The project is done. The code is deployed. The documentation is written. The team moves on. Six months later, the client calls. Nobody's using it. Not because it doesn't work. Because nobody knows how to make it theirs.
This is the handover problem. It's the gap between "delivered" and "adopted." It's where good enterprise software goes to die, and it happens far more often than anyone in this industry admits.
Delivered Is Not Done
We treat project completion like a finish line. Code deployed, invoice sent, team disbanded. But deployment is the starting line for the client. That's when real users encounter the system for the first time. That's when the edge cases nobody anticipated start appearing. That's when the person who was supposed to own the system internally realises they don't fully understand it.
The handover problem isn't technical. The code works. The documentation exists. The problem is human. The people who built the system understood it deeply. They had context for every decision, every trade-off, every "we did it this way because" explanation. That context lives in their heads, not in the documentation. When the team walks away, the context walks with them.
Why Documentation Doesn't Fix It
Every enterprise project produces documentation. Architecture diagrams, API references, user guides, admin manuals. Some of it is genuinely useful. Most of it is written for the project team, not for the client team who inherits the system.
Good documentation describes what the system does. It rarely describes why the system does it that way. The "why" is the context that new owners need most and have least access to.
"The user role hierarchy uses a three-tier model" is documentation. "We used a three-tier model because the client's approval process has exactly three levels, and a more flexible model would have introduced complexity the admin team couldn't manage" is context. One gets written down. The other doesn't.
Documentation tells you what the system does. Most handovers deliver the first and lose the second.
Isaac Rolfe
Managing Director
The Three Failure Modes
I've watched enterprise handovers fail in three predictable ways.
The knowledge void. The build team leaves. The client's internal team doesn't have the technical depth to maintain or extend the system. Changes stop. Bug fixes slow to a crawl. The system becomes static in an organisation that keeps moving. Within a year, users are back to spreadsheets.
The second-system trap. A new vendor inherits the system. They don't understand the architecture or the decisions behind it. Rather than learning, they propose a rebuild. The client, frustrated by the stagnation of the first system, agrees. The cycle starts again. Same problem, new invoice.
The slow drift. The internal team makes changes without understanding the original architecture. Each change is small and reasonable. Over twelve months, the system's integrity degrades. Performance drops. Bugs multiply. The codebase becomes something nobody wants to touch. The system works, technically. It just gets worse every month.
What We're Trying Instead
At IDESIGN, we've started treating handover as a project phase, not a project event. It's not a meeting and a zip file. It's a period of overlap where the build team and the maintenance team work together.
Paired sessions, not documents. We sit with the client's technical team and walk through the system together. Not a presentation. Hands on keyboards. "Here's how you'd add a new user role. Here's what you'd change if the approval process adds a step. Here's where to look when something breaks." They do the work. We watch and fill in the gaps.
Decision logs, not just documentation. We've started keeping a decision log during the build. Every significant technical choice gets a one-paragraph entry explaining what we decided, what we considered, and why we chose this path. It's the "why" documentation that most projects lack.
A support runway. We stay available for a defined period after launch. Not on retainer. Just available. Questions that take us five minutes to answer would take the client's team five hours to figure out. That runway costs us very little and saves the project from the knowledge void.
The Uncomfortable Truth
Handover is under-invested because it's not billable in a way that clients want to pay for. The project budget covers discovery, design, development, and testing. Handover gets whatever's left, which is usually one meeting and a shared drive folder.
Until the industry treats adoption as part of delivery, we'll keep building systems that work perfectly and die quietly. The gap between "delivered" and "adopted" is where the real value is created or lost. It deserves the same rigour as the build itself.