Most projects are planned around a launch date. Most value is lost in the months after it, when a system built by one team is handed to people who did not build it, and the firm that designed it moves on.
Where the value leaks
- Knowledge leaves with the delivery team, and the people left running the system learn by trial and error.
- Nobody measures the outcome, so small problems become accepted workarounds.
- Adoption stalls because training happened once, weeks before anyone used the system for real work.
- The business case is never revisited, so nobody notices the benefits were only half delivered.
We added Drive as the fourth stage of our method for this reason. The same engagement manager stays, outcomes are measured against the baseline agreed in Discover, and knowledge transfer runs through every sprint rather than arriving as a manual at the end.
What staying actually looks like
For the first weeks after launch, the delivery team sits alongside the people who now own the system. Issues are fixed quickly, questions are answered in the moment, and the runbook is written from real incidents rather than guesses. Then the rhythm changes to monthly: measure the results against the baseline, agree the next improvements, and report plainly on what has and has not worked.
A launch date is a milestone. A measured result is the outcome.
Questions to ask any delivery partner
- Who from your team will still be working with us three months after go-live?
- What baseline will you measure against, and how often will you report?
- How will our people learn to run and change what you build?
- What happens, and who pays, if the agreed outcome is not reached?
If those questions are hard to answer before the contract is signed, they will be harder to answer after launch.