Build-to-Run: Why operability must not be considered only shortly before go-live.

A programme does not deliver at go-live, but with stable operation. Anyone who considers operability only in the final weeks shifts the actual complexity into a phase in which barely any room to steer remains.

Observation

In complex IT and SAP programmes, one pattern recurs: delivery is geared towards go-live. Milestones, tests, migration and acceptance all lead up to this single date. The operation that follows — support, data maintenance, monitoring, change process, knowledge transfer — is placed at the end as "hypercare" or "handover". In practice, it then becomes clear that many operationally relevant decisions have long since been made: implicitly, in the way permissions were granted, interfaces were built or data was structured. This observation stems from our own project practice and makes no claim to statistical generality.

What is remarkable is the asymmetry: for the build there are governance, plans and reporting. For the transition into the run there is often only a date. The complexity does not disappear as a result — it shifts into a phase with less time, less attention and fewer means to steer.

Context

That large IT programmes frequently miss their targets is documented repeatedly. The Boston Consulting Group reports that a substantial share of large technology programmes fail to reach the goals they set, and names the absence of end-to-end planning and the lack of active programme management as recurring factors.¹ The joint study by McKinsey and the University of Oxford on large IT projects shows, on average, significant budget overruns and a considerably lower value contribution than planned.² Both sources look at programmes as a whole, not specifically at the operational handover. The connection to the run is our own interpretation: if value contribution is only realised in operation, then an unconsidered operability is a plausible channel through which planned value is lost.

That operation is not an appendage of delivery is firmly anchored in the service management standard. ITIL 4 and ISO/IEC 20000-1 treat operability, support and recoverability as their own requirements of a service management system, not as a closing document.³ Google's Site Reliability Engineering literature makes operability — monitoring, alerting, error budgets, tested recovery — a design property that is built into the solution, not added afterwards.⁴ And the "Accelerate" research by Forsgren, Humble and Kim shows, on a data-driven basis, that high-performing organisations think about operational and delivery capability together: fast, reliable deployments and fast recovery go hand in hand with better overall performance.⁵

The term: Build-to-Run

Build-to-Run denotes the continuous consideration of operability across the entire delivery — from the first architecture and governance decision through to stable, steady-state operation. The core is not an additional phase, but a steering perspective that runs alongside, with three principles:

1. Make run requirements visible early. The support model, operational responsibilities, data maintenance, monitoring and permissions concept are not defined only at cutover, but carried as requirements in parallel with the build phase.
2. Operability as a steering variable. The level of maturity towards operation is reported visibly — not just progress towards go-live. This creates room to steer while it still exists.
3. Handover as a process, not a date. Knowledge transfer, operational documentation and role clarification are built up step by step, rather than compressed into a short hypercare phase.

Four areas of operability

1. Ownership. For every productive service it is clear who owns it functionally and who owns it technically, who decides on changes, who prioritises incidents and technical debt, and who takes over responsibility after the project ends. An anonymous handover "to operations" is not ownership.
2. Operability. The system can be understood and steered in its productive state: monitoring, logging, alerting, defined service levels, health checks, capacity and performance information, as well as traceable deployment processes. Operability does not emerge from an operations manual alone — it must be built technically into the solution.
3. Supportability. Support teams can handle incidents in a structured way: service and support model, clear tiers, ticket categories, known escalation paths, knowledge articles, reproducible error patterns and a defined collaboration between support, development and suppliers.
4. Recoverability. The organisation can return to a stable state after disruptions: backup and restore, rollback, disaster recovery procedures, restart plans, tested contingency processes as well as technical and organisational decision rights. An untested recovery plan is an assumption, not a safeguard.

Build-to-Run along the project lifecycle

• Initiation. Identify service owners, clarify criticality and operating model, define internal and external responsibilities.
• Architecture & planning. Define non-functional requirements, plan for monitoring and security requirements, design support and operational processes, derive realistic service levels.
• Implementation. Develop logging and monitoring in parallel with the solution, build operational documentation on an ongoing basis, establish automated deployments and tests, let support knowledge emerge alongside.
• Testing. Test not only function, but also load, recovery and support workflows; rehearse incident and escalation paths; verify permissions and operational access.
• Cutover & go-live. Extend go/no-go criteria to include operational readiness, activate support staffing and escalation paths, switch monitoring and alerting to production, demonstrate rollback capability.
• Hypercare. Heightened support with clear exit criteria, daily assessment of critical incidents, knowledge transfer into the regular support organisation, handover only after demonstrated stabilisation.

Hypercare is not a permanent solution

Hypercare sensibly safeguards the initial phase of a new or heavily changed system. It must not, however, serve to compensate permanently for structural deficits with project resources. Warning signs: no clear exit criteria, permanently elevated project staffing, support tickets that continue to go directly to development, a service owner without actual responsibility, external specialists as the only source of knowledge. A successful hypercare does not end on a calendar date, but when defined stability and handover criteria are met.

Application in projects

• Run backlog in parallel with the build. A visible, maintained set of operationally relevant topics (support, monitoring, permissions, data maintenance, contingency processes) runs across the entire delivery — not as a leftover list at the end.
• Name operational responsibility early. Whoever will later carry the operation is involved early, so that architecture and process decisions take future operability into account.
• Operational readiness criteria. Alongside acceptance criteria for function, there are defined criteria for operability — monitoring in place, support paths clarified, data maintenance owned, roles documented.
• Handover in stages. Knowledge transfer and operational documentation emerge alongside the implementation, so that go-live is not a leap in knowledge and responsibility.

Limitations

Build-to-Run is a practitioner term and a steering perspective, not an empirically validated model. The three-part structure is a generalisation from project experience; the cited studies evidence the frequency of missed programme goals, not causally the share attributable to inadequate operational preparation. Not every undertaking needs the same amount of run preparation — for small, well-supported systems a compact handover may suffice. The value of the concept lies in treating operability early as a conscious decision, rather than letting it emerge as an implicit by-product.