January 20, 2009

Key Performance Indicators (KPIs) for SM processes

Posted in ITIL tagged , , at 4:03 pm by Molly

What are they?

First, we have to understand what they are before we can understand how and why we need them. A KPI is a metric, a type of report or value you use to measure or show the success of your Service Management (SM) process (this is an ITSM blog). You will want to use them and understand them in greater depths, so that you can target failures in the existing process and maybe kick-start a Service Improvement Program (SIP).

Why do we need to know about these process failures?

Your organisation doesn’t want to have a failing or ineffective Release Management process does it? Think about all those illegal, pirated, and beta versions of software that are floating around amongst your staff. Now consider the consequences of an external audit (it may well happen with a large financial institution). Does your organisation really want and can it afford to appear in the next morning’s press with the headline “€1Million fine for illegal software/downloads at ABC”? This would be a big wake-up call for your management team and if you are part of this Release Management team, you will probably consider a new career. So you see, it is important have visibility of, not only your own process but all the other interfacing and underpinning processes too, because they may directly or indirectly affect yours. KPIs also assist with your process strategy, which feeds further up the management ladder and produces the management strategy for the whole organisation.

KPIs are measured in percentages (%) or number(s) of something. Let’s look at a few examples, and let’s consider our Release Management process.

    Number of implementations (releases) bypassing Change Management;
    Number of incidents caused by releases; (this would be a hard pill to swallow)
    Number of failed releases;
    Number of urgent releases in the current quarter; (could another process be failing for this to occur?)
    Number of releases not adequately tested;
    Number of releases implemented late;
    % of releases without back-out plans;
    % of releases that failed during the testing phase … due to incorrect configuration information; (another process is involved here, is that process failing in some way?)
    % reduction of illegal software decommissioned in the live environment … during a certain period; (a nice management information success story for the Board of Directors – shows you’re on the ball with this one)

Do you see what we are trying to achieve?

We are identifying positives & negatives of the process, and whether it is or has improved or reduced over a period of time. This in turn, will help us identify whether the Release Management process is at fault, or whether there are interfaces into Release Management from other processes that are causing these errors. Ideally, we want to collect information that will be useful, so that is another topic entirely – the collection of USEFUL DATA. How do you scope the data you want to collect to improve your process? That is entirely up to you and probably your management team. Obviously you don’t want to be spending huge amounts of time as well as computer resources gathering all this information (hopefully you won’t be slowing down the network!).

Know what you want to report, identify what is important to the business, keep the other data for yourself, it could be useful to have a baseline.
Give management the bottom line in plain business speaking language, don’t fluff it up with technical jargon either, but also justify your data (back up your arguments).

How can KPIs be useful to me?

KPIs can kick start some process improvement program/plan, can identify where the bottlenecks are occurring, can maybe identify staff who are ‘doing something incorrectly’ which you may take action upon (further education, more training, sticking the procedures manual on their desk) and it can identify other processes that are causing you failures or reductions in service. Remember this isn’t a ‘blame game’, you should just be highlighting areas within your team where improvements can be identified, curbed, and improved so that your team or your process can function efficiently and effectively.

Let’s look at this minor scenario: “Joe has been a tester in your team for six months, he gets the job done, but he constantly keeps forgetting to get his test plans signed-off by you, the Release Manager. What hasn’t been identified yet are that all Joe’s release units create more incidents when they are released into the live environment. This is starting to annoy the users and in turn the Service Desk manager too.”

As the responsible owner of this process, what are you going to do about it? Do you care that this minor deviation in your process is going unnoticed? Is it going unnoticed by the users or other team members or management? Are you getting it in the neck at management meetings when the Service Desk manager once again pipes up that releases are causing more incidents? Are you the bad guy, the guy who doesn’t manage his team, the guy who is costing the company money, money that could be better spent on hiring a configuration librarian or further training elsewhere in the organisation. Will you sit on your laurels now – surely not!

Why then is it useful to have these KPIs for our little scenario? What possible benefit can you gain from knowing why releases are causing many more incidents? For one, you will stop getting it in the next from all the other managers at those management meetings. For two, you can identify within a short period of time both what and where the problem is occurring. For three, you can take Joe aside and ask him why he isn’t getting his test plans signed-off. Actually, he may just have forgotten because he’s been so busy, but what if he hasn’t read the paragraph in the Release Procedures manual that says in bold red letters that he needs to get all his tests signed-off before going into the rollout planning phase. Obviously you will have some pleasant words with Joe and make him understand his actions are causing more incidents, leads to more time resolving these incidents, leads to more RFCs being raised to resolve these incidents, leads to further release units and finally more work for Joe!

Nip problems in the bud early, by early identification, and how best to do that is to keep one eye on those reports!

N.B. Your process is only as good as the people who use it.

Keep it ITIL conformant, but if you see that an additional tweak or improvement can be made to it, try it out first before putting it into your Policy or Procedure. That improvement might help your organisation stay ahead of the game.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: