You may be looking for a way to achieve better value and success from your digital transformation projects. A good source of inspiration would be a recent NAO report on the topic – The challenges in implementing digital change.
It looks into a multitude of previously published project reports and compared their findings from interviews with digital leaders across the public and private sector, including from academia and think tanks.
The report aims to identify patterns of common reasons why digital transformation projects fail so often and lessons that can be learned.
This is the second article in a series of four on this important report, the first being on the topic of flexible contracting.
Building a sound business case for digital projects
You need to start with an end in mind…
The first reason a sound business case should be considered as vital may not be what some project stakeholders would have expected. A properly considered and detailed business case is often used during the implementation and ‘in-service’ process, as a performance management tool; to identify what is going well and where areas for improvement have been identified.
When actions and behaviours are deviating from their expected path, the sooner you are able to recognise that this may happen or has in fact already happened, the greater your chances of correcting course are.
The starting point is understanding ‘what good looks like’ (what has changed in your organisation and the outcomes you are now achieving) once the implementation has been completed and the service/project is running as BAU.
Your business case should not only be able to show, with crystal clarity, where you are hoping to end up, but also the milestones along the way which make up the path you’d expect everyone to follow. Consider this to be the cat’s eyes on the road you’re travelling down; they help you to stay in lane and tell you when you’re veering off to one side so you can correct your course.
A sound business case can lead to a more collaborative supplier relationship
If we jump back to the beginning, the other primary reason for developing a properly researched and carefully calculated business case for digital projects – bringing in all relevant stakeholders to ensure the most accurate of real-world data is used to create as much certainty as is practically possible in your viability assessment – is to provide everyone with the best information from which to formulate action plans and decisions going forward.
The more information you have on the prospects, risks and opportunities of a strategic and/or complex project, the greater your chance of making the right decision as to whether to proceed with it.
The more business outcome information you are able to share with your prospective supplier partners, the greater the accuracy of their assessment on the challenges they and you will face along the way. They will help you to sense check the reality of your view of the outcomes you are aiming for, along with their capacity to deliver against those targets.
And the more information you have on the ultimate business objectives, the outcomes and the milestones that mark your path forward, the greater your capacity to manage the project so everyone is pulling in the same direction.
More accurate and considered information builds commercial trust. It is also clear that communication minimises opportunities for misunderstandings, which decades of experience has shown us is the number one reason for disputes in complex strategic supplier relationships. Therefore, the better your business case and articulation of business outcomes, the better your relationship with your strategic supplier is likely to be.
The NAO report highlighted an example of where a sound business case was not as clear as originally anticipated.
Figure 8
Case example: NHS England’s management of the primary care support services contract, 2018
Problems can arise from failure to understand what is being contracted for and not reflecting the requirements appropriately.
Objective: NHS England aimed to create better-quality primary care support services that were more efficient and easier to use, as well as reducing costs by 35%. It did not believe it had the necessary skills in-house for transforming services through better use of IT. In August 2015, NHS England entered into a contract with a supplier to deliver primary care support services.
What happened: NHS England did not know enough about the services it inherited to set achievable service specifications and performance standards from the start of the contract. As a result, it made assumptions about the services in order to set service specifications and performance standards. The supplier underestimated the scale and nature of the task.
Outcome: NHS England largely secured the financial savings it expected but did not achieve the transformation it wanted. Failure to deliver key aspects of the end-to-end service had a detrimental impact on primary care services and primary care providers, and potentially put patient safety at risk.
What lessons departments can learn: Government should set realistic but challenging expectations by developing an understanding of what is wanted and at what cost, before the procurement.
Source: Comptroller and Auditor General, NHS England’s management of the primary care support services contract with Capita, Session 2017–2019, HC 632, National Audit Office, May 2018
NAO report recommendations
One of the reasons cited for too little time being invested into building a sound business case on digital transformation projects, was in the lack of funding. The NAO report cited as one of its recommendations for the government was to:
…work with HM Treasury to review existing business case funding and approval processes for digital programmes to: remove the incentives to state with full confidence those things which are still unknown; ensure that uncertainties associated with assumptions are made clear, together with when these uncertainties will be better understood; understand what the final product should look like, and the path to get there; be clear on what risks represent ‘unknown unknowns’; and ensure professional independent technical assurance mechanisms are in place, to support those responsible for approving programmes.
And, of course, to learn from and apply lessons learned from past successes and failures, which is the foundation of this NAO report.
What makes a sound business case for digital projects?
The goal of any sound business case for digital projects should be to provide as much clarity and certainty as possible to minimise any chance for ambiguity to push the project and/or relationship off the rails in future. This can be achieved through a combination of knowing what ‘good’ looks like for the requirements and what format of requirements best suits your relationship.
From requirements, specialist suppliers can outline ‘specifications’ based on their sector experience. The NAO tend to use the term ‘specification’ when in our view, they really mean ‘requirements’. The general interpretation by industry is that the term ‘specification’ overlaps heavily with ‘how’ a project’s objectives should be delivered. In transactional projects, the end-client putting together a ‘specification’ is less of a concern, as the ‘how’ is often a ‘known’ entity.
However, in more complex projects, the ‘how’ is usually either unknown, or there can be multiple ‘how’ approaches to achieve the same outcome goal. If the end-client is reliant on the supplier’s specific expertise for a complex project, then it is better to clearly articulate the ‘what’ (requirements); the outcomes, objectives and behaviours from both sides required, and a range of dialogues / discussions with the suppliers for them to outline the ‘specification’; the ‘how’ of the project.
Specialist suppliers usually have a range of “Expert Responsibilities” and are often under a “Duty to Warn”, so if the end-client is reliant on the supplier’s advice to ensure the project delivery is fit for its intended purpose, it is much more effective both in project delivery AND contractual terms, for the end-client to focus on ‘requirements’ and for the supplier to focus on producing the ‘specification’.
Some projects may be of a uniquely technical nature, i.e. the MoD and a defence systems supplier working together on, say, a state-of-the-art missile defence system. The MoD may have its own specialist technical experts in defence systems who in turn, writes/develops a ‘specification’ for the defence supplier to input into, but largely, the MoD’s own technical specialists have the final say on the design/specification because of its own in-depth technical expertise in this specific area. In turn, the MoD (and its own technical expert) would probably retain (and may even commercialise) any specialised intellectual property.
The NAO notes that where a ‘specification’ is written by the end-client, then it can be defined in three general forms – input specifications, output specifications and outcome specifications.
-
- Input specifications – these look to show everyone, in great detail, ‘how’ a supplier can deliver against expectations. Input specifications are all about clarity of the ‘how’. However, by being prescriptive there is always the chance that opportunities to achieve better results more affordably and more quickly could be missed as suppliers simply follow instructions, rather than employ their expertise to find better ways of achieving your goals.
- Output specifications – these look to explain ‘what’ you are looking to achieve as a result of the strategic relationship you enter into with your supplier. Suppliers now usually have complete freedom to determine how they will achieve your goals, encouraging innovation, however it does require a client to give up quite a bit of control over the project and not everyone is comfortable with this.
- Outcome specifications – these look to show ‘why’ you are undertaking the project in the first place, including quantified differences between current and future states, the benefits you hope to achieve. With greater clarity comes a greater commitment to responsibility from suppliers, but it takes a very different way of thinking to move away from inputs and outputs and towards specific project outcomes.
The ‘specifications’ from within your business case should include:
-
- Overview
Every business case requires a detailed overview of how the relevant department/service/system currently works, or not, how it has evolved, its strengths and weaknesses, stakeholder’s views on where improvements are possible and the interconnected web of actions and consequences of change within and without the department/organisation.
-
- Objectives
What are you looking to achieve as a result of your project? What are the ultimate business objectives you are aiming to achieve and the outcomes you are hoping will result? The more these are quantified and qualified the better as numerical goals are far easier to assess progress against.
-
- Your reason why
The central purpose of a business case is to identify a clear enough reason why you should move forward with a project. If this reason does not exist then your investment in a business case was money well spent to save you a small fortune in what is likely to have been an expensive misadventure. Identify your reasons why, and how your future state, post-delivery, will help you achieve it.
-
- Future state benefits
Project yourself forward in time to a point where the digital transformation project has reached its successful conclusion. In other words, imagine the project has already been completed and you are achieving key benefits from it. Now list all the benefits you hope to gain (in terms of the specifics of those benefits; what they are, what % improvement you have achieved and over what time scale) when compared with the current state overview.
-
- Challenges and opportunities
No project is ever plain sailing, so it’s best to look to identify the potential/likely challenges ahead so you can put in contingent processes to mitigate them. Use your stakeholder’s in-depth knowledge of your current real-world situation and the way activities will bend and stretch as you look to implement changes to assess the challenges and opportunities possible along the way.
-
- Negative impact of failure
Everyone should be aware of the impact on your organisation should the project fail to deliver on expected outcomes and objectives. It would not otherwise be possible to determine whether the risks outweigh the rewards or visa versa, a vital consideration on any project.
Conclusion
The NAO report points to a very bleak view of government failure to transform its own approach to digital transformation projects, suggesting that while there’s a will from many, the way has been illusive to date.
It is hoped that the lessons contained within this curated report may place more major public sector projects on the right path, but it should also be noted that despite the NAO’s focus on governmental projects, these lessons are just as relevant for those in the private sector. Get your business case ducks in a row, in detail and with clarity, from the outset and you stand a far greater chance of success in an arena that is littered with metaphorical bodies of well-intentioned projects that were destined for failure.
A sound business case offers the building blocks for the blueprint to a successful project.
