Almost every organization has had a technology project go off track: deliveries constantly postponed, a budget spiralling upward, users who no longer believe in the outcome. Faced with this situation, the temptation to add resources or change tools is strong. These reflexes often make things worse.
Recognizing the warning signs
- Delivery dates are pushed back at every steering meeting, with no new planning baseline
- Progress has been stuck at around 90% for several weeks
- Demos are rare or always show the same features
- Key users no longer attend workshops
- The team is working constant overtime and turnover is rising
Week 1: establish the facts
The diagnosis starts with one-on-one interviews with the sponsor, the project manager, the delivery team, key users and the vendor. Then the actual deliverables are examined: code, environments, tests, product backlog and budget tracking. The goal is to separate what actually works from what is merely reported.
Week 2: understand the causes
Technical symptoms often hide organizational causes: poorly defined scope, slow decisions, unclear roles, unmanaged dependencies or an unsuitable architecture. Each cause is documented with its impact and level of certainty.
Week 3: present the options
The diagnosis leads to costed options: continue with targeted fixes, reduce the scope to deliver a useful first version, rebuild certain components or, sometimes, stop the project. Each option sets out its costs, timelines, risks and the value it delivers.
Adding people to a late software project makes it later. Fred Brooks's observation, made in 1975, still holds true.
Week 4: decide and relaunch
Management chooses an option with full knowledge of the facts. The resulting relaunch plan sets a new, realistic baseline, close and verifiable milestones, tighter governance and indicators shared by all stakeholders.
The value of an outside view
An independent advisor more easily obtains candid information from all parties and can state difficult findings with no political stake. That neutrality makes it easier to take the decisions the internal team hesitates to propose.
After the relaunch
The first weeks after the relaunch are decisive. Regular demos, transparent communication about progress and gaps, and close attention to the team's workload help rebuild trust. A recovered project can become one of the organization's greatest successes.