The concept of a “problem” in service management is already well-defined.
ITIL 4 states that a problem is “a cause, or potential cause, of one or more incidents”.
For example: a customer’s computer stops working (an incident); the supplier sends a replacement, which resolves the incident. However, the supplier notices that the failed computer is one of several manufactured in the factory on Friday afternoons. To understand the underlying “problem”, the company identifies that production teams visit the pub at lunchtimes on Fridays – and they’re not drinking fizzy water.
By pinpointing the problem, a solution can be applied – in this instance, sorry folks, but no alcohol on Friday lunchtimes.
While this fictional example of problem management might seem simple enough, companies still have much room for improvement.
Some people think it’s just a process that’s organically created when a company obtains certain standards and associated documentation. However, the key questions are: who owns problem management? Who’s doing it? How are you measuring success?
Ownership of problem management is critical, as it often involves bringing diverse teams together to collaborate and resolve problems. It doesn’t just happen by itself.
So, it’s an even greater necessity to have the right people in place than the right documentation.
Problem management in a digital computing era
Our era of digital transformation has led to a larger and far more complex systems environment – which has a knock-on effect on what “problems” occur and how you handle them.
With different types of contracts and vendor/supplier relationships, plus the proliferation of different systems, the problem management principles of diagnosis and analysis around a cluster of incidents has become more difficult.
Despite the interconnected nature of cloud computing and applications – hence a heightened risk and criticality for businesses in the digital age – the right analytic skills are lacking in modern problem management. This means failure to resolve root causes of problems, which leads to frustration, waste, recurrence of incidents and a more significant (and faster) impact than in previous, simpler systems environments.
It’s an unavoidable truth: organisations need to develop better problem management skills and capabilities.
How should problem management work in practice?
First, effective problem management needs the right people, with the right mentality, to acknowledge that it needs to improve and to promote the value of collaboration.
From there, it’s necessary to understand what the business’ main problems are and to quantify their likely impact, such as risk to the organisation, potential benefit from achieving a fix, improved customer experience and so on.
Part of this is evaluating whether a problem is a technical or a people/process issue? Analysis is key to unearthing the source and translating it into something a decision maker understands from a business perspective (e.g. cost savings) and can decide on investment to reduce risk and achieve value.
Another key success factor is transparency visibility of problems. Don’t hide them away in systems, get them out in the open so that a wider group of people are aware of them and potentially able to fix them or contribute.
The value of problem management
Without problem management, internal IT departments won’t progress. Risk and technical debt will continue to grow and opportunities will be missed. Costs may not be optimised and service experience will not improve.
Organisations will often look to managed services companies for new solutions, where often the success focus is primarily still on incident management. However, change is also afoot for the managed service model: where, previously, there was no commercial incentive to reduce incidents, they are now often incentivised to make necessary improvements that fall within the sphere of problem management.
But while there is investment in people doing problem management, there is also a persistent lack of analysis and ability to convert the diagnosis into business speak that non-techie decision makers can relate to.
Also, there is a need for greater, organisation-wide transparency for problem management; for example, encouraging approaches such as swarming, which bring a collaborative, group method to fixing problems. Whichever way you do it – one problem manager pinned up posters monthly with the top 10 problems – it needs to be out there and visible.
Problem management, as a key practice in service management – it’s a ‘game changer’. There is increasing awareness and demand to do this, plus the practice is generally getting better, but it needs to move from theory and documentation to gritty reality – to make it happen.
Technical people will get issues fixed – the challenge is organising that this happens in accordance with business needs and priorities.
This is mostly a people, leadership and business issue, not just a technical or process one.
Problem Management summary points:
- Get the right people to deliver problem management – it doesn’t happen as a process by itself.
- Quantify and prioritise problems in business terms (risk, quality, user experience, cost, opportunity), and in business language.
- Broaden the scope of what problems and their causes are – its not just about technical issues.
- Make problems visible – everyone, especially leaders, should know what the top 10 problems are.