Every experienced business analyst will have plenty of scars and stories from working on projects and initiatives that should never have been pursued in the first place. These include ideas that were never going to deliver real benefits, projects that couldn’t be successfully completed with the available resources, and initiatives that made things much worse for staff and customers in order to save a measly amount of money.
While many organisations, particularly larger ones, will have processes and protocols in place for deciding what change initiatives or products get a “green light”, these controls are frequently ineffective; pet projects are pushed through (or just circumvent the approval process entirely) and proposals may receive insufficient scrutiny due to group-think, domineering personalities, or just because nobody asked the right questions.
Preventing bad ideas from becoming bad projects is hugely valuable, saving time, money, and effort, and reducing the risk of damaging outcomes.
In this post, I’ll look at some of the awkward questions we should ask to “kick the tyres” on proposals, helping organisations ensure they pursue the best ideas to achieve their strategic goals.
1 – Does this really fit with our strategy?
Any change initiative should have a clear link to the organisation’s overall strategy. If this link hasn’t been articulated, further probing is vital! It’s amazing how many projects and products get approved with only a tangential link to the organisation’s stated goals.
Personal motivations and incentives are a frequent cause of misalignment, and the phrase “no-brainer” gets used too often when brains really should be applied!
Whoever is pushing the project needs to show how this initiative links to specific strategic goals. What KPIs will this initiative move? And by how much?
2 – Do the numbers actually add-up?
It’s common for a project proposal or technology purchase to require a business case, and this will typically include some form of financial feasibility assessment. It would be fair to say, these are not always as robust as the scientific-numbers might lead us to believe. There are a number of angles that should be considered.
Firstly, can we afford this investment? The business case should show how much things will cost, and when these costs become payable. Where there is uncertainty, are ranges and probabilities discussed? What does the maximum possible cost look like? Will we be paying an ongoing subscription? What variables (licence numbers, support needs etc.) might change the costs over time?
Knowing what the costs will be, and when they’ll occur, enables us to think about affordability and cash-flow. Major up-front investments may create an unpalatable cash-flow risk; are the right people aware of what’s being proposed? Are there constraints on what we can spend, and when?
In addition to describing the costs that will be incurred, a business case typically details the benefits that will be achieved. These will often be a mixture of tangible or quantifiable benefits (e.g. cost reductions) and intangible or qualitative benefits (e.g. customer satisfaction). Where financial benefits are expected, consider whether the cost-benefit analysis robustly demonstrates a net gain (and over what time).
Calculating net present value and discounted cash flow ensure that the changing value of money over time (and how this proposal compares to simply investing the money) are properly considered. If these haven’t been included in the investment appraisal, it’s possible the cost-benefit analysis doesn’t stack up!
3 – Are we truly capable of delivering this?
Even the very best ideas are not worth pursuing if they can’t be delivered successfully. Organisations need to be honest about their chances of success!
Firstly, is there enough time to deliver this project? There may be regulatory deadlines or other business constraints that mean the change has to be delivered within a particular window. If achieving this looks unlikely, perhaps alternatives should be considered.
Delivering projects and products requires people (and those people need skills and know-how!). Do we have the people we need, and will they be available? Do they have day-jobs to fulfil? If we need to bring people in from outside the organisation, how can we do this, and is this feasible? What if we need to scale up or down? Can we work around any skills gaps? How will people be managed?
4 – Will we actually see the benefits?
I’ve worked on many “successful” projects that delivered the change they were supposed to but never quite brought about the benefits everyone was expecting.
“Efficiency savings” are probably the biggest culprit. Plenty of proposals get approval because they’ll “save 10 minutes from everyone’s day”. A small time saving across multiple people rarely translates into an actual cost reduction – it’s unlikely to result in a headcount reduction. Where proposals are claiming efficiency, ask probing questions about what is going to be done to turn that saved time into a benefit. Are we going to reduce headcount, or give people other things to do? And how will we know this has happened?
Ensuring benefits are measured and reported is crucial. Organisations shouldn’t be approving proposals for delivery if nobody knows how the benefits will be demonstrated, who will test this, when they’ll test this, and who they’re going to tell. Someone needs to be accountable for the benefits being realised.
5 – Will it work here?
Not every great idea will work everywhere, and it’s important to question whether a proposal is right here and now in this organisation.
Consider cultural fit; if your organisation thrives on deep interpersonal relationships, introducing a change that limits interaction is going to end in tears. Factors such as autonomy, standardisation, hierarchies and power-distance, tacit knowledge, and rewards/disincentives should all be considered.
New technology will need to fit within the existing tech landscape (and align with the future tech roadmap). I’ve seen many instances of senior leaders with access to a budget simply going shopping for a new system without properly consulting with IT! Ensure the right people are being consulted, and any concerns should never be lightly dismissed.
With a portfolio of products and change initiatives all being delivered in parallel, it’s very easy for change saturation to start undermining success. Those responsible for delivering change need sufficient bandwidth (and can’t “run hot” all the time!) while those on the receiving end can only handle so much change at any one time alongside the demands of their day-job. Consider whether now is really the best time to be pursuing this proposal, and ask questions about how any challenges might be mitigated.
6 – What risks are involved?
Delivering a change or new idea always comes with risks. There will be risks to the successful delivery of the proposal, and risks that arise because of the successful delivery of the proposal.
Consider who will not be happy about this change., or who might be disadvantaged. This could include staff, customers, suppliers, or regulators. Have we talked to them, and do we understand why they might feel this way? How might discontent be expressed? Will we see a reduction in sales, negative media coverage, or people quitting their jobs?
Ask questions of stakeholders in the business and in project teams to determine what we can do to reduce the likelihood of risks occurring or to mitigate any impacts.
7 – What assumptions have we made?
It’s ok to make assumptions. We can’t possibly know everything before deciding whether to pursue a particular idea.
However, it’s important to flag these assumptions (making clear that they are assumptions!), and we should ask questions about what we’ll do if these assumptions are later shown to be wrong. Will we carry on? Will we pivot to a new course of action? Or will we cancel the whole project?
8 – What if we just don’t do it?
Doing nothing is always a possibility (albeit possibly absurd, illegal, or generally undesirable). A good business case will describe the do-nothing scenario, highlighting costs, risks, and likely impacts.
There may also be positives in this scenario, not least the money and time saved by not pursuing this proposal. It’s important to be clear and fair in assessing the do-nothing scenario to ensure decisions are made with eyes-open.
9 – What about the things we’re not doing?
An organisation will generally have more project and product ideas than it could possibly deliver, and choosing to pursue one initiative means that others have to wait in line (and indeed, may never get done).
Before a proposal gets approved, it’s important to ask what we will not be doing while our attention and resources are on this.
Choosing not to pursue other initiatives can mean that new products are delayed, remedial projects don’t happen, or that great opportunities pass the organisation by. It doesn’t necessarily mean that the project we’ve chosen to pursue is a bad idea, but decisions need to be made with a clear understanding of the implications.
10 – What would make us kill this idea?
Stopping a project or killing a product once things are in motion is actually really hard. Tough decisions need to be made by senior people, and they probably have significant “skin in the game”. Nobody wants to be the one to put their head above the parapet and question whether this is still a good idea.
The sunk costs fallacy can lead us to continue throwing time, money, and resources at something that really should be abandoned.
It’s much better to be clear from the outset about the circumstances in which this initiative should be abandoned. As mentioned above, assumptions may turn out to be incorrect. External factors may change (the cost of resources, the size of a market, regulations) and other internal demands and ideas may arise that should take priority.
Asking questions about when we’ll cancel a project is healthy, and much easier before resources are committed and work has begun.
Asking awkward questions is hard!
I’m firmly of the belief that helping organisations make better choices about which changes to pursue is where business analysis makes the most difference. It’s complex work, requiring great analysis, strong interpersonal skills, and true integrity.
If we’ve been responsible for assembling a business case (and particularly if the proposal was our idea) it’s hard to ask ourselves the challenging questions. Consider asking others to review things critically. De Bono’s 6 Thinking Hats could provide a useful framework. While having our ideas knocked about by others can feel a bit brutal, identifying flaws and pitfalls early can save a lot of pain later on.
Challenging others’ proposals can also feel daunting. Doing so requires us to apply empathy, great communication skills, and a constructive mindset. The focus should be on finding the best ways to achieve the organisation’s strategic goals, and framing discussions this way will help in those difficult conversations with senior stakeholders!
Make it clear from the outset that challenging questions are going to be asked as proposals are developed; close examination of ideas needs to be expected and welcomed by all concerned, particularly when the investment is significant.
Asking awkward questions is hard, but doing so is what elevates a business analyst to the role of “trusted advisor” to their organisation.