Case Study:
Rescuing a project in a downward spiral
Client Context
Our client had reached a crisis of confidence in a major project to replace one of its core business systems. With a two year major IT systems upgrade running millions over budget, and nearly a year behind schedule, they had to decide the fate of the project.
Continuing the project risked further over-runs and delays to other projects. But terminating the project would forfeit not only the time and resources invested, but also damage stakeholder confidence in the organisation’s capability to deliver. With a merger into another organisation nearing, losing confidence was an outcome that our client could ill-afford.
When the new project sponsor came to us, they had already received external advice that the project was worth continuing. But following standard process improvements was not helping the project to succeed. The sponsor knew that a different approach was needed but was not sure what it was.
Mapping a path to delivery was the challenge that Reason was engaged to meet.
Our approach
- Analysing the root causes of the project delays
- Building an internal leadership team and reshaping project governance
- Establishing a Business Reference Group (BRG) to prioritise requirements
- Rebuilding the vendor relationship
- Giving executive objective data to make decisions on future investments
- Redefining the project schedule, chunking the project down into stage gated milestones
- Re-engineering contractual, requirements and testing processes
- Developing and executing the transition and change management plans
Our Thinking
We also discovered that the project was trapped in a loop of continual testing. On paper, the project seemed to be just one stage short of completion. In practice, business acceptance testing kept uncovering system requirements. As the project timeline ballooned, stakeholders questioned why delivery kept being delayed. The software vendor was also concerned by the never-ending cycle of more defects to fix, on what they thought was a finished product. Lines of communication were frayed.
It was clear that our client had to draw a line in the sand: to define what issues would be resolved at launch, and what issues would be tackled later. The client was deeply committed to project quality, so we reassured them that containing scope did not mean compromising quality. Iterative development enabled them to let go of less-essential requirements, knowing there was a plan for delivery post-launch.
That line in the sand also helped restore relationships with the software vendor. With reset expectations, they gained a clear brief on they had to deliver.
The outcome
Beyond the planned benefits, the client also gained standing in the eyes of stakeholders. They had demonstrated their capability to deliver. The relationship with the vendor was back on solid ground, and continues to this day. Previously segregated business areas are now working more closely together.
In an external PWC review, our client said that this process was the best-run implementation in their history. They experienced this both in how smoothly it progressed, and how well-prepared they were for the end-product they received.
As the external review found, while Reason’s methods may have not followed the text book, in this case, they were exactly what this project needed.