August 11, 2008

RACI tables in ITIL, in projects, in life!

Posted in ITSM, Project Management, RACI matrix tagged , , , , , at 4:45 pm by Molly

Open your Service Transition v3 books, turn to page 166 and you see table 5.3 “example of RACI matrix for managing change“.

Notice how the change enabler can be either a process owner or a service owner. This table doesn’t make it entirely clear to the reader at first sight that these two roles are considerably different. Therefore, when I created this table, I duplicated this Change Enabler to be either a process owner or a service owner with their own defined rules.

RACI = Responsible, Accountable, Consulted and Informed.

Referenced in Service Design & Continual Service Improvement.  Its a model used to help define roles and responsibilities.

Responsible:  the person or people responsible for getting the job done.
Accountable: the person who is accountable for each task (can only be one person).
Consulted: The people who are consulted and whose opinions are sought.
Informed: the people that are kept up-to-date on progress.

For example:-   The PROCESS OWNER is responsible for their proccesses and the SERVICE OWNER is accountable for a specific service.

V3 exam question:

A Service Owner is responsible for which of the following?

  1. Continual Improvement of the service
  2. Designing and documenting a service
  3. Carrying out the Service Operations activities needed to support a service
  4. Producing a Balanced Scorecard showing the overall status of all services

Can I use RACI Matrices for other applications ?

I had an interesting conversation with someone recently, the conclusion of that discussion, prompted me to edit this post and it all centred around the RACI table.  A somewhat bold statement was made during this conversation, and it goes something like this, “.. you can use RACI tables in everyday situations”.   It got my head in a spin, because I wanted to come up with some sort of smart retort that RACI tables or matrices could only be used in service management, but today I found blurting out the words “let me create a RACI table for that”, and it wasn’t even related to anything ITIL, it was concerning additional resources for a project.

Stay with me now, don’t loss track of what we are talking about, because I think I’ve also just hit the nail on the head with this one, and am becoming to see myself as a the number one fan of RACI tables.  Wouldn’t it be dandy to have a RACI table which depicts your project resources, either those directly in your control and those that you liaise with closely or whom provide you with information (indirectly or directly); then the tasks or actions down one side, then you can ‘control’ through your RACI table who has the responsibility to source this & that, who is accountable (say to manage the information i.e. make sure of its accuracy, its completeness etc.), who is consulted for information or for project updates (information inputs and outputs etc.), and who is kept informed on a daily, weekly, bi-weekly running period (sounds familiar?).

What also intrigues me is the fact that you don’t even have to manage this table once it is 100% accurate, unlike the project plan, but a word of warning to you, don’t use the RACI table to ‘replace’ the project plan, no way can it be used to convey milestone dates or other such deliverables.  What the RACI table I just mentioned will give you is the holistic view of ‘people’ and as project managers we need to constantly be fully aware of what is communicated around us with regards to personnel.  Loss sight of resources, and they will be pinched under your nose without you knowing about it (how many times has that happened to you?).  Loss sight of their involvement in your project and your project may loss its focus and milestones will start to slip like a mudslide on a rainy day (look how devastating they can be).

Also, don’t ignore the RACI table totally, but don’t think you need to update it on a daily basis either, its a tool, another tool you can carry with you on your project manager toolbelt each day.

I’m dying to find more uses for RACI tables, and when I come across them I shall update this page and share those experiences.  Am sure there are hundreds of applications where I can use it.  So start using it yourself, and if this inspires you, jot me down a quick comment on the page and share your experiences, as I would love to hear them all.

Principles of metric design

Posted in ITSM tagged at 2:40 pm by Molly

SMART

Specific – does the metric measure a specific process or part of a process? If the metric measures parts of a 2 different processes there is a danger that neither process owner will feel responsible for achieving the result.

Measurable – is the metric measurable? You may need to measure the time your customers are on the phone to the service desk, but if you do not have a switchboard or PABX that can give you the times of calls you will not be able to track this.

Achievable – would it be possible for the service desk to close all calls within 3 mins? If it takes 2mins to fill in a screen with all the callers details (obviously if you have a good CMDB this would not be the exercise or time frame) then you are only allowing one minute to solve the call – which is probably not achievable!

Realistic – does it make sense to measure the time that incidents keep the status of ‘waiting’? there might be lots of different reasons this call might be in this state. If you don’t know what the reasons are, then being asked to reduce this tiem is not realistic. In this case, the solution would be to split this status into for example:
‘waiting for customer call back’
‘waiting for 2nd level support’
‘waiting for software patch’

The important point is to ask yourself whether this really is measuring something in the real world, rather than something that is just part of the software package!

Timely – if you measure the performance of the service desk once a month and one metric is customer satisfaction, base on quarterly surveys, then you don’t have a timely metric. Customers could be dissatisfied for 2 mths before your metric would show it!

KISS

Keep
It
Simple
Stupid

If metrics are not explained well and how to achieve them not well understood, the door is open to resistance, rejection, disillusionment and easy excuses for non-compliance. So explain them well, make them easier to read and understood by everyone involved from the reader to the producer.

It would be better to step back and ask what is important.

Some Other metric design methods:

GQM – Goal – Questions – Metrics – Method

MAPE – Mean Absolute Percentage Error

ITIL & COBIT working in harmony

Posted in ITSM tagged , , at 2:30 pm by Molly

IT organizations are under increasing pressure to meet the business goals of their companies. This challenge can be particularly daunting because it involves complying with regulations, such as the Sarbanes-Oxley Act (Sarbox or SOX) and Basel II.

Compliance requires strong corporate governance capabilities that are demonstrable to outside auditors. Because IT plays such a major role in business processes, the IT organization not only creates complexity for the business, but at the same time, provides the means to demonstrate this compliance. Organizations rely on guidelines such as the IT Infrastructure Library (ITIL) and Control Objectives for Information and related Technology (COBIT) to help understand and address these challenges.

ITIL and COBIT can enable organizations to achieve three objectives:

  • Establish proven best practice IT service management processes to manage IT from a business perspective and achieve business goals, including that of compliance
  • Put in place clear process goals, based on the organization’s business goals, and provide a means of measuring progress against them
  • Ensure effective IT governance and control at the process level, and enable IT to demonstrate that it meets or exceeds the requirements set forth by government or external regulations

There is, however, confusion in IT organizations concerning these frameworks. Some think they are two alternate approaches to the same goal, and others think they are mutually exclusive. Actually, they are highly complementary, and together provide greater value than using just one or the other.

COBIT outlines what you need to do to meet these challenges and ITIL shows you how to get there.