Imagine the scene: You’re waiting at a coach-station, about to embark on a long (and expensive) trip. It’s 4am in the morning, it’s dark and raining so the visibility is poor—meaning you can’t read any of the timetables or travel information. You’re expecting a coach will arrive soon. And, after a short wait, it does.
However, the front of the coach has a route number but no destination name, so you aren’t sure whether the coach is heading in the right direction. You scan the coach station and see a variety of other people and members of staff mulling around. What would you do?
If you are like many people, I suspect you would ask a member of staff, a fellow passenger or the driver to confirm which destination this coach was headed towards. You might also ask for information about the route it is taking, the cost, and when it is due to arrive. Yet, whilst cost and time will be important to you – getting to the right destination is the key. A cheap, quick coach ride in the opposite direction will likely be a bad thing—you’d end up further from where you want to be!
Agreeing the destination is crucial
This focus on destination is important on business initiatives and projects too. When initiating a project or initiative, an organisation wants to get somewhere; there is a desired outcome that our stakeholders are seeking. Yet often, when time is short (as is so often the case), there is a temptation to skip over (or race through) discussions which refine the outcome. Indeed, as BAs and change practitioners we may find our stakeholders press for estimates, requirements and solutions first.
Yet a trap awaits organisations and teams that do not spend time concisely and precisely agreeing the outcomes that they are seeking. So often there can be tacit agreement on project outcomes—on the surface it appears that everyone agrees. Yet, when we get into the detail of the project we discover very different perspectives on what should be delivered. This difference may have bubbled beneath the surface for weeks or months, and by this point may be costly to resolve. If it had been resolved up front it would have saved time and effort.
Take this theoretical example. Imagine two senior stakeholders on a project in an insurance company:
Manager A: We’ve recently seen a drop in revenue. Our core problem is targeting and retaining the right policyholders (customers). We need the ability to segment our customer base, enabling us to effectively (and regularly) send relevant personalised messages and offers to selected customers. This will lead to increased revenue.
Manager B: We’ve recently seen a drop in profits. Our core problem is that marketing cannot target the right policyholders (customers) and we therefore need proper segmentation. It is also essential that we gain the ability to amend our rates for specific segments quickly in response to competitive insight (or due to any other underwriting need). Our current inability to do this means we lose business or sell policies at an unprofitable premium for too long. Solving this will lead to an increase in profitable business.
Clearly Manager A & B’s perspectives are complementary, but they are different. If we launched a ‘Segmentation Project’, both managers would think that their problems are likely to be solved. Yet a decision needs to be made over how much of this scope to bite off. Indeed, analysis needs to be carried out to determine the real nature of the problem—and whether there are any other perspectives that may be valid.
Drawing back on the analogy mentioned earlier in this article: If a group of passengers were to get on a coach without checking its destination, then there is a significant risk that at least some will end up disappointed. The same is true on projects; if we embark on an initiative without ensuring our stakeholders are aligned in the outcomes and objectives, then there is a risk that a mismatch in expectations will cause problems later down the line.
Spending time up-front defining a problem statement, clear Critical Success Factors and Key Performance Indicators, and a model of the scope can help a great deal. This pre-project problem analysis doesn’t have to be time consuming, and will likely save time in the long run. It can often be distilled into a single page of A3, and in doing so we create a concise and precise picture that binds our project efforts together. This small investment of effort in the short term pays dividends in the long run.
What are your views on pre-project problem analysis? I’d love to hear them, please add a comment below. If you’re interested in this topic, you might be interested in our pre-project problem analysis course. You may also be interested in attending a related session at BA Camp Vienna
If you’ve enjoyed this article don’t forget to subscribe.
About the author:
Adrian Reed is Principal Consultant at Blackmetric Business Solutions, an organisation that offers Business Analysis consulting and training solutions. Adrian is a keen advocate of the analysis profession, and is constantly looking for ways of promoting the value that good analysis can bring.
To find out more about the training and consulting services offered at Blackmetric, please visit www.blackmetric.com
Adrian. Another great article. You highlight a very simple, yet common problem that I think is regularly overlooked due to ambiguity in language. Though discussion is held and statements are made, as you aptly illustrated, the true meaning is muddied and remains so until deeper into the project.
I use this same analogy, though not so elegantly, when highlighting approach development issues. In verifying correct approach, score and success measurement planning, I will typically ask about the destination. As you have shown, there is a lack of clarity of the end state…. And it puts everything else askew until it’s resolved.
In rushing to define things in pre-sales, we can see the consequences of that rush. However, do you have any thoughts in how we as business analysts can coach customers and sales professionals on expectations of this critical period?
Hi Doug, Thanks so much for the comment, I’m really pleased to hear that you found the article valuable!
You raise a really interesting point regarding ‘coaching’ customers/sales professionals on expectations. I often find that it’s a really tough period–often as the customer has a very *concrete* view on what they need (the “I’ve decided I want XYZ solution” type of situation). The approach I’ve found is to, over a few sessions with the stakeholder, with rapport, to gently question their assumptions…. to ask what it is *about* XYZ solution that they value. And then asking why that is important to them (i.e. the business outcome they are ultimately aiming for).
Essentially, taking them back from the “How” to the “What”. And *then* getting back to the “Why”. And of course, once you’re back at the “Why”, then you can help them discover other “What’s” and potential different “Hows”.
It’s interesting, a lot of traditional business analysis theory suggests we should *always* go from Why, to What to How. Yet people often start with the How. So, in my view, there’s huge value in helping them to take a step back and work out the Why before rushing forward.
What do you think Doug?
Hi Adrian,
Absolutely agree with you. I ran a workshop once where the stakeholders got very annoyed with me because they didn’t think the why was relevant. I eventually coaxed it from them and it became apparent that the requirements written by them didn’t all relate to the why the project was needed. This uncovered additional requirements. Without asking the why we wouldn’t have uncovered these crucial requirements. So can’t think of a better example than that backs up your viewpoint.