Part #2: Wicked problems
Synopsis:
Whilst IT must present itself to its customers more simply in terms of business benefits, its maturity and effectiveness are dependent on building complex solutions. IT systems depend on increasing levels of abstraction, integration, and complexity. A methodical approach using techniques like MECE (Mutually Exclusive, Completely Encompassing) and systems thinking can be used to solve these wicked problems.
What is a service?
A good way to illustrate what a service is, is through the quote “it’s safe to say that nobody wants a quarter-inch drill. They want a quarter-inch hole.” Or “When you buy a razor, you buy a smooth chin”. People don’t buy products or services; they buy the expectation of benefits.
Customers evaluate a product or service in terms of how easily it helps them achieve their desired outcomes. A driver expects their satnav to position them accurately on a map. They care ‘not a jot’ for the network of GPS satellites orbiting the planet that need time keeping so accurate that the engineers have to take Einstein’s theory of relativity into account. That is not their problem. They have paid for their satnav and the dot better be in the right place on the map.
To show the benefit of an IT service, we need to show its effect on the company’s bottom line. What is does, not how it does it. The irony is that while we need to explain the service in simpler terms for the customer, behind the scenes we need to go deeper into layers of abstraction and complexity.
As an example, let’s use 5 Whys analysis to understand why we would need Dynamic Service Mapping.
Investment proposition: We need Dynamic Service Mapping
The point is that the business benefit of improved availability is obvious, but the need for a Dynamic Service Mapping capability that enables it is obscure and form part of a complex multilayer solution.
Decomposition
To create a complex system, we must break it into smaller parts and design how each part will work. The use of McKinsey’s MECE (pronounced Mee-See) approach is very helpful. It stands for Mutually Exclusive, Completely Encompassing. It is human nature to jump straight to a solution without really agreeing what the problem is. Often stakeholders want to show just how difficult their problem is by combining lots of related problems into a big knotted-ball of a problem. MECE breaks down the problem space into separate smaller problems that a mutually exclusive. Completely encompassing ensures that all problem aspects are considered, and no parts are forgotten.
But those parts do not work in isolation. The output from one process is the input to the next. IT departments are rated as more mature when there is focus on not only how well individual processes perform, but how well they interact with other processes.
Recomposition
Problems that are difficult to solve due to their interconnectedness and the lack of a clear solution are termed ‘wicked problems’. We start by breaking problems into smaller parts, but eventually we need to combine these parts into a system. We need a network of capabilities that work together to become greater than the sum of their parts.
One example of this comes from event management. We can take log information from a collection of tools that monitor networks, applications, and infrastructure, and combine it into a large data set. We can then use Artificial Intelligence to look for patterns that reveal underlying problems and predict service impacts. These insights feed into Problem Management which evaluate them and present them as investment opportunities to be managed as projects.
Our ability to influence the bottom-line is based on this entire end-to-end ecosystem, or to use the business terminology, the entire value-stream.
Don’t reinvent the wheel
Another aspect of wicked problems is that they are unique. Whilst every IT department is unique, and the exact services they offer are specific to their business, IT Service management is a common activity, and many others will be facing the same challenges.
At KTSL we are often approached by IT Managers who share their business problems, but who have not yet got into the depth of creating a value chain to solve them. There are tools and practices that they are not aware of. If we ask: “what are your requirements” we sometimes get the answer: “you’re the experts, you tell me what my requirements should be.” Working on service catalogue we usually get asked: “what is everyone else doing?”. These questions are perfectly reasonable. With such complex interlinking systems, defining the problem is part of the problem.
Tame problems
Once wicked problems have been investigated and solved, they can be tamed into known problems where a solution is available and can be re-applied by following rules and applying technical knowledge. A framework is needed to: understand and define the problem, to create the business case, to move it through analysis, solution, testing and finally implementation and BAU.
Next time...
In our next newsletter we will look at how business analysis practices move us through this process.