Digital Economy Dispatch #167 -- Avoiding the Next Digital Transformation Death March

Digital Economy Dispatch #167 -- Avoiding the Next Digital Transformation Death March
21st January 2024

We’ve all been there. That sinking feeling in the pit of the stomach as you make your way to the weekly project review meeting. Armed with the latest figures from your dev team about lines of code written, bugs found, test cases passed, and any other piece of data that might indicate you are moving forward, you do your best to accentuate the positive. But you know deep down that the project is going nowhere. Just thinking about it now, I can feel the sweat on my palms and the hairs standing up on the back of my neck.

Over the past few days, I’ve been experiencing this feeling a lot. With the Post Office Horizon scandal hitting the headlines, it has brought a great deal of attention to the challenges of large software system delivery, IT failure, and their implications for business transformation. While the on-going inquiry and review of that project is looking into many aspects of software-driven digital transformation activities, reading some of the details takes me back to lots of time sitting in project meetings and the hours spent pouring over priority bug lists, burndown graphs, risk registers, RAG charts, and the like.

Begun over 20 years ago, the Post Office Horizon project essentially was replacing paper-based activities with digital point-of-sales terminals in up to 17,000 post offices. In that time, it has struggled with a variety of issues and is the subject of a public enquiry regarding how the project was carried out, and the behaviour of Fujitsu and the Post Office in handling the consequences of its poor performance, delays, and errors. This includes looking into previous prosecutions of sub-postmasters based on data Fujitsu and the Post Office provided from the Horizon system. Amongst other things, the accuracy of data and appropriateness of the processes involved are now being questioned.

There is a great deal to be unpicked in the on-going review of the Horizon project regarding the way it was procured, how it has been undertaken, the tactics used to address discrepancies attributed to the system and its users, and the implications on people lives and livelihoods. These have resulted in extreme pain and suffering for people caught up in its effects. Consequently, much of the on-going review involves determining whether management and governance practices have been adequate, appropriate, and effective. As a result, much of the questioning is dominated by a variety of legal and ethical concerns.

However, a key part of the discussion directly addresses the way large IT projects are executed. A topic relevant to all of us involved with software delivery and digital transformation. Indeed, the scrutiny being placed on this project is raising broader questions about the way large scale IT projects are carried out and what can be done to avoid future delivery failures.

IT in the Dock

The Economist describes the Post Office Horizon scandal as “a typical IT disaster”. They comment that what we hear from Fujitsu, the prime contractor in this case, is not unusual and “evidence points to classic problems with the way public bodies contract firms to build and manage large IT systems”. But what is “a typical IT disaster” and why does it happen? For software practitioners and digital leaders, it is crucial to understand and acknowledge these issues to learn from any failings, no matter how painful the experience.

I have no personal involvement or information about the Post Office Horizon project. But in the last 30 years I have seen at first hand several large software-driven digital transformation projects experiencing many similar technical challenges. I am sure that anyone who has been involved with large IT delivery projects over the past few decades, like me, will recognize some of the characteristics we are hearing about in the Post Office Horizon project inquiry. Whether it is reference to Bugs, Errors, and Defects (BEDs) from day one, staff that some considered “weren’t capable of producing professional code”, or a customer who “did not have the skills or experience needed to deliver and oversee this transformation”, it is the start of a catalogue of problems seen in many projects. So much so that such projects have come to be described in very graphic terms: A “death march”.

Step By Step

The term "death march" isn't just a morbid metaphor for failed large software projects. It's a grimly accurate description of how some large, complex projects can feel to those on the inside when things go wrong – a gruelling, relentless grind that characterizes endeavours that seem doomed from their earliest stages. Despite best efforts of a large collection of talented people, they feel constrained to maintain the relentless march towards an ambiguous goal, fuelled by caffeine and adrenaline, to work long hours while putting their personal lives and well-being on hold trying to meet a series of impossible deadlines.

In such projects, this difficult journey is paved with a litany of red flags. Unrealistic timelines, poorly defined requirements, and a constant barrage of scope creep become the daily reality. Communication breaks downs are replaced by a culture of blame and finger-pointing. Long hours and difficult compromises to meet deadlines contribute to a toxic cocktail of stress, burnout, and resentment. No surprise that the initial excitement of a ground-breaking project soon dissolves into a bitter sense of disillusionment, as developers watch their passion erode under the weight of unachievable demands.

Perhaps this description is a little overly dramatic. However, the fallout of a "death march" project can be devastating. Morale plummets, talent flees, and the project stumbles from one crisis to another. Deadlines are missed, budgets collapse, and the promise of a successful launch recedes into the distance. This is why "death march" isn't just a catchy term; it's a stark reminder of the human cost of large-scale digital transformation gone wrong.

Facing Your IT Demons

Considering these issues can be rather overwhelming. Commenting from his experience with large public sector projects, the former UK government digital transformation leader, Mike Bracken, rather narrowly places the blame on allowing big IT consultancies to run entire national services. However, in my experience, there are usually several complex issues and processes at play. I have seen that there are at least 5 critical failure points that can drag down any such project.

1. Procurement Pitfalls. One of the primary challenges in large digital transformation projects is the procurement process. Both private and public sector agencies often grapple with bureaucratic procedures that can delay the selection of suitable vendors. In some cases, decisions may be influenced by factors other than technical expertise, leading to the selection of vendors ill-equipped to handle the complexities of large-scale projects.

2. Requirements Management Dilemmas. Effective requirements management is the cornerstone of successful digital delivery projects. However, many organizations struggle to define and document clear and comprehensive requirements. This can result in misunderstandings between stakeholders and developers, leading to the delivery of a system that does not meet the real needs of its end-users.

3. Legacy Systems Integration Challenges. Complex digital change programmes often grapple with the integration of new digital solutions into existing legacy systems. The complexity of integrating advanced digital technologies with outdated infrastructure can lead to unforeseen complications, jeopardizing the overall success of the project.

4. Training and Change Management Hurdles. Introducing a large-scale processes and practices to thousands of users necessitates comprehensive training and change management strategies. Many organizations underestimate the time and resources required to prepare users for the transition to new digital solutions, leading to rollout delays, resistance, confusion, and decreased productivity.

5. Maintenance Miscalculations. The long-term success of a digital transformation project hinges on its longer term maintenance and ongoing support. With pressure on budgets and delivery delays, it is easy to overlook the importance of allocating sufficient resources for post-implementation maintenance, leading to issues such as outdated software, security vulnerabilities, and a decline in system performance.

Big Projects, Big Problems

The on-going investigation into the Post Office’s Horizon project is placing a spotlight on challenges faced by all organizations in designing, delivering, and deploying large-scale digital change programmes. To those responsible for delivery, they can soon have the feel of a “death march”: A daily grind to meet unrealistic targets in a culture of blame and mistrust. Avoiding this requires addressing issues in procurement, requirements management, legacy systems integration, training, and maintenance. The success of these large digital transformation projects is not about hitting the finish line; it's about building trust and delivering lasting value to the people they serve. Let's learn from past mistakes, embrace innovation, and work toward a future where large software-driven change projects are held up as exemplars of the digital transformation we demand today.