Accountability Model

First, from the dictionary:

• Accountable - Liable to being called to account; answerable
• aility or -ibility is a suffix meaning - Ability, inclination, or suitability for a specified action or condition
• Model - a pattern or mode of structure or formation

So, we're really talking about a pattern or structure that shows us how to select the group most suitable to be answerable for a specific task.

What!?! What weirdness is this and what does it have to do with me?

As we progress with our process reviews and redesign, we're finding more and more that the better we define the Accountability Model, the smoother things go. It's a point that we illustrate in our latest round of Incident Management training. It's also the point the a large number of our trainees say was the biggest learning for them when they come to the training.

Essentially, our Accountability Model for Incident Management says that we can distribute all incidents into three specific types - Individual, System, and Design, and each type of incident has a specific group that is 100% accountable to get that incident resolved.

Individual incidents are those affecting an individual, whether it is their account, computer, connection, or ability to do what they need to. An individual incident can't be duplicated using another account or on another machine, etc - you get the idea. Accountability for individual incidents resides with either the Service Desks or Field Services, depending on the specific details of the incident.

System incidents are those affecting many individuals and are resolved by restoring, restarting or reseting a system component such as a server, switch, router, system, etc. Accountability for system incidents resides with either Operations or Field Services, again, depending on the specific details of the incident.

Design incidents are those that require a design change to resolve the incident. No amount of restore, restart, or reset will get the customer back in service. Accountability for design incidents belongs to Engineering.

The idea is to get the incident assigned to the correct accountability group as quickly as possible so the incident can be resolved quickly. We're having no more of this transferring incidents from group to group to group like a hot potato. It's important that we learn how to do this well so that our customer's incidents can be resolved as quickly as possible.

On ITSMWatch.com I found the following quote that talks about the value of the Accountability Model:

"There are many jewels of IT service management (ITSM) guidance in the IT Infrastructure Library (ITIL), but of the most valuable is the inherent accountability model that is referenced throughout the framework. Utilizing this accountability model can make all the difference in changing “hard work” efforts to “smart work” efforts.

Having clearly defined accountability and responsibility allows for individuals to understand what service they provide; what their role is in the overall management of a given service, process, or function; and provides a mechanism for aligning their daily activities with business priorities."

See the whole article here ==> http://www.itsmwatch.com/itil/article.php/3794216

Even better, we think the Accountability Model helps us to understand and respect one another. Too often, it seemed that the old way of just pushing an incident along the path "up" the levels of IT led too many people to think that the "first level" Service Desk wasn't as smart or as capable as the "higher levels" of Operations or Engineering. We affectionately call that the "Dummy Model" and want nothing further to do with it. Our Accountability Model abolishes the levels and focuses instead on ares of suitable expertise.

It's kind of fun in the training sessions to see how this plays out. When we do the wrap-up at the end, it's always interesting to hear how eyes are opened and how respect is generated for each of the OIT groups and how the Accountability Model helps people to 'get it'.