Business decisions made better and faster

Measure twice, cut once. Business decisions made better and faster

 

Introduction

If you make great business decisions quickly and you routinely deliver the goods, then this note isn’t for you.  Unless you want to gloat.

For most leaders, our everyday business life features thorny business issues that are euphemistically labelled ‘strategic’ – code for complex, high stakes, risky and thankless.

So we try one of two behaviours. We see ourselves as seasoned sceptics, risk averse and evidence-based decision-makers. Which can look like procrastination. Or, we are dynamic leaders with a bias for action and agility.  We can appear rash and risky.

Meanwhile, getting buy-in from those who fund, deliver and depend on us is crucial to momentum. For that, we need deep self-assurance. If you can fake that you’ve got it made.

The following wise words still ring true after half a millennium:  “The innovator makes enemies of all those who prospered under the old order, and only lukewarm support from those who would prosper under the new.”

 

 

Executive summary

Decision Assurance^TM enhances business decision-making from strategy to execution drawing on disciplines of Quality Assurance¹, strategic program management and stakeholder engagement.  We refer to ‘assurance’ because making great decisions that turn out well is not always enough. We need to assure others – and especially ourselves – that we’ve got it right.

 

 

Step 1: Strategic Focus

 

Working through the following questions refines your strategy and shapes the outline business case whilst mobilising stakeholder buy-in and momentum.

 

• What’s the problem? What’s broken? What is the scope of work? Who benefits?
• Why this issue now? What’s the ‘Net Present Value’ of a controlled and budgeted plan of action now vs deferring it (risking an expensive and avoidable crisis)?
• Why is it MY problem? Is this a strategic issue that (only) I as business leader should own?

 

 

Step 2: Execution Feasibility

 

Addressing the following questions refines the business case and project plan whilst managing/ empowering stakeholders and colleagues regarding the project and their part in it.

 

• Scope: What is to be done, how and by when? Is it Big Bang or phased? What is the ‘Minimum Viable Product?
• Timetable: What is the timetable and deadlines? How flexible?
• Budget: What’s the cost – both direct cost and opportunity cost vs doing other things?
• Benefits: What’s the ROI and breakeven point? Who gains and how do they benefit? Do they know it and have you mobilised their support?
• Risks: Have you registered the main risks and associated mitigations? Who loses and how? Do they get it and how may the obstruct you? What are the contingencies and how have you planned for them (eg, flexing scope, timetable and budget?)

 

 

 

A deeper dive #1: Future-proofing aka NPV

 

Time is tricky (ask Einstein). Net Present Value calcs remind us that today’s decisions need to consider future benefits and costs. And there’s the fog of future risks and opportunities. Delaying a decision can seem prudent and risk averse but often carries hidden issues the impair the NPV of change.

 

• Lost savings: A large retail bank insisted on very lengthy due diligence before signing of a program guaranteeing hefty savings. The author calculated that every week of delay cost the client c. £100,000 of guaranteed savings that were gone forever.
• Amped up costs: Timely and proactive change enables quality planning and time to mobilise ‘A Team’ resources at competitive costs. However, when a business requirement devolves into a crises that the costs and risks multiply as the benefits shrink.
• Lost opportunities: Early implementation can harvest a host of direct benefits, competitive advantage, additional opportunities and reputational rewards that evaporate with time.

 

A deeper dive #2: QA and requirements testing

 

If Quality Assurance is dull and fussy then software testing is surely the worst. However, by the author’s estimation requirements testing is remarkably powerful. The root cause of disappointing ROI if not project disasters goes back to inadequately specified requirements. Delivering benefits is tricky if stakeholders aren’t quite clear about what they want, or developers aren’t sure what’s needed, testers don’t know what ‘bad’ looks like or users don’t know what to expect. Sometimes, requirements are vague or ambiguous. Sometimes, they aren’t specified and written up at all. Sometimes, sometimes the business doesn’t know what it wants. And sometimes, they know they

don’t know it.

 

• Black box requirements: The author worked with a UK media major seeking to replatform its core application onto new, agile-friendly tech with the new tech delivering the same use cases as the old. The trouble was that the legacy requirements weren’t documented. Code and requirements had evolved over many years. No-one really knew exactly what the tech was doing or why.
• The challenge of the new: The author’s client was a home improvement multi-national seeking to launch their first on-line portal. The project had a timely delay. When asked to specify its requirements, the client said ‘how can we specify what we will want in 24 months from now of an online portal when we’ve never had one before’?

 

Getting it done … and why DIY isn’t the answer

 

We’ve set out a deceptively simple checklist drawing on mature sub-disciplines of Quality Assurance (eg ‘requirements assurance’ aka ‘static testing), program management (de-risking complex projects) and change management (eg, stakeholder management). We’ve delivered complex programs but fixing those that are failing is the best way to learn how to simplify, streamline and de-risk projects. 

 

Secondly, independence scrutiny and challenge from seasoned practitioners is key. We may ask deceptively dumb or impertinent questions plus we help avoid the risk of misleading consensus aka ‘group think’.

 

Thirdly, we can’t over-state the importance of tapping into ‘alien’ mindsets. For example, great developers are positive team players who like to make things. Great QA testers are disruptive sceptics who like to break things. The former can make your fortune; the later can save you a fortune,

 

In conclusion, the title reminds us that even when cuts must be made and quickly that it is prudent to invest a bit of time up front to measure up what you want.