Solution or Illusion? Achieving Better Outcomes With Pre-Project Problem Analysis

I have a confession to make. I absolutely love gadgets, and am drawn towards the novelty of shiny new tech products. I have been known to make purchases without really thinking through the practicality of the item I’m buying, which means I have a box full of tech products and gadgets that I rarely (if ever) use. There was a time when we had no fewer than three juicers in our house, which (as far as I am concerned) is three more than we’re ever going to need. Each of these products “seemed like a good idea at the time”, but were soon relegated to the depths of a dusty cupboard, never to be used again.

While most of the purchases I’m referring to here were small and inconsequential, a similar and more worrying pattern exists in organisations. Stakeholders often fall in love with the idea of a particular ‘solution’, long before an understanding of the context and the desired outcomes have been determined. If nobody has asked “why is change necessary” and “what benefits and outcomes are we seeking” then how on earth can we ever know whether the supposed “solution” will actually make things better? There’s a chance it’ll actually make things worse.

The Solution Illusion

This pattern of unconsciously assuming that a particular solution would work can lead to situations where teams end up delivering exactly what is specified, only to find out that it isn’t what people needed or expected.
Different stakeholder perspectives remain unheard, and there may be tacit disagreement on why change is necessary, what the scope is and how it’ll be delivered. If you’ve worked on a project like this, you’ll know how much painful conflict can emerge, often at the least convenient of times.
In this regard the ‘solution’ that is implemented isn’t really a ‘solution’ at all—the implemented change may have actually made things worse, with users shouting about how it doesn’t do what they need it to. The implemented product might remain unused, with stakeholders actively disliking it and finding ways to avoid
using it. It becomes an expensive mistake, and (metaphorically) collects dust, just like the unused shiny technical gadgets I mentioned earlier…
This is an extremely bad outcome. Time and money are wasted, but even worse stakeholder relationships are damaged as the product doesn’t meet expectations. It might well be ‘on time’ and ‘on budget’, but if nobody uses it, then it’s not going to be ‘on benefit’ and will likely be a costly mistake! But fear not, there is a way of pre-empting this…

The Importance Of Pre-Project Problem Analysis

Whether you are working in an agile, waterfall or ‘hybrid’ environment, whether you are following a project or product management lifecycle, there needs to be sufficient focus on up-front analysis. This short, sharp, pre-project problem analysis is the type of work that doesn’t need to take long, produces concise artefacts and can be done at pace. However, it ensures that key stakeholders reach agreement on the why, what and how of the project.

There are many techniques that can help us understand this, and in this article I’ll focus on just a few that can help explore and gain agreement on the why. Firstly, it’s important to explore the perceived problem situation from different stakeholders’ perspectives. Techniques like a multiple cause diagram, fishbone diagram, problem statements and many others can help here. These can lead on to conversations on what success looks like and how it can be measured. At this early stage, discussing Critical Success Factors (CSFs) and Key Performance Indicators (KPIs) can be extremely beneficial.

CSFs and KPIs are often discussed at organisational level, but they apply equally well at project or product level. A CSF is typically qualitative and not directly measurable, with each CSF having one or many KPIs attached to it. The KPI acts as the metric or measurement for the CSF. We might say, for example, after a project has been initiated we will offer “Excellent customer service” (a CSF). That is good to know, but it will be the KPIs that add a measurement to this. We might add a KPI of “Fewer than X complaints in every Y orders”.
Pre-project we might not have the data to add the numbers here (X and Y), but we have defined the scale of measurement that can be supplemented if the initiative goes ahead.
This may sound trivial but it is actually very important. Discussing metrics for success is a way of cultivating a conversation about outcomes. Quite often different stakeholders will have subtly (or sometimes radically!)
different views on what constitutes ‘success’, and this is best uncovered early. A stakeholder in sales might be looking for “increased sales”, whereas a manufacturing colleague might be looking for “better production forecasts”. These two outcomes might be compatible, but there would need to be a discussion. Even though these two stakeholders might agree at a surface level on what “solution” they want, in reality they want it for different reasons. This might affect whether the “solution” on the table is suitable.

By uncovering any differences in desired outcome early, there is time to get people round a table, discuss priorities, and agree on how to proceed. Not only this, it helps to understand the likely scope. A project that is aiming to “increase sales” will likely have a different scope to one that is also looking to enable “better production forecasts”. Knowing this early will help ensure a laser-like focus on requirements analysis later in the business change lifecycle.
It also helps us shift away from solution-centric thinking. Even if a stakeholder has a particular solution in mind (“we just need to buy this new IT system!”), talking about outcomes helps us encourage divergent thinking (“OK, so the IT system is one option, what other ways might there be of achieving these outcomes?”). This, in turn, can help us either validate that the original proposed idea is the best or will help us find a more suitable solution. We might even find one that is quicker to deliver and cheaper—and who wouldn’t want that!

Quick, Slick & Lightweight

Pre-project problem analysis has to be quick, slick and lightweight. I often describe it as taking a ‘thin slice’ through the why, what and how, taking into account different stakeholders’ perspectives. It’s often possible to summarise the key outputs onto a single page (with links to more detailed information if anyone wants it), and this ‘one pager’ acts as a decision-making aid for sponsors. If the project goes ahead, this one-pager becomes a useful traceability tool. If a requirement doesn’t map up to it, then it is very likely out of scope (or the target has moved, which usually requires a broader discussion) This is the kind of analysis that can be done at pace.

To borrow and embellish a phrase from the agile community it is about “just enough [analysis work], just in time”. It is the small up-front investment that means we can hit the accelerator hard, knowing we’re heading in the right direction. Even more importantly, it ensures everyone is on the same page and aiming in the same direction. It is a relatively small amount of effort that can make a significant difference, and well worth investing in!