I was meeting with a client a few months back. This particular client was having some ongoing issues with the performance of their help desk. Specifically, tickets were not getting closed in a timely fashion and as a result IT’s customer (i.e. users of IT services) were getting some what exasperated (to be polite). The question on the table was how do we change this trend and begin to improve service levels? It was a serious issue for the IT team and it had been a problem for a while. Consequently their internal reputation was less than stellar (most of the organisation thought they were incompetent) and “shadow IT” was popping up all over the place as the rest of the organisation sought to work around the IT team.
As the conversation progressed the approach that the team began to agree on was the need to define and implement robust business processes in and around the help desk in the belief that if they could implement robust processes this would lead to improved performance. They set off to make this happen, meanwhile I sat, observed and began to feel distinctly uncomfortable.
It’s not that I disagree with the assumption that high performing teams have robust process and are really really good at what they do. Indeed, when you look at high performing teams they almost always have high levels of process maturity. That is, they know what they need to do and they do it really well. Stick to the process, the results will follow.
This stick to the process philosophy has dominated business for as long as I’ve been working. The gold standard for change has been to design and implement robust and mature processes knowing that if we do that well we will produce excellent results. Great results and high performance comes from successfully following a well designed process. This is what the team was proposing and it’s an approach I have used a lot during my career. It is the approach that sits behind not just process engineering but most, if not all, “technology enabled change.” The software we are implementing has predefined best practices. Our implementation approach is to leverage these best practices for the benefit of our business. By doing this we will establish robust processes that will enable improved performance. This logic has been liberally written into business cases through time, indeed, I may have even written words like this into a business case or two in my time.
It’s clean, logical and sensible. It’s a relatively easy sell as I reckon nearly every executive in the world either actually believes that this is true or wants to believe this true. The problem is, most of the time it doesn’t work. We know this because project success and failure statistics tell us it doesn’t work. Yet we keep doing it.
It’s not just business that run this process led improvement mantra. The past decade or so has seen a significant growth in the pop culture of stick to the process. It is most visible in sports stars. How often have you heard a sports star or a coach of a professional sports team saying something like “we don’t think about the outcome, we focus on the process and if we do that well, the outcome will take care of itself.” Stick to the process, but I can’t help thinking that stick to the process means something very different to a professional sports team or person than it typically does in business.
In sports stick to the process seems to refer to a series of rituals and routines that the team / person uses, practices and repeats to support them to perform on the day. Sticking to the process seems to be predominantly about getting their preparation right so that when game time comes they are at their best. When game time comes yes they use the moves they have rehearsed in practice but by and large they play on instinct and this allows the skills they have practised to come to the fore in the game. I can’t remember the number of times I have heard a New Zealand rugby coach saying that they want the team to play what’s in front of them, to play on instinct.
In business it tends to be the opposite. We don’t pay on instinct, we rarely practice skills outside of “game time”, which in this case is talking to IT’s customers and users. Then we expect flawless performance through routine application of predetermined actions. It doesn’t work for many reasons but the primary one amongst them is that if you are focusing on executing the process in this fashion you are unlikely to be “playing on instinct”, playing what’s in front of you. In the case of a service desk (and most of business) what’s in front of you is a customer problem. Playing on instinct would be to take your knowledge and skills and apply it to solving the customer problem. Do this in your service desk and across your IT organisation and you have the start of a customer centric organisation.
Also, in the event that a professional sports team or sports star doesn’t perform you will also often hear them talking about learning from what happened and making the appropriate adjustments. That is, they take the lessons from the game back to the practice field. They adjust how they prepare and refine new or different skills in the hope that they can create different results on the field during game time. I have never been a professional sports coach but I get the feeling that in season 90% of what the teams do is adjust based on feedback from game day with a view to improving performance the next week.
How often do we do this in business? What we did didn’t work for the customer. What lessons are there for us in this and how can we improve? Let’s take these lessons, build them into our practice, adjust our process and aim to get better. I hear this sometimes but very seldom.
All of this brings me back to the starting point. There is no doubt that high performance is underpinned by robust process, however getting to high performance is less about designing the world’s best and most robust process. Rather it is much more about observing performance both good and bad and adjusting your approach based upon actual performance for the customer. That is, we need to create a customer centric view of service. Did we meet the needs and wants of our customers? If yes, how can we repeat this? If no, what do we need to change to improve the outcome?
If we do this we can create feedback that “closes the loop” on process development and builds our way to becoming a high performing customer centred team supported by robust processes.
