A programme has only reached its goal once operations are running stably. Go-live alone is not enough for that. Considering operability only in the last few weeks shifts the actual complexity into a phase in which hardly any room for steering remains.
Key points
  • The value of a transformation arises in reliable regular operations after go-live. Nevertheless, operability is often only dealt with at the end.
  • Decisions that affect operations are already made in the build phase, whether consciously or not. They include responsibilities, support model, data maintenance, monitoring and authorisations. If they are not steered deliberately, rework under time pressure follows later.
  • Build-to-run looks at operability across the entire delivery. Operational requirements are made visible early and carried along as a steering variable instead of only being checked at cutover.

Observation

A pattern repeats itself in complex IT and SAP programmes. Delivery is geared towards go-live, and milestones, tests, migration and acceptance all run towards this one date. Operations afterwards, with support, data maintenance, monitoring, change process and knowledge transfer, are placed at the end as hypercare or handover. In practice it then turns out that many decisions for operations have long been made. They were made implicitly, namely in the way authorisations were granted, interfaces built or data structured. This observation comes from our own project practice and makes no claim to statistical generality.

There is a clear imbalance here. For the build there is governance, plans and reporting. For the transition into operations there is often only a date. The complexity does not disappear as a result. It shifts into a phase in which less time, less attention and fewer steering instruments are available.

Context

That large IT programmes frequently miss their goals is documented several times. The Boston Consulting Group reports that a considerable share of large technology programmes do not achieve the goals set. As recurring factors, it names the absence of end-to-end planning and of active programme management.1 The joint study by McKinsey and the University of Oxford shows clear budget overruns on average for large IT projects and a considerably lower value contribution than planned.2 Both sources look at programmes as a whole and not specifically at the handover into operations. The link to operations is our own interpretation. If value only arises in operations, neglected operability is a plausible way in which planned value is lost.

Service management firmly establishes that operations are not an appendage of delivery. ITIL 4 and ISO/IEC 20000-1 treat operability, support and recoverability as requirements in their own right for a service management system.3 Google’s literature on site reliability engineering describes operability as a property of the design. Monitoring, alerting, error budgets and tested recovery are built into the solution and not added afterwards.4 The Accelerate research by Forsgren, Humble and Kim shows on the basis of data that fast and reliable deployments and fast recovery go hand in hand with better overall performance.5

The term: Build-to-Run

Build-to-run describes the continuous consideration of operability throughout the entire delivery, from the first decision on architecture and governance into stable regular operations. It does not mean an additional phase. It means a perspective that accompanies steering from the start and follows three principles.

  • Making operational requirements visible early: Support model, operational responsibility, data maintenance, monitoring and authorisation concept are not only defined at cutover. They are carried as requirements in parallel to the build phase.
  • Operability as a steering variable: Reporting also covers how far the solution is ready for operations, and not only progress towards go-live. This keeps room for steering while it still exists.
  • Handover as a process: Knowledge transfer, operational documentation and the clarification of roles are built up step by step. They are not squeezed into a short hypercare phase.

Four areas of operability

  • Ownership: For every productive service it is clear who is responsible for it functionally and technically, who decides on changes, who prioritises incidents and technical debt and who takes over responsibility after the end of the project. An anonymous handover "to operations" does not create responsibility.
  • Operability: The system can be understood and steered in production. This requires monitoring, logging, alerting, defined service levels, health checks, information on capacity and performance and traceable deployment processes. An operations manual alone is not enough. Operability has to be built into the solution technically.
  • Supportability: Support teams can handle incidents in a structured way. Prerequisites are a service and support model, clear support levels, ticket categories, known escalation paths, knowledge articles, reproducible error patterns and defined cooperation between support, development and suppliers.
  • Recoverability: The organisation can return to a stable state after disruptions. This includes backup and restore, rollback, disaster recovery procedures, restart plans, tested emergency processes and technical and organisational decision rights. An untested recovery plan is an assumption and not a safeguard.

Build-to-Run across the project lifecycle

  1. Initiation: The service owner is named. Criticality and operating model are clarified, and internal and external responsibilities are defined.
  2. Architecture and planning: Non-functional requirements are defined, monitoring and security requirements are planned in, support and operational processes are designed, and realistic service levels are derived.
  3. Delivery: Logging and monitoring are built in parallel to the solution. Operational documentation grows continuously, automated deployments and tests are introduced, and the knowledge for support is built during delivery.
  4. Testing: Besides function, behaviour under load, recovery and support procedures are tested. Incident and escalation paths are rehearsed, authorisations and operational access are checked.
  5. Cutover and go-live: The go/no-go criteria are extended to include operational readiness. Support staffing and escalation paths are activated, monitoring and alerting are switched to production, and the ability to roll back is demonstrated.
  6. Hypercare: Support is more intensive for a limited time and has clear criteria for its end. Critical incidents are assessed daily, knowledge passes into the regular support organisation, and handover only takes place after demonstrated stabilisation.

Hypercare is not a permanent solution

Hypercare sensibly safeguards the initial phase of a new or substantially changed system. It must not, however, be used to compensate structural deficiencies permanently with project resources. Several warning signs are known from project practice. There are no clear criteria for the end, project staffing remains permanently increased, support tickets still go directly to development, the service owner has no real responsibility, or external specialists are the only source of knowledge. Successful hypercare ends when defined criteria for stability and handover are met, and not on a particular date.

Application in projects

  • Run backlog in parallel to the build: A visible and maintained set of topics for operations runs along throughout the entire delivery. It includes support, monitoring, authorisations, data maintenance and emergency processes. It is not only kept at the end as a leftover list.
  • Naming operational responsibility early: Those who will later carry operations are involved early. This way, decisions on architecture and processes take later operability into account.
  • Criteria for operational readiness: Alongside the acceptance criteria for functionality, there are defined criteria for operability. Monitoring is in place, support paths are clarified, data maintenance is owned and roles are documented.
  • Handover in stages: Knowledge transfer and operational documentation are created during delivery. As a result, go-live does not mean a sudden jump in knowledge and responsibility.

Limits

Build-to-run is a term from practice and a perspective for steering, but not an empirically validated model. The structure of three principles is a generalisation from project experience. The studies cited show how often programmes miss their goals. They do not show what share of this is due to insufficient preparation for operations. Not every undertaking needs the same preparation. For small, well-supported systems, a compact handover can be enough. The value of the concept lies in deciding on operability early and deliberately instead of letting it arise on the side.