CIO Thoughts

One of the things I have discovered through a number of implementations of ITIL processes, is that it doesn’t really matter how many processes get put in, or measurements applied, if you don’t have ownership, it will all come to very little.

In almost all of the organisations I have been involved in there has been some element of what I call ‘fence-throwing’.  This is when one team passes an incident or ticket to another team without taking any ownership of the customer, checking to see if it is received ok, or determining whether they should be taking a deeper look.  It leads to dissatisfied customers, a reputation of IT being a ‘black hole’ and inefficient solutions.

Pretty much everywhere I have been I have solved this issue in the same way.  Whenever a problem crops up that gets my attention (and it is usually the higher impact ones that do, but it can be almost any of sufficient complexity), I form a cross team group to resolve it.  I will choose the best person placed to add value from each team in the department, describe the problem, and then get them to work through it.  Inevitably there will be the usual slopey shoulders, but by using questioning techniques designed to bring them together  (eg. ‘That’s one solution, but how could it work better if you involved John from the DBA’s?’)  and showing them the difference in a solution that is self-generated and one that is team generated I usually get buy-in. Of course, having the courage to allow robust, challenging, and constructive discussions about solutions is also important – it helps to build the team feel, and establish a notion of the solution being one they agreed on.

Now, I am not suggesting you need consensus on all the solutions generated, although that may be useful in some instances.  Often it is best to get a few solutions on the table, list out the risks, timescales and resources (pro’s and con’s) and then make a decision yourself, explaining why the decision was chosen.  This shows you are both willing to listen, and willing to back what you believe to be the right solution. Finally, it is important in these discussions that you always have one person taking the customers perspective – even if it has to be you. Otherwise you won’t really be balancing all the risks.

The whole idea here is of course to get them thinking as a team outside of their normal day to day team.  There are other ways to do this as well, such as forming project groups, where the results are the responsibility of the group – be it success or failure. Showing leadership by example is important too – when a request comes across my desk, I will make sure I understand it, send it to the Service Desk for logging, make sure the problem is being resolved, and then do a quick check to see if the team have handled it well with both the solution and customer in mind. It is effectively random checking, and where I find it done well (including handover between teams) I look for opportunities to praise and reward the individuals.  Where it is done wrong I determine whether it is one of three things: the process for doing it is wrong, the communication has been incorrect, the skills of the individual are insufficient or the person has simply stepped out of all of those and gone off on a tangent.  Once I know that, I make sure the corrective actions needed are put in place, along with a timescale.

To get teams to work together you need to show trust in the teams, and an expectation that they will and can work together well.  Once you have this, the ITIL style processes will really start to fly.  Don’t expect it to happen immediately though – it takes consistency in approach, constant care about the customer and a consistent belief in your people over a period of time.  How long? Well, that depends on how well you do it, how receptive your people are, and a few successes to prove the point. In my experience, about 6 to 9 months usually does the trick.

|