Testing and Verification of ITIL Implementation

[bobwill]

After a partial or full implementation if ITIL, how does one test it, or verify (especially to upper management) that things are working and working well? I.e., I can implement an operations architecture and I am able to test it too; how about ITIL?

[Azard]

hi, you will need to define the metrics of how well the process is working?
Ex. if you incident managemenet process is working well, you should be able to measure increase in satisfaction from your clients. This could be a metric you choose to report on.
If you are tracking software licenses as CI's, when you do a reconciliation, your metric should indicate is the company saving money by reusing licenses, or do you have more licenses than needed?

hope that gives a few ideas.

cheers,

[RandyASteinberg]

The proof is in the metrics. Each process should have established critical success factors and Key Performance indicators. These should be measured and reported on each month. The ability to reach targets as described by these will indicate whether you are succeeding or not.

[rjp]

Remember the M in ITSM - ITIL processes are management processes, not operational processes. The justification for ITIL is that traditionaly IT producction has been poorly managed.

ITIL processes are designed to increase the clarity, visibility, and measurability (is that even a word) of ICT production. So the inforamtion gathered in your Incendent Management processes are not designed - first and foremost - to tell you how well your incident mangement is going, but how well your infrastructure is travelling.

So for example MTTR (Mean Time to Resolution) isn't automatically a measure of the IM process performance - perhaps the prudction people and change management has really got there act together this month and the only change effected incidents were of a trivial nature and easy to resolve at first point of contact.

So take care not to apply the producction metrics your ITSM processes enable to a performance indicator of the processes themselves.

Checking the health of the process has two aspects - neither of which is really to do that much with throughput (or 'quantitive performance')

1: Process quality - eg: analysing how many incidents were re-classified after being assigned.

2: Overall maturity - aimed at assessing how well your SM processes are controlling and improving the production. So that you can relate incidents through problem management to a prior change, indicates a maturity level higher than processes where that link is still invisible. That is a very real indicator that your ITIL implementation is working - and has nothing to do with how many incidents are being caused by changes, or how qhichly each on was resolved.

The Service Desk - being a function not a process is slightly different, and it does make sense to have metrics that measure how well the Service Desk is performing - though the ceiling on that performance will related directly to the level of maturity of your processes.

NB: Assessing process quality and maturity, and the leel to which customer expectations are being met are very good habits to be in.