Business Implementation and transition in PM²: from delivery to real use
Twenty-third article in the “Learning PM² Through a Project” series
Delivering a solution is not the same as achieving the result for which the project was created. An app can be technically ready, deliverables can be accepted, and the project can still fail to create benefits if users, processes, support and organisation are not ready.
In PM², Transition Management and Business Implementation Management address this often neglected part: controlled transfer of project results into operations, and enabling the business change needed for benefits to materialise.
Output, outcome and benefit: the value chain
| Level | Meaning | Annotatio example |
|---|---|---|
| Output | What the project delivers. | Smart Bookings feature available on web and app. |
| Outcome | The change produced by using the output. | Managers and collaborators use the system as the primary channel for bookings. |
| Benefit | Measurable improvement resulting from the outcome. | Fewer no-shows, fewer phone calls, better class occupancy. |
The project mainly controls output quality and delivery. Outcomes and benefits also depend on adoption, behaviours, processes and operating conditions; they often mature after project closure.
Transition and Business Implementation: different, complementary
| Transition Management | Business Implementation Management |
|---|---|
| Ensures orderly transfer of deliverables, responsibilities, data, support and knowledge to the people who will operate the solution. | Ensures that the organisation, users, processes and working practices adopt the change and can obtain the benefits. |
| Question: “is the solution ready to enter and remain in operation?” | Question: “are people and business ready to use it in the way that creates value?” |
In a small project, both activities may be handled in the same plan. Conceptually, however, they should not be confused. Handing an app to support is not enough if users continue to work as before.
Transition: what must move into operations
Transition is not a go-live date. It is a set of verifiable preparations and handovers.
| Area | Examples of items to prepare |
|---|---|
| Service / solution | Production environment, configurations, data, access, monitoring, backup and continuity. |
| Support | Operational owner, support levels, incident procedures, knowledge and contacts. |
| Deliverables and acceptance | Criteria met, test evidence, documented exceptions or residual issues. |
| Documentation | Operating guides, manuals, runbooks, technical knowledge and updated repositories. |
| Responsibilities | Who manages after the project, who decides evolution, who supports recurring costs. |
| Suppliers and contracts | SLA, licences, expiry dates, contacts and service obligations. |
The Transition Plan coordinates these activities: owners, dates, readiness criteria, dependencies and criteria for declaring the transfer complete.
Business implementation: changing how work is done
The Business Implementation Plan focuses on actions that make adoption possible and measurable:
- analysis of current and future processes;
- operational roles and responsibilities;
- training, materials and initial support;
- communication of what is changing and why;
- involvement of users and managers;
- management of resistance;
- measures to verify use and benefits;
- actions after go-live, when the project no longer owns operations.
Training alone is not business implementation. If process, incentives, roles or support contradict the new way of working, people will tend to return to old habits.
Readiness: when go-live readiness is real
A proportionate readiness checklist enables evidence-based decisions rather than enthusiasm-based ones.
| Question | Example evidence |
|---|---|
| Is the solution ready? | Quality and acceptance criteria met; critical issues closed or managed. |
| Are operations ready? | Service owner, support, access, monitoring and procedures active. |
| Are users ready? | Training delivered, instructions available, pilot users involved and feedback collected. |
| Are processes ready? | Rules, responsibilities, exceptions and flows updated. |
| Are benefits measurable? | KPI baseline, target, owner and measurement frequency defined. |
| Is there a plan for the initial period? | Hypercare, support channel, communications and escalation criteria. |
A conditional go-live can be appropriate, but conditions, owners, review date and fallback must be explicit. “We will sort it out later” is not a transition plan.
The Annotatio case: Smart Bookings adopted, not merely published
For Smart Bookings, the team completes the feature and publishes it. To produce benefits, the project also plans:
| Area | Action |
|---|---|
| Technical transition | Configure roles, notifications, monitoring and fallback procedure if push does not arrive. |
| Support | Assign operational contact and a channel for reports during the first week. |
| Process | Establish that official availability is what appears in Annotatio, not what is said on WhatsApp. |
| Training | Twenty-minute session for collaborators; one-page guide for clients and managers. |
| Adoption | Check after two weeks the percentage of bookings managed in the system. |
| Benefits | Compare no-shows and unoccupied places against the previous baseline. |
If collaborators keep taking bookings on WhatsApp, software may be perfect but the outcome does not materialise. This is not “a user problem”: it is a Business Implementation risk or issue to manage.
After go-live: hypercare and handover
The immediate period after activation often needs hypercare: closer support, monitoring, quick fixes and feedback collection. It should have duration, owner and exit criteria.
At the end, the project carries out the handover to operations. The operational owner accepts responsibility for the service, support, recurring costs and routine improvements. Material new evolutions may become new projects or separate changes.
Who does what
| Role | Typical contribution |
|---|---|
| PM | Coordinates plan, readiness, dependencies, evidence and handover. |
| BM | Leads business implementation, adoption, processes and benefits. |
| PO | Maintains focus on value, results and sustainability of change. |
| SP | Ensures technical transfer, quality, documentation and solution supportability. |
| BIG / key users | Validate processes, participate in training and foster adoption. |
Responsibility for benefits does not magically end at go-live. It must be explicitly assigned, especially because many benefit measures are observed after the project has closed.
Do not confuse these
| Statement | Correction |
|---|---|
| “Go-live means transition is complete.” | Go-live is one moment in transition; support, stabilisation and handover may continue. |
| “If the deliverable is accepted, the benefit is guaranteed.” | Benefit depends on real use and organisational factors. |
| “Training and one email are enough for adoption.” | Processes, roles, support, involvement and measurement are also needed. |
| “After closing, nobody needs to deal with the solution.” | Operations takes ownership; the project closes, the service continues. |
Three questions to anchor it
- Who owns the solution and support after the project ends?
- Which operational behaviour must change for the output to produce an outcome?
- Which indicator will demonstrate that the expected benefit is materialising?
Flashcards
Q: What is the difference between output, outcome and benefit?
A: Output is what the project delivers; outcome is the change created by its use; benefit is the measurable improvement that results.
Q: What is the Transition Plan for?
A: To coordinate orderly transfer of solution, responsibilities, support, knowledge and operating conditions into operations.
Q: Why is Business Implementation needed?
A: To prepare people, processes and organisation to adopt change and obtain benefits.
Exam-style question
A new feature has been tested, accepted and published. The team closes the project without assigning operational support, training collaborators or defining how to measure reduced no-shows.
What is the correct assessment?
Answer: technical delivery is insufficient. Elements of Transition and Business Implementation are missing: handover, support, adoption and benefit measurement. The project risks producing a correct output without sustainable outcomes and benefits.
Source
Transition Management, the Transition Plan, Business Implementation Management and the Business Implementation Plan are covered in the European Commission’s PM² Methodology Guide 3.1.
This article completes the block on the main cross-cutting management activities. The natural next step is to work on PM² artefacts: how to use them without turning them into sterile documentation.