Working in support provides the opportunity to witness the behaviour of individuals and organisations in the face of failure.
Systems stop working, processes break down, money gets lost.
As many companies today have decided to be managed in a structured (maybe even “scientific” way) there are of course also procedures to handle failure.
In IT organizations these procedures are especially well-liked (think of the often used ITIL process framework).
A major part of such procedures is to define responsibilities.
Who is responsible for what?
The idea behind this is clear: to avoid unnecessary and unproductive discussions about who has to do what when this or that happens.
So far so good.
But reality puts a different connotation of responsibility into the spotlight:
Who’s to blame for what went wrong?
And this is where the real problems start.
In reality, people, not functions or positions, have to actually DO what was planned before in the process descriptions.
These people aren’t “invoking a process”, but the DO their work.
Now, with the responsibility chained to their function these people have to work in fear of becoming the one to be blamed for whatever went wrong.
With fear in place, most people switch to “lizard-brain“-mode, that is, they run and hide.
For business processes, cover-your-***-minimal-process-step-fulfillment-working is the equivalent of “run and hide”.
Another effect of this situation is to relay the pressure to the next chain link.
(business user calls IT -> IT calls product vendor support -> vendor support calls partner hardware support -> … *put in any loop in this as you like*)
Thus, by neatly defining what to do when things go wrong, a system had been designed that, by it’s very design, leads to half-assed execution of procedures that are supposedly not just important, but critical to the organisation.
Interestingly, the measurements (KPIs) for the processes effectiveness are usually fulfilled even by this kind of work.
I’d say that this alone would disqualify these KPIs then – but no, stuff like guaranteed initial reaction time (IRT) is still sold a lot. (and so are the certifications for such process structures)
However, even the bad aspect of ever more failing “process invocations” for critical issues does not seem to provoke a re-thinking on the way to handle failures from a organisations point of view.
Sure, it may be true that in many cases handled in IT-Support the KPI-reports are next to perfect. But if one looks closer, then many of these cases were either trivial or could be solved by applying an already known solution.
Suddenly the good KPIs turn into cases that were preventable in the first place.
Looking at the cases where really new problems are handled, very often the people working on it don’t even get to really work on it, simply because they are busy with doing everything not to be blamed for anything afterwards.
Still these people – who are supposed to work on the problem solution – are actively chased by managers and process owners to regularly deliver status reports.
I personally was involved in cases in which process owners asked for call conferences every 30 minutes to discuss the progress. Just to keep in touch…
Seriously, if there is a problem for which the solution is yet unknown, then I would expect the person assigned to the task of solving it to actually spend time doing that: solving the problem.
So, what should be done instead?
I’d propose to provide the people that do the work (that give life to the processes) with certainty about their job and their abilities.
Don’t focus on failure when designing process KPIs but instead motivate people to get engaged with the solution to the problem.
Embrace thinking and working beyond one’s own desk.
Enable a working-culture where problems aren’t handed over to the responsible department, but where the problem is actively discussed with the topic experts.
Are there KPIs available for working this way? I don’t know.
But maybe management has to rely on personal (or group) judgement instead of stupid simple numbers.
I know, all this is a nice wish list, but hey: it’s just four weeks to Christmas today!