Problem Solving Methodology

Written by Rob Hulme

Problems, problems, problems.
At a fast-paced tech company like L&W, there’s always a problem to solve, but how do you recognise what is, and what isn’t, a problem?  How might you go about solving it, especially when in unfamiliar territory or faced with a mass of “data” and opinions in a forum with multiple people?  This is where formal problem-solving methodology is always useful.  There are various frameworks in the industry, so let’s keep this high level as they’ll all have a lot in common; often the methodology has been formulated and developed by interviewing people with a reputation for solving problems and labelling up good and common industry practice.

So, what is a problem an “issue”/incident, not a problem in the ITIL ?  Actually, this is quite an interesting question, because sometimes, you don’t really need to solve anything to correct a situation.  If you consider a problem to be an issue you have to spend some time on to solve, then there are quite a few scenarios that don’t meet the formal criteria.  A problem must have all 3 of these aspects be true:

1. A deviation of the (measurable) ACTUAL, from the (measurable) SHOULD (or, to put it another way, it should be doing this, but it’s actually doing that);
2. You don’t know the root cause; and
3. You need to know the root cause.

Number 3 is quite noteworthy, especially in the ITIL world.  If the incident can be resolved by a service restart or a ctrl-alt-del like action, then great, job done, service restored – no problem J.  We can investigate the underlying root cause later, but for now, the SHOULD and the ACTUAL are aligned (it should be doing this, and now it is!).

In a mass of confusion, where do you start?

A good first step is with the question “what’s the problem we’re trying to solve?”  Seems obvious right, but you would be amazed at how many situations exist where no one can articulate the answer to that question.  If faced with this scenario, the ideal place to begin is to list concerns and from those concerns, separate and clarify, and derive the problem statement(s) in an object-defect format (the thing having the issue, and what that issue is).  From there, consider these questions; document the answers:

• When did the problem start?
• When’s the problem going to start (if alarm and graph trend)?
• Where’s the problem; where isn’t the problem (differences can often suggest clues to potential solutions)?
  • This is a lifecycle question, not necessarily a geographical one.
• What’s changed (always ask this one!)?
• Where else might we have this issue (now)?
• When might we have this issue (in the future)?
• What other problems might this cause? (definition of “done”; think beyond the fix – time, environment)?

I find the structure really accelerates the whole process, keeps the investigations on track and supports a controlled documented briefing to new / additional members of the Investigation Team.  There are multiple online references to problem solving methodologies; I thoroughly recommend Googling “formal problem-solving methodology” to get started…

The opinions expressed in this blog post are strictly those of the author in his personal capacity. They do not purport to reflect the opinions or views of Light & Wonder or of its employees.