8.1 Transition Requirements and Business-as-Usual Readiness
Key Takeaways
- Transition management integrates the outputs of a project into business-as-usual so that outcomes and benefits become possible.
- Transition must be planned from the outset, not assembled near go-live, because design, contracts, and training decisions all constrain it.
- Business-as-usual must be considered throughout the project — operations continue running while the change lands on them.
- Operational readiness covers people, process, technology, support arrangements, data, and documentation, and is assessed before the go/no-go decision.
- Hypercare is the heightened support period immediately after go-live, and it must be resourced and time-bound rather than left open-ended.
What transition management means on the APM PMQ
Transition management is how project outputs are integrated into business-as-usual (BAU) so the organisation can run, maintain, support, and improve the new capability after temporary project structures wind down. On the PMQ it is learning objective 8 — Transition management in Area B (Preparing for change).
Weak answers treat transition as a final handover meeting or a signature on a certificate. Strong answers show that transition is a planned change of ownership, knowledge, process, risk, and support — designed early, agreed with stakeholders, and verified with readiness evidence.
Exam frame: A finished product is not success if BAU cannot use it. Transition is the bridge from project delivery to operational reality and, usually, to benefits realisation.
Why transition matters
Projects are temporary; operations are enduring. Without deliberate transition:
- Users reject or under-use the output
- Support desks cannot resolve incidents
- Procedures, roles, and SLAs remain unclear
- Residual risks stay with people who are leaving the project
- Benefits assumed in the business case never appear
Transition therefore protects investment value. It is not an optional administrative close-out task.
Requirements for successful transition
Successful transition needs more than technical completion. Typical requirements include:
| Requirement | What good looks like | Failure mode if missing |
|---|---|---|
| Clear receiving organisation | Named BAU owner(s), support teams, and escalation routes | "Everyone and no one" owns live service |
| Agreed acceptance criteria | Measurable readiness and acceptance standards for go-live | Arguments at cutover; informal go-live under pressure |
| Operational processes | SOPs, work instructions, SLAs, backup/restore, exception handling | Staff invent process under stress |
| People readiness | Training, role changes, RACI for run-state, capacity for new workload | Low adoption; workarounds; shadow systems |
| Technical readiness | Environments, access, monitoring, data migration, fall-back plan | Outages, data loss, irreversible cutover risk |
| Knowledge transfer | Documented and demonstrated know-how in BAU, not only in project files | Capability leaves with contractors |
| Support model | Hypercare, then steady-state support, with ticket/priority rules | Project team becomes permanent unpaid helpdesk |
| Risk and issue transfer | Residual risks accepted by named BAU owners with treatments | Risks orphaned after project closure |
| Stakeholder agreement | Transition plan endorsed by sponsor, operations, users, suppliers | Last-minute vetoes or silent non-cooperation |
| Evidence and sign-off | Handover pack, training records, acceptance logs, known-error list | No audit trail; disputes about what was delivered |
Consider BAU throughout — plan transition from the outset
The syllabus emphasises two linked ideas:
- Consider BAU throughout — design, requirements, packaging, testing, and schedule should reflect how operations will actually run the change.
- Plan transition from the outset — transition activities, owners, and windows appear in the project plan early, not as a scramble in the final weeks.
Early transition thinking changes delivery decisions:
- Requirements include operability, maintainability, and supportability — not only build features
- Training and data migration appear on the critical path early enough to finish
- Cutover windows respect operational blackouts (peak trading, exam seasons, clinical rotas)
- Suppliers contract for handover documentation, training, and warranty/support periods
- Benefits measures assume realistic adoption curves after go-live
Late-only transition planning is a classic failure pattern: the product is "done," but roles, training budget, and night-shift coverage were never funded. The project then either delays, dumps unfinished change on BAU, or claims success while benefits collapse.
Scenario A — early vs late planning
A hospital replaces an outpatient booking system. If transition is planned from the outset, the plan includes dual-run periods, clinic admin training before go-live, a weekend cutover with fall-back, and named service-desk scripts. If transition is left to the end, the vendor finishes configuration on a Thursday and asks clinics to switch on Monday with no trained super-users. Technical completion is high; operational readiness is low — a PMQ long-response should recommend re-planning transition before forced go-live.
Operational readiness, cutover, and hypercare
Operational readiness
Operational readiness is the evidenced state in which BAU can receive the output. Readiness reviews often sit near decision gates before go-live. Evidence may include training completion rates, dry-run results, support roster confirmation, monitoring dashboards live, and fall-back tested.
Cutover
Cutover is the controlled switch from old state to new (or first live use). Choices include big-bang, phased rollout, pilot sites, or dual running. Each balances risk, cost, and complexity. The plan should define freeze periods, communication, command structure for the cutover window, and criteria to invoke fall-back.
Hypercare / enhanced support
Hypercare (enhanced post-go-live support) is a time-boxed period of intensified support — often with project specialists still available — while BAU builds confidence. It is not an indefinite extension of the project. Define duration, exit criteria (incident volumes, knowledge transfer complete, SLAs met), and the move to steady-state support.
| Phase | Focus | Typical owners |
|---|---|---|
| Pre-transition | Build readiness into design, plan, and training | PM + BAU + suppliers |
| Cutover | Controlled switch, command/comms, fall-back | Joint cutover team |
| Hypercare | Rapid incident response, coaching, defect triage | Project specialists + BAU support |
| Steady-state BAU | Run, maintain, improve under operational governance | BAU service/product owners |
Why should transition into business-as-usual be planned from the outset of a project?
A go-live is approaching. The system passes all functional tests, but support staff have not been trained, no service-desk process exists for the new product, and the operational owner has not accepted the residual risks. What is the correct assessment?