Look Before You Leap: Pre-Project Problem Analysis: A Thin Slice Of The “Why, What & How”
A common challenge that faces change practitioners is the situation where a group of stakeholders decide on a solution early. There is nothing inherently wrong with this, the issue arises when a solution is seized upon before there’s a clear understanding of the outcomes that are being sought, and the problems or opportunities that are being addressed. In that situation there can be a real danger that each stakeholder has a slightly different expectation on what the chosen ‘solution’ will do and how it will benefit them. If these expectations aren’t clearly articulated then situations can emerge where people agree on the surface level but have vastly different underlying views. It can also lead to situations where the supposed “solution” actually makes things worse, or simply displaces the problem to somewhere else in the organisation.
Imagine a group of stakeholders who have decided that they want a new CRM system. It would be completely possible to launch a project to implement exactly what they’ve asked for (and migrate the existing data), but if questions weren’t asked about why they wanted a new system in the first place we might find that it doesn’t have the effect they were hoping for. Imagine a stakeholder says:
“Ah, I’m glad you asked me this! The reason we want a new CRM package is because our field sales team just won’t use our existing one. We’ve heard (XYZ CRM System) is really popular, so we thought we’d give that a go”
Clearly this is a provocative example, but it illustrates the fallacy of going ahead without understanding “the why”. In fact, we would certainly want to probe further, and ask why the sales team don’t use the existing system…. Perhaps it’s because the data is poor? Maybe they are field based, and it doesn’t work well on their mobile devices? Or maybe it’s just because they don’t see the value in using it at all (if that’s the case then a new system is unlikely to solve the problem!).
Without understanding these things better we could actually end up delivering a new IT system that makes things worse. We also need to keep in mind that the solution that has been suggested (an IT solution) is likely only part of a much wider situation involving processes, politics, people and much more besides. The best tech in the world is a wasted investment if people choose not to use it and develop their own workarounds instead (Excel macros anyone?!)
Slowing Down Before Hitting The Accelerator: Understand “The Why”
This is where change practitioners such as business analysts can add significant value in the pre-project and discovery phases. It is valuable to take a short period of time to understand different stakeholders’ perspectives on the situation. Using techniques such as 5-whys, a fishbone diagram, a multiple cause diagram and others can help gain a broader and richer understanding—and crucially a shared understanding of the situation.
One technique of particular merit is the problem statement. Quite often stakeholders are seeing things very differently but this doesn’t come to light until they start to articulate their view of the problem. There will often be arguments over particular words, and this is actually a good thing—it is getting different understandings and perspectives out on the table early. A possible format to utilise for a problem statement is:
The problem of… A short description of what is seen as most problematic.
Is affecting… Who is it impacting? Who would benefit if it were ‘solved’?
The impact of which is… What is the negative impact it is causing?
A successful solution would… What attributes would a successful solution have? What outcomes are being sought?
Although a problem statement is simple, it is by no means simplistic. It is often difficult to create, and takes iteration and discussion. This can be done relatively quickly when the stakeholders are on-board. It then acts as a crucial traceability artefact which helps manage scope; imagine further down-stream prioritising a requirement and asking “can you help me understand how this requirement will improve/help solve this problem?”.
A Thin Slice
However, this initial pre-project work can’t be overly time-consuming or onerous. It is about getting a ‘thin slice’ of the why, the what and the how. A problem statement, perhaps with some Critical Success Factors (CSFs) and Key Performance Indicators (KPIs) gives an indication of why the change is necessary and the outcomes that are being sought. To create an initial scope of what might need to change, something like a business use case diagram or context diagram might be used. Then, of course, discussions can centre on how the change should be implemented.
Of course, life is never quite as simple as we might like to think, and in reality the ‘why’, ‘what’ and ‘how’ are blurred in people’s minds. As practitioners we will be laddering up and laddering down that hierarchy to obtain an initial ‘thin slice’ which solidifies a unified understanding.
This ‘thin slice’ can typically be presented in a very concise way, for example in a very lightweight document that ensures that people are literally on the same page. It provides the certainty needed to hit the accelerator with confidence. If an agile approach is being used, the team will have a firm basis on which to form a backlog. If it is a more predictive or waterfall approach, then there’s the foundation for a project initiation document or charter.
It is ironic that there is sometimes reluctance from some stakeholders to engage change practitioners at such an early stage in the business change lifecycle, as this is an area where we can make a significant positive impact. Pre-project problem analysis is one way of assuring the project starts on the right track!