CoreITSM 101: ITSM Audits

To be truthful this probably isn't really a 101 subject, but I'm posting it here because 'audit' is a term you'll find used with casual abandon by those in the ITSM world who don't really understand what it is all about.

Not all audits are equal, and neither are all auditors 

In fact let us begin with the different types of auditor, because that has a massive bearing on the type of audit that can be carried out and the value that can be derived from it. 

In the ITSM world  the auditors you are most likely to meet include:

• The independent quality auditor assessing management systems against an ISO standard
• The consultant undertaking a supposedly independent audit  prior to and after an ITIL implementation
• A 'tick and turn' internal auditor following a check list
• A systems based internal auditor who will assess whether the system of  management control is effective and/or whether  Value For Money (VFM) is being achieved
• A technical IT internal auditor who will be able to test and assess assess technical controls in detail

 Hopefully I don't need to dwell on the outmoded "tick and turn auditor" I still have nightmares about when the manager of a major government data center rang me up to complain that two of my trainee auditors were insisting he lifted the floor panels so they could check the voids for dust and debris, even though he had explained to them it was a solid floor.

If you read some of the ITSM literature you could be forgiven for thinking that ITSM audits are mostly undertaken by the teams responsible for each process. In reality this rarely happens, though, with several caveats, there are arguments in favour of it as one aspect of the overall audit process. 

So, what about the types of audits these guys and gals undertake?

The last time I checked I was a member of three BSI/ISO committees, so obviously I think ISO standards are a "good thing"  If you aren't British you might want to read '1066 & All That' to get the joke. The point is that these audits do exactly what it says on the can.  They do not look outside of their very specific remit, and that remit is the basic requirement of a management system. So if your IT supplier makes great play of being  ISO/IEC 20000 certified be sure you understand what that really means. it does not tell you anything about the actual quality of the service they are capable of delivering. What it does tell you is they haven't just cherry picked the 'easy' ITIL processes of incident and change management. It is a great starting point, but that is what it is, nothing more.

In another lifetime, before marriage, step-children, dogs, cats and degus I spent a lot of my time doing audits as part of consultancy assignments. Typically we would use a pseudo CMMI approach, because clients can understand the message

"You are here, but really it would be great if you here. Don't worry, it is OK if you only get to here, because we can rationalise it for you"

I'm actually a great fan of maturity models, and I think COBIT has done a good job of integrating them into the ITSM world. I believe, however, that most ITSM maturity models and assessments are flawed though, not least because they never explicitly address how we balance the maturity of an individual process against overall maturity. Being really really good at incident management is really really great, but it doesn't make you a mature service management organisation if you are not terribly good at request management. The classic example we see of this is people claiming to be at a high maturity level for change management but not for release management, service level management, capacity...or any of the other capabilities and processes that are essential to delivering world class change management.

Dare I suggest that the he people doing these audits want to sell you things. Then when they've finished selling you things they want to sell your success. So how much do you trust their audits? 

Now in contrast ITSM could do a lot worse than invest time and effort in cultivating your friendly systems based auditor. They will ask what it is you are trying to achieve, validate that outcome, and then assess whether you are are doing the right things to achieve it.  The only downside is they won't know what technology is capable of achieving...which is where your technically capable auditor comes on the scene. You can possibly sub divide this type of auditor into the one trick pony, who knows a lot about, say, security, and the technology auditor who also keeps a foot in the business world. Both have a valid role to play. 

So what about this concept that ITIL seems so fond of, the self audit approach? First of all let me be very pedantic and make two points. The first is that this is not 'Internal Audit'  Internal Audit  is a corporate governance function and, secondly, what Internal Audit has that the IT team doesn't is independence.

Leaving that aside though I believe there is considerable value in an internal team trying to take an objective view of their own performance.  After all no auditor will ask any question that management shouldn't have already asked themselves. However I think they need help to make it effective. So cultivate a friendship with the audit team, and ask them about Control Risk Self Assessment. Involve your stakeholders in the process, and above everything else make sure you focus on your ability to consistently deliver desired outcomes. 

Just because it has never gone wrong in the past doesn't mean it will always go right in the future