“If I had an hour to solve a problem, I’d spend 55 minutes thinking about the problem and 5 minutes thinking about solutions.”
It turns out, Einstein possibly didn’t say this, despite it being one of his more famous ‘quotes’. However, that doesn’t change its merit and the wide acceptance that problem definition is where value starts. Nevertheless, we find you still have to make a conscious effort to avoid diving in and ‘getting things done’, even after years of experience.
Problem definition is a broad subject and most would agree on the importance of developing a quality project charter to better understand the problem that needs to be solved. We are certainly strong supporters of this approach…if it is practical and there’s time to facilitate it. But what happens when a problem is not well understood, and there’s extra urgency, and the time to understand and scope the problem in detail is simply not available? From our experience, when time is short, one of the biggest improvements most organisations can make when delivering improvement work is actually in this area of better understanding the problem they are trying to solve.
A simple framework
There are four questions we use in time-constrained situations to understand the problem our clients are trying to solve:
- Can the problem be clearly articulated? Can someone succinctly define the gap in performance we’re trying to improve? You get bonus points if there’s data to support it. Acknowledging the problem is the first step in solving it. If a team can describe the specific problem, it means they understand the need to change – and it helps when communicating during implementation.
- Do we understand the timeframe over which the problem occurred? For example, is it a systemic problem or are we reacting to a high-profile, one-off event? This provides the first insights into how you might solve the problem. A one-off event might consider an approach heavily drawing on root cause analysis, whereas systemic problems may draw more on other methods.
- Can the gap in performance be linked to a business process? This helps to begin defining the scope, size and complexity of the problem. For example, does it need to be broken down into smaller projects run simultaneously? This also helps define who may need to be involved in each project. Clarity now will prevent complexity and potential rework later in the problem-solving process.
- Can the problem and process be linked to a business outcome? For example, does it relate to an increase in throughput, a cost saving or reduced business risk? All improvement projects require leadership support and take time. When it gets hard, or commitments waiver, reminding people of the end goal and business benefits helps. It’s also a quick test to ensure you’re working on a real business problem and not a pet project or ‘today’s crisis’ (which become projects at high risk of losing leader support and interest over time).
These questions don’t replace the complexity and detail of a properly defined project charter. However, for an initial assessment and sizing up of a problem, we find they are a great place to start. If you can’t answer those four questions clearly, tread carefully.
A real-life example
One of our projects was to increase truck availability for a mining operations team. We met with the team and they were adamant they knew where the problem was – if maintenance could just deliver their plan and only have the machine for the promised time, overruns would stop and they’d see a quick increase in availability. They even had data to show how long the truck was ‘offline’ for planned maintenance. In their eyes, they could clearly articulate the problem, had data to support it, could demonstrate the ‘problem’ over a sustained time and believed the process causing the problem was someone else’s responsibility. Sound familiar?
The maintenance team had a different story. They could clearly show their own data – how long they needed the machine and how consistently they met the target. So where was the problem? The problem was in the handover of the machine and the differences in how operations and maintenance were measuring it. Once the operations team parked the truck on the go-line, or at the wash pad, they considered this ‘handed over’ and their clock started ticking. In contrast, the maintenance team started their clock when the machine entered the workshop. What neither team was accounting for was washing the machine prior to it entering the workshop. And that washing was completed by contactors whose time no one was factoring in. To make matters worse, the contractors were not involved in any planning activities, or any status meetings during the week to notify them of plan changes.
Spending time up front defining the problem revealed an issue with planning and the communication of machine handover. That was a relatively faster fix that allowed us to reassess and then tackle the next problem impacting machine availability. Interestingly, it also turned a project with an operations team – which looked like a project with a maintenance team – into a project shared between a maintainer, production planner and contractor.
Time taken at the start to properly define a problem, commonly saves time and effort later during the problem-solving process. Yes, robust, detailed project charters are ideal, but sometimes you have to go with what the circumstances allow. Having enough discipline to pause and use a framework like the four questions above, to adequately define the problem will give confidence that effort and investment are being applied in the right places.
Photo by Olav Ahrens Røtne on Unsplash
