One of the joys of Project Management is the constant need for problem-solving.
The novelty and uncertainty of a project environment constantly throw up surprises. So, a Project Manager needs to be adept at solving problems.
In this article, we look at problem-solving and offer you a structured, systematic approach.
Problem-Solving Methodologies
There are a lot of established approaches to structured problem-solving. And there is a good chance that, if you work in a large organization, one of them is in common use. Indeed, some organizations mandate a particular problem-solving methodology.
For example, in automobile manufacturing industries, the 8 Disciplines or 8-D methodology is used widely. And anywhere that Six Sigma is an important part of the toolset, you will probably find the DMAIC method of problem-solving.
Others I like include Simplex and the catchily-named TOSIDPAR. And there are still others that, whilst highly effective, are also assertively protected by copyright, making them hard to discuss in an article like this. I’m thinking of you, Synectics.
Strengths and Weaknesses
All of these methodologies offer great features. And curiously, while each one feels complete, none offers every step you might want. The reason is simple. Each approach is tailored to focus on a part of the problem-solving process. Other parts are either outside their remit or receive less emphasis.
Comparison of Approaches
The consequence is that every structured approach can miss out steps that are important in some contexts. To illustrate, let’s compare the four methodologies I have mentioned.
Resolving the Gaps
At OnlinePMCourses, we use an 8-step problem-solving approach that covers just about all of the steps that these four methodologies offer. But, before we address these, let’s take a look at some practical approaches to applying problem-solving.
Practical Implementation
Some of the best examples of project problem-solving are in two of my favorite movies:
Waigaya
In the Apollo 13 movie, there’s a scene where one engineer dumps a big pile of stuff onto a table in front of a bunch of his colleagues.
‘The people upstairs handed us this one and we’ve gotta come through.
We’ve gotta’ find a way for this {holds up square thing] fit into the hole for this [a round thing] using nothing but that [a pile of random-looking stuff].
Let’s get it organized.’
They all dive in and we hear a hubbub.
Hubbub
Hubbub is about as reasonable a translation of the Japanese onomatopoeic word Waigaya as I can find. The idea behind Honda’s Waigaya approach is that everyone on the team gets to contribute to the conversation. But it isn’t a simple free-for-all. There are rules:
There is a fabulous article that is well worth reading, at the Strategy & Business site.
Gemba
In The Martian, the character Mark Watney is stuck with his problem. This makes it immediate, and also easy to see the context clearly. Another idea from Japanese manufacturing harnesses the value of getting out from behind your desk and going to where the problem is. It’s called ‘going to the gemba’ – literally, ‘going to the place’.
There is magic, when we get up, move about, and gather where the problem is happening. Going to the gemba and convening a waigaya is a great way to kick-off even the most complex problem-solving. Unless, that is, the gemba is halfway to the moon, or on Mars.
Recommended 8-Step Problem Solving Method
To reconcile the different methodologies for solving problems on projects, I have developed my own approach. It was tempting just to take the 17 steps in the chart above. But I also found that those four still miss some steps I find important to remember.
Would anyone think a 20-step Problem-solving Process Makes Sense?
I doubt it.
So, I decided to wrap some of the steps into 8 main steps. This gives us an 8-step method, which has everything that I have found you will need for problem-solving in a project context.
In the figure below, you can see those 8 steps as the bold boxes, with the subsidiary elements that form parts of those 8 major steps in fainter type.
So, in the rest of this article, I’ll summarize what I mean by each of these steps.
1. Define the Problem
Defining your problem is vital and takes up four of the 9 steps in the 8 Disciplines approach. But, on a project, this is often clearer than a new problem arising out of the blue in a manufacturing context, where 8D is most popular. So, I have folded the four parts into one step.
Understand the Context
Here’s where you need to find out how the problem impacts the whole of your project, and the circumstances in which it has arisen.
Gather Your Team
On a small project, this is likely to be all or most of your project team. For larger projects, this will center around the team delivering the workstream that the problem affects. For systemic problems, you’ll be asking work-stream leaders to supply expert team members to create a cross-cutting team. We sometimes call these ‘Tiger Teams’ – for reasons I can’t tell you, I’m afraid!
To support you in this stage, you may want to take a look at these articles:
Define the Problem
It’s often reasonably easy to define your problem in terms of ‘what’s wrong’. But it pays to be a specific as possible. And one thing that will help you with the next main step (setting an objective) is to define it in terms of what you want.
I like the discipline of defining your problem as:
How to…
Safety First
When I first encountered the 8 Disciplines method, the step that blew me away was D3 – Contain the Problem. I’d not thought of that before!
But it’s clear that, in many environments, like manufacturing, engineering, and transportation, solving the problem is not your first priority. You must first ensure that you do everything possible to limit further damage and risk to life and reputation. This may be the case on your project.
2. Set An Objective for Resolving the Problem
With everything safe and the problem not getting worse, you can move forward. This step is about defining what success looks like.
And, taking a leaf out of the TOSIDPAR approach, what standards, criteria, and measurable outcomes will you use to make your objective s precise as possible?
3. Establish the Facts of the Problem
I suppose the first step in solving a problem is getting an understanding of the issues, and gathering facts. This is the research and analysis stage.
And I like the DMAIC method’s approach of separating this into two distinct parts:
4. Find Options for Resolving the Problem
I see this step as the heart of problem-solving. So, it always surprises me how thin some methodologies are, here. I split it into four considerations.
Identify Your Options
The creative part of the problem-solving process is coming up with options that will either solve the problem or address it in part. The general rules are simple:
Rule 1: The more options you have, the greater chance of success.
Rule 2: The more diverse your team, the more and better will be the options they find.
So, create an informal environment, brief your team, and use your favorite idea generation methods to create the longest list of ideas you can find. Then, look for some more!
Identify your Decision Criteria
A good decision requires good input – in this case, good ideas to choose from. It also needs a strong process and the right people. The first step in creating a strong process is to refer back to your objectives for resolving the problem and define the criteria against which you will evaluate your options and make your decision.
Determine your Decision-makers
You also need to determine who is well-placed to make the decision. This will be by virtue of their authority to commit the project and their expertise in assessing the relevant considerations. In most cases, this will be you – maybe with the support of one or more work-stream leaders. For substantial issues that have major financial, schedule, reputational, or strategic implications, this may be your Project Sponsor or Project Board.
Evaluate your Options
There are a number of ways to evaluate your problem resolution options that range from highly structured and objective to simple subjective approaches. Whichever you select, be sure that you apply the criteria you chose earlier, and present the outcomes of your evaluation honestly.
It is good practice to offer a measure of the confidence decision-makers can have in the evaluation, and a scenario assessment, based on each option.
5. Make a Decision on How to Resolve the Problem
We have done two major articles like this one about decision-making. For more on this topic, take a look at:
There are two parts to this step, that are equally important.
Documenting your Decision
Good governance demands that you document your decision. But how documentation to provide is a matter of judgment. Doubtless, it will correlate to the scale and implications of that decision.
Things to consider include:
6. Make a Plan for Resolving the Problem
Well, of course, now you need to put together a plan for how you are going to implement your resolution. Unless, of course, the fix is simple enough that you can just ask your team to get on and do it. So, in that case, skip to step 7.
Inform your Stakeholders
But for an extensive change to your project, you will need to plan the fix. And you will also need to communicate the decision and your plan to your stakeholders. Probably, this is nothing more than informing them of what has happened and how you are acting to resolve it. This can be enormously reassuring and the cost of not doing so is often rumours and gossip about how things are going wrong and that you don’t have control of your project.
Sometimes, however, your fix is a big deal. It may involve substantial disruption, delay, or risk, for example. In this case, you may need to persuade some of your stakeholders that it is the right course of action. As always, communication is 80 percent of project management, and stakeholder engagement is critical to the success of your project.
7. Take Action
There’s an old saying: ‘There’s no change without action.’ Indeed.
What more can I say about this step that will give you any value?
Hmmm. Nothing.
8. Review and Evaluate Your Plan
But this step is vital. How you finish something says a lot about your character.
If you consider the problem-solving as a mini-project, this is the close stage. And what you need to do will echo the needs of that stage. I’ll focus on three components.
Review and Evaluate
Clearly, there is always an opportunity to learn from reviewing the problem, the problem-solving, and the implementation, after completion. This is important for your professional development and for that of your team colleagues.
But it is also crucial to keep the effectiveness of your fix under review. So, monitor closely, until you are confident you have completed the next task…
Prevent the Problem from Recurring
Another phrase from the world of Japanese manufacturing: ‘Poka Yoke’.
This is mistake-proofing. It is about designing something so it can’t fail. What stops you from putting an SD card or a USB stick into your device in the wrong orientation? If you did, the wrong connections of pins would probably either fry the memory device or, worse, damage your device.
The answer is that they are physically designed so they cannot be inserted incorrectly.
What can you do on your project to make a recurrence of this problem impossible? If there is an answer and that answer is cost-effective, then implement it.
Celebrate your Success in Fixing it
Always the last thing you do is celebrate. Now, when Jim Lovell, Jack Swigert, and Fred Haise (the crew of Apollo 13) returned safely to Earth, I’ll bet there was a big celebration. For solving your project problem, something modest is more likely to be in order. But don’t skill this. Even if it’s nothing more than a high five and a coffee break, always ensure that your team knows they have done well.
What Approach Do You Use for Problem-Solving?
How do you tackle solving problems on your projects? Do tell us, or share any thoughts you have, in the comments below. I’ll respond to anything you contribute.
Great structure, Mike. We had a problem once that suited the “contain” step quite well. Lubricating oil and hydraulic fluid, from the same supplier, had been packaged incorrectly. A tech went to add oil to an aircraft’s engine, but dropped the can onto the concrete, and noticed red hydraulic fluid spill out! Obviously there’s now the risk that people have been inadvertently adding hydraulic fluid to aircraft engines… not good. It was actually FAR more important to contain this is real time so that aircraft, some of which could be airborne, could be safely grounded/quarantined. Resolving the subsequent ramifications could then be accomplished in “slow time” with some deliberate planning/execution.
Thank you very much. That’s a powerful illustration and hopefully the incudenbt did not cause any loss of life or serious damage.