By Adrian Reed

July 2024

Upcoming events by this speaker:

October 21-22, 2024 Online live streaming:
Pre-Project Problem Analysis

Successful Projects Start With “Why”

Projects are usually launched in response to some kind of challenge or opportunity. Perhaps there is a need to increase efficiency, replace an old legacy IT system, or launch a new product into a new market. There will undoubtedly be a set of outcomes and benefits sought by the project’s sponsor, but it is no secret that many projects suffer difficulties during their execution and unfortunately some projects fail. In fact, a project could be on time and on budget and still be a failure if it doesn’t actually meet the needs of the business and achieve the benefits that were projected.

A key discipline that helps avoid these situations is pre-project problem analysis. This typically starts before the project is formalised, and seeks to understand the nature of the problem being solved (or the opportunity being pursued).  Crucially, it aims to avoid early solutioneering.  Seizing upon a solution too early, before there is a shared understanding of the problem or opportunity, can lead to significant problems as the project progresses.

Avoiding the “Solution Illusion”: The dangers of seizing on a solution too early

This might sound counterintuitive, after all surely deciding on a “solution” is a good thing? While that is partially true, too many projects become completely solution focussed rather than being outcome focussed. The entire team is diligently working to deliver on-scope, on-time and on-budget…. while inadvertently losing sight of the benefit that they are trying to deliver. This can lead to a situation where the project has immaculately “green” status reports, but some sinister surprises await the team when it actually goes live.  There’s that old danger of delivering everything they ask for only to find out (sadly too late) that this wasn’t what they actually needed.

This is just as true for smaller iterations and feature requests too. Imagine the following request comes in from a stakeholder:

“We need another field on the web form, which maps to the database. It should be a drop-down list.”

You will almost certainly have questions about this statement. You’d likely ask what should be in the drop-down, what question should appear on the website etc. Yet this is an example of solution-centric thinking happening before an understanding of the true need/desired outcome has been discussed.  It is completely natural, as human beings we seem to be natural problem solvers. 

However, there is a magic word which can help break us out of this thinking: “Why”.

Asking the stakeholder why they want this field might uncover the fact that they want to determine the source of business for orders that come in, so that they know what percentage of business is generated from web advertising, social media and so forth.  Asking “why” again might determine that what they really want to do is optimise their marketing spend.

Here we see an example where they have come to us with a solution (a new field). Yet that new field might or might not meet their actual desired outcome (provide data to help them optimise their marketing spend).  In fact, there might be many other ways of providing them with the data they need… some of which might be quicker, slicker and better than the idea they first thought of!

Scale This Up: Imagine A Project That Solutioneered Too Early

The example of a field on a database probably feels really small and insignificant. Yet the same pattern occurs at much bigger levels too.  Take the following examples:

  • “We’re launching a project to implement a CRM system” (why did you choose a CRM system? What outcomes are you hoping for? Might there be other changes, as well as a CRM system, that are needed?)
  • “We’re migrating from system X to system Y” (what outcomes are you hoping for? Are you mitigating risk? Increasing productivity? Something else? Does everyone agree?)
  • “We’re implementing robotic process automation” (are the processes streamlined already? If not, is there a danger we’re automating bad processes? What prompted this? What problem are you trying to solve?)

These are just some hypothetical examples, but I am sure you get the idea. A danger of progressing projects like this, without discussion of the outcomes being sought is that stakeholders will have their own implicit view on what should be achieved. Because this is implicit and never discussed, it tends to emerge later, through conflict. The scope starts to creep, and eventually the project pulls itself apart.

Stakeholders might agree, on a surface level, that they want (or need) a new CRM system. Yet they might want this for very different, and sometimes conflicting reasons. Without analysis and discussion, it’s impossible to know whether everyone is on the same page. In fact, without knowing what problem they are trying to solve, it’s impossible to know whether a CRM system is a suitable solution anyway!


Thin Slicing: Start With Why

This is where pre-project problem analysis comes in. Spending a short amount of time up-front to understand why an initiative is being progressed yields significant benefits in the long run.  Yet, things don’t stop there: it’s also possible to take a thin slice through the why, what and how of a potential project. Quickly and concisely gaining a shared understanding of why (the outcomes being sought), what (the conceptual scope) and how (possible solutions that can be considered). 

This can culminate in a short, succinct document that ensures everyone is on the same page. This project concept summary document  in turn becomes a guiding beacon throughout the initiative.  There’s not a mandated or fixed format, but it might include things such as:

  • Problem statement: A concise, precise definition of the problem being solved
  • Outcomes: Critical Success Factors (CSFs) and Key Performance Indicators (KPIs) to show what improvement is sought
  • Conceptual scoping diagram: A very high level diagram, such as an initial Business Use Case diagram, that shows the likely scope
  • Solution List: A list of potential solutions that are deemed to be potentially feasible and desirable

Clear The Roadblocks: Accelerate With Confidence

Pre-project problem analysis is relevant for small initiatives, large initiatives, agile, waterfall or hybrid approaches. When done well it involves a range of complementary analysis techniques that ensure people are on the same page.  It helps clear the roadblocks so that the project can accelerate with confidence, knowing that stakeholders have a shared view on what they are delivering.

It also provides an excellent opportunity to garner engagement early in the project or product lifecycle. Since key stakeholders will be actively involved, it provides the opportunity for people to work together and co-create a shared view on scope. It helps avoid situations where people fixate on a particular solution, instead subtly and empathetically shifting them towards thinking about problems, opportunities and desired outcomes. It is a sound investment in time that will likely save time in the long run.