Problem solving is a skill that is relevant for just about every role within an organisation. It doesn’t matter whether you spend most of your time working with colleagues internally, or whether you work for a managed services provider (MSP) that offers services externally, it is likely that dealing with problems takes up a significant part of your day. Whether you’re a CEO, receptionist, or contact centre worker, chances are that you are involved with solving a wide range of problems. These can range from small, well defined and well scoped problems (for example, a customer not receiving a parcel) right through to tricky, messy and ill-defined problems (for example, revenue dropping due to multiple unrelated yet volatile conditions in the business environment). Sometimes, our problem solving activities are so ingrained in our daily activities that we do them without thinking. Other times, for larger problems, we might use formal business analysis, creative thinking or problem management techniques. Entire methodologies and practices have emerged which help us liaise with relevant stakeholders and analyse different potential options for solving organisational problems.
One important element of problem solving that is rarely discussed is problem ownership. Even the smallest problem is likely to need coordinated action from a range of people within the organisation to resolve. The problem owner works with others to ensure this cohesive and coordinated response. Significant problems can occur when a problem isn’t ‘owned’.
We have probably all experienced situations like this in our own lives as consumers. Imagine that you order an item online, and after waiting a week it still hasn’t arrived. You go online to track the parcel, and discover that the company holds the wrong address on file—you are sure that you entered it correctly, so it must have corrupted somehow during the order process. You ring up to explain the situation, and the customer services advisor offers to send a replacement, but advises that they can only send it to the address they have on file. This won’t help—as you know they have the wrong address on file. You are transferred to billing—who advise that they can only change your address if you e-mail (or fax) proof that you’ve moved (which you haven’t—the original address was typed incorrectly!). You go round and round and eventually give up…
Clearly this is a hypothetical example, and I would hope that no organisation actually operates like this, but the core issue here is that nobody owned the problem. Everyone involved was passing the problem on to somebody else—and the customer was left to resolve the problem.
When a problem isn’t owned there’s trouble!
The danger of relying on a customer to resolve the problem is that they will focus on solving their problem and not the root problem. In the example above, the customer will be focussing on “Getting my parcel delivered as quickly as possible whilst spending the least amount of time on the phone as possible.” However, the organisation really needs to be focussing on the additional problem of “Why did the address corrupt during the order process, how do we prevent this from happening, and how many other customers are affected?” Sadly, so often front-line staff in organisations are trained to address the symptoms rather than the cause of problems. Encouraging problem ownership throughout an organisation can help to address this—and those on the front-line are often crucial and knowledgeable experts who can help solve and prevent problems recurring. They are well placed to own the initial problem, and escalate any other organisational issues that may require ownership at a different level.
Problem ownership is equally important on large-scale, ill-defined problems. Often these require the coordinated action of large groups of people. If nobody ‘owns’ and defines the problem, then there is the danger that there will be inconsistent and incoherent action—time will be wasted and the organisation will start to pull in different directions. Equally, there is a danger that several people will try to ‘solve’ the problem in different (and conflicting) ways and a turf war will ensue!
What this means for business and business analysis
A lot of time is spent in organisations solving problems. When we embark on a problem solving initiative—whether for our own organisation or for that of a client—it is crucial that we make sure the problem is owned and defined before we expend too much time and effort on a potential solution. Efforts spent in ensuring that everyone has a common, consistent and shared view of the problem early will reap rewards in the long run.
Do you have any suggestions or thoughts related to problem ownership or problem solving? I’d love to hear from you – please add a comment below!
If you’ve enjoyed this article don’t forget to subscribe.
This post was brought to you by IBM for MSPs and opinions are my own. To read more on this topic, visit IBM’s PivotPoint. Dedicated to providing valuable insight from industry thought leaders, PivotPoint offers expertise to help you develop, differentiate and scale your business
AR:
One extra thought on early ownership identification. As you know, another one of the BAs never ending list of obligations is the need to identify risk. The absence of an owner related to a problem under analysis with identified risks also then eliminates the early accountability to the risk mitigation….which might actually be to do nothing.
Doug
Thanks Doug, that’s a great point! Risk ownership is critical too.
Great article. We face this dilemma every day. But the article stopped short!! What techniques do you suggest to implement the ownership you suggest?
Hi VT, thanks very much for your comment, and I’m glad you found the article useful. What approaches and techniques are appropriate vary a lot by context, but in general terms I tend to find that spending time identifying the real (root) causes is important. In most situations this will be more complex or complicated than it first appears, and there may be a whole ‘mess’ of interconnecting causes, sub-causes and issues.
This is where techniques such as a fishbone diagram (Ishikawa), or a mutliple cause diagram, a rich picture, or a cognitive map can come in useful. These allow expression of the problem situation, but crucially allow the *connections* to be shown.
Once the causes and the interconnections of those causes have been identified, then the discussion can move on to ownership *and* of course on to possible interventions or changes.
I hope that this helps! Best of luck, and I hope you find some of the other articles on this blog interesting too.
Best regards, Adrian.
Thanks for this piece