Expert's Opinion - The Danger of Jumping to a Solution and the importance of Pre-Project Problem Analysis
Do you speak in the language of 'problem'? In this exclusive article on The Master Channel, Adrian Reed explains how you can start the process of organizational change right. Sounds a bit abstract, right? With his practical example, you'll understand.
We’ve probably all worked in situations where the word ‘problem’ is seen as a dirty word. This is understandable to some extent—after all, discussing a problem situation seems a lot less attractive than getting on and implementing the ‘solution’ that will help improve things. It sometimes seems that as human beings we are wired to think in solutions—we fall into repeated patterns where we make implicit assumptions over how to best ‘solve’ things. It seems that by default we think and speak in the language of ‘solution’ rather than ‘problem’.
This might sound abstract, so let me give you an example. A few months ago, my car reached the end of its serviceable life. I’ve never really enjoyed driving, and since I live in a densely populated city, I hardly ever drive anyway (I live an 8-minute walk from a train station). However, there are times when the convenience of a car is compelling, so when my (very old) car finally broke my initial ‘solution-centric' thought was ‘What type of car shall I buy to replace it’?
I was looking online at used cars, deciding what color and model I wanted when a crucial thought struck me: Why on earth am I buying a replacement car at all? What are my actual needs here? And are there other options that I haven’t considered? I looked back over the car’s paperwork—I drive significantly less than 2,000 miles per year. I drive on average once every two weeks, yet have many of the same ‘fixed costs’ as if I drove every day (insurance, tax, servicing, etc.). What if I used that budget differently, and looked for different ways of meeting my core ‘need’? After all, my core ‘need’ could be defined as ‘convenient transport between two points to allow social/business interactions to take place’.
This led me to generate a whole range of different options (use public transport more frequently, get taxis, hire a car when needed) and I ended up joining a car club that rents cars by the hour. I now have a ‘car-as-a-service’, on-demand, whenever I need it. A completely different solution that is (a) better and (b) cheaper than the one I had initially assumed. A textbook win/win situation.
Beware The ‘Organisational Silver Bullet’
The example of my car might seem nuanced, but a similar pattern occurs in organizations. Stakeholders seize upon solutions. Perhaps you’ve seen this too: stakeholders appear to fall in love with a particular solution or specific IT system, asking that it is implemented, and assuming that it’ll cure all of their organizational woes. This is completely understandable—we all seem to think in this way—but it is one area where as BAs we can really help out. If we go ahead and implement the solution that we are asked to without truly understanding the organizational, stakeholder and broader ecosystem needs then there is a danger that we’ll deliver precisely what is asked for... only to discover it doesn’t meet the actual needs.
Even worse, we might deliver something that actually makes things worse because the knock-on impact wasn’t considered (improving the sales process is fine, but if your operations team can’t service the customers then you have created a different issue!). Or we might even discover, mid-way through a project, that different stakeholders have very different perspectives on why the initiative is being pursued. I suspect we’ve all experienced this, and the inevitable scope creep that it can lead to.
Sadly, there is no simple antidote to these organizational issues, but one discipline that can help a great deal is that of Pre-Project Problem Analysis. When working with stakeholders early in the business change lifecycle, we can (amongst other things) aim to get a thin-slice of the ‘why’, the ‘what’ and the ‘how’ of a project. The ‘why’ addresses the purposes of the project in the first place, the ‘what’ outlines the conceptual scope, and the ‘how’ identifies potential options (without prematurely jumping to a single ‘solution’). We explore high-level needs and gain consensus—or at least a situation that everyone can live with—before moving forward. This analysis can be distilled into a concise yet precise Project Concept Document which ensures that everyone is on the same page. Techniques such as fishbone diagrams, problem statements, critical success factors, business use cases, and many others can be extremely helpful here.
In conclusion, when it comes to organizational change, there is a lot to be said for starting right. A building without foundations is likely to crumble. A change initiative is no different, and as BAs, we are well-placed to help build those firm and lasting foundations.