Wrong decision or wrong problem?
Cathryn Lancaster, a Principal Consultant at MartinJenkins, urges governors to keep their eye on something that can often get lost along the way in major projects – the problem the project is supposed to solve.
The fact that your organisation is considering an investment in something new or making some other kind of change suggests there’s some problem you’re trying to solve, some need you’re aiming to satisfy. It could be something is broken or no longer fit for purpose. It could be that your competitors are gaining market share from you because they’re more efficient. Either way, whatever response you choose, it needs to match the problem.
That sounds obvious, but too often we see organisations being lured into, for example, a shiny new technology investment that ultimately doesn’t address the organisation’s fundamental problem.
Projects can often end up in these positions when they’re not focussed on problem solving. It may be that the original problem definition has been lost sight of along the way – or it may be the problem was never properly defined and understood in the first place.
In this article I’ll cover some key issues and warning signs that those in governance roles should keep an eye on in guarding against the risk of losing sight of the problem.
"What’s your problem?” – Any analysis of options for a second Auckland harbour crossing needs to begin with a strong problem definition
DEFINING THE PROBLEM WELL AT THE OUTSET
When you understand your problem, you’re more likely to generate a fulsome set of options from which to select your preferred solution. If you don’t get the problem definition right, you can miss potential options – often the less obvious, more innovative options that provide the best overall value, such as non-build alternatives in construction projects.
There are different techniques for defining your problem, but agencies providing services in the local- and central-government sectors always need to have a solid understanding of Treasury’s Better Business Case Framework. It’s logical and pragmatic and will underpin your whole business case from go to whoa.
Done well, the problem definition phase is also often a great way to focus the people who are involved with and affected by the change. It helps create a good case for change and a shared understanding.
A four-year-old's approach to defining the problem
Irrespective of the size and type of your organisation or project, I believe the best approach to defining the problem still lies in the Multiple Why’s approach, where you apply the relentless questioning of a four-year-old.
Take the issue of Auckland’s second harbour crossing. A less curious approach to defining the problem could see you arrive at the following:
“Auckland needs a second harbour crossing because the existing harbour bridge can’t take enough cars, and you can’t add any more lanes to the bridge.”
By contrast, the Multiple Why’s approach leads you to dig several layers deeper:
"We need a second harbour crossing."
Why?
"Because it takes too long to get across it."
Why?
"Because too many people need to get across it."
Why?
"Because they need to get to the other side, of course."
Why?
"Well … mainly because so many of them live on one side of the harbour but work or play on the other."
When you apply the Multiple Why’s test, you can end up contemplating a very different problem from the one that first seemed the most obvious.
REVISITING THE PROBLEM
Having defined the problem well at the outset, don’t just stick this definition in a drawer – keep it front of mind throughout the project. This will serve you better in the long term, and counteract any bias towards a particular solution.
There are a number of points in particular when it will be important to stop and reflect on the problem definition. Most obvious is when a project has gone over budget or fallen behind schedule. This is often taken as a trigger to look at the scope of the solution, but adding an extra step and stepping back further to look at the initial problem can be more effective and efficient.
Other less obvious triggers for revisiting the problem are when there’s been high staff turnover, as the problem may have gotten lost in multiple handovers to new project teams, or when you’re about to start a value engineering exercise to reduce cost and scope.
When you have high staff turnover, there’s a risk that the problem may get lost somewhere amidst the multiple handovers from one project team to another
A change in policy or regulation may also prompt another look at the problem, as the context or nature of the problem may have changed.
Going back to basics
Once you identify a need to revisit the problem you’re trying to solve, think about these potentially relevant sets of factors:
· Situational – Do the assumptions that underpin your investment still hold, or has a change in context changed the problem itself? For example, investments decided on pre-COVID to solve office space problems took on a new complexion after the pandemic and the rise of remote working.
· Technology – Has new disruptive technology reduced the size of the problem or provided other solutions? For example, new EV charging technology has developed alternative approaches to public infrastructure charging.
· Competing priorities – Are there now bigger problems that need solving? For example, a natural disaster might have changed the focus from investing in additional infrastructure to repairing existing infrastructure.
· Competitors – Have your competitors started to do things differently so that the original problem is now irrelevant or has been superseded by other competitive advantages?
· Affordability – What if it turns out you can’t afford the planned version A of the solution, and can only afford the lesser version B? The key question is whether version B will still solve the problem.
Understanding the barriers to revisiting the problem
The inertia created by a project once it’s underway can be very powerful. After putting a lot of effort into identifying a solution, project teams can be reluctant to acknowledge changes in context – they’ve become attached to the chosen solution and what they’ve promised to deliver. The debate around the Cook Strait ferries is a recent high-profile example.
Project teams may also be reluctant to revisit the approval process. Approval processes are often protracted as organisations grapple with how to spend their scarce resources, and getting people to contemplate navigating these processes again can be a big ask.
Decision makers may also fall into the “sunk costs” fallacy. The amount of money already spent is often seen as the reason to continue with a project or investment, even though costs incurred so far should be seen as irrelevant for rational decision making.
Cathryn Lancaster, a Principal Consultant at MartinJenkins
PREVENTION’S BETTER THAN CURE: KEEPING THE PROBLEM FRONT OF MIND
Embedding the following practices into your normal business cadences will go a long way to making sure you always keep an eye on the fundamental problem.
Make sure the problem is understood and communicated up-front as the reason for the investment
Involve your stakeholders and funders in the problem definition stage, just as much as you involve them in developing user requirements or analysing options. You need to ensure that defining the problem is much more than just an intervention logic mapping exercise.
For public-sector agencies the decision-making environment is also changing, so that Cabinet will now be scrutinising many investments earlier on. Treasury recently implemented changes to the way government makes decisions on business cases, so that for significant investments Cabinet will be considering your organisation’s Strategic Assessment, the first step in the Better Business Case Framework.
Identify when and how you’ll reassess the problem after you get the go-ahead
Schedule these assessments as part of your regular reporting rhythm. Develop reporting that goes beyond metrics for time and budget to assess progress in a third dimension: progress against solving the problem.
Identify roles for different people and parts of the organisation and hold them accountable
First is delivery – empower someone senior in the project team to be responsible for keeping the project focussed on the problem and for reporting on progress in resolving it.
Then leadership – leaders need to be bold and brave enough to reassess the project when necessary, irrespective of sunk cost and approvals processes that have already been navigated.
Finally the governance roles – governors need to have visibility over and sign-off on the problem definition stage, rather than waiting until a business case is ready to be approved. The governance function needs to hold the leadership to account for achieving the objectives of the investment, rather than just focussing on milestones.
“Solution” (noun) – "A means of solving a problem or dealing with a difficult situation"
Today, even the vocabulary of business writing reflects the too-common tendency for projects to drift away from a focus on problem solving. The word “solution” has become overused and debased so that it seems now to be the default way of referring to any product or service. In our language we’re losing a strong sense that “solution” always goes with an implicit flipside “problem”.
The kinds of frameworks and tools I’ve described here – like clearly assigning responsibility for reporting on resolving the core problem – will help you and your team stay focussed on the fundamentals, including calling out a chosen “solution” that no longer solves the original problem.
You can receive our insights delivered directly to your inbox