The Teal Book: Part F
The purpose of transition into use is to move the built or developed solution into its intended future environment so that it can be used. Transition into use also includes formal handover of accountability of the outputs from the senior responsible owner and their programme or project team to the future solution owner or operator.
Transition into use needs to be managed so that:
A well-planned and managed transition leads to fewer issues in initial operation and builds confidence in those who will be operating and using the solution over the longer term. It also builds trust with the solution owner or operator for the delivery of future work within the portfolio.
Transition into use is the set of activities which are focused on meeting the acceptance criteria for handover to the future owner or operator. It makes sure the solution works as intended and that the future owner and operator are capable of managing it on an ongoing basis.
The receiving organisation can be the body which sponsored the work, another public or private sector organisation charged with owning or operating it, or sometimes a broader group of stakeholders (for example, local authorities following a grant programme or social project)
Transition into use does not have to happen all at once. It can use many combinations of iterative and incremental approaches. For example:
All these approaches rely on understanding when certain outputs need to be available, and when they need to be verified and validated, and where necessary, integrated. In every case, the exact configuration of the solution needs to be known at the point of handover if verification, validation and ultimately acceptance are to be valid.
As most government programmes and projects rely on suppliers, transition into use needs to be founded on robust contract terms. Maintaining traceability can help avoid disputes and delays (see Chapter 23: Traceability management and Chapter 25: Procurement and contract management.
Transition can also happen at any point in the development of the solution when a solution or part of a solution moves from one state to another. For example, a digital service might move:
In these cases, much of the advice in this chapter applies except that overall ownership remains with the senior responsible owner, although accountability within the team can change, for example from a developer to a trial manager.
Anyone overseeing or managing transition requires an understanding of how to plan for transition, manage the transition and its resultant impacts and of their responsibilities in managing them. Accountability and responsibility for transition into use should be clearly defined within the governance and management framework for the work and reviewed on a regular basis, to avoid duplication or gaps. Typically, accountability follows the hierarchy in the work breakdown structure, but some roles can also be designated as having cross-cutting responsibilities.
The senior responsible owner, in a programme or project, has overall accountability for transition into use and owns the transition management framework, ensuring that it is effective in providing the capability and capacity needed to deliver the solution successfully into use.
The programme or project manager, as appropriate, is accountable for developing and managing the transition management framework, including its processes, tools, techniques, and for ensuring that it remains effective through the life cycle, as well as acting as the transition manager. They may exercise through a dedicated transition board, which they may chair, usually as a sub-board reporting to the programme or project board. bringing together programme, project, operations and supplier leads to:
Depending on the scale and complexity of the work, there could be a dedicated transition manager (often from a support office) with responsibility for overseeing transition management on behalf of the programme or project manager. They may be supported by transition specialists.
Transition specialists should develop the strategies, methods and plans to be used, in line with an agreed and compatible transition and change strategies, whether ‘big bang’, incremental or iterative. The responsibilities normally follow the solution hierarchy (sometimes called a system hierarchy or product breakdown structure) and are heavily influenced by the integration, verification and validation strategies. The role title for people who manage transition differs widely, depending on the type of output and methodology used.
A crucial part of transition is the transfer of ownership and so the future solution manager should be involved in planning and be engaged throughout the actual transition of the solution, including the formal acceptance of ownership.
A solution can only transition into use when it’s ready to operate and the receiving organisation can use or run it. It is not always necessary or desirable to wait for an entire solution to be ready before those impacted by it can benefit. A good delivery strategy aims to realise benefits as soon as possible.
If the solution is being transitioned in stages, the integration strategy should set out which groups of outputs need to be available for that to happen. As the integration strategy builds on the high-level design, transition needs should be considered as part of that design (see Chapter 33: Solution development and integration). For example, there is no point in relying on a training system in transition if that training system has not been included in the high-level design.
Handover is when accountability passes from one party to another. This transfer of accountability can be:
All involved parties should know when a transfer of accountability takes effect and what the implications are on their respective roles and obligations. This is particularly important during periods of concurrent working or where handover is progressive.
If there is a contract boundary, the contract itself should define the requirements, criteria and mechanisms for handover. Agreeing this at the point of transfer is too late, although confirming the practical implications of what has already been agreed before handover is needed.
Transfer of accountability can be based on 2 distinct approaches. These apply whether the handover is internal to an organisation, between government organisations or between a sponsoring organisation and a supplier or another delivery partner (for example a local authority).
An output-based approach means requirements for a solution and its parts are defined in specifications, sometimes called system requirements. Acceptance is based on verification (see Chapter 34: Verification and validation).
An outcome-based approach means requirements are framed as user or stakeholder needs. Acceptance is based on validation (see Chapter 34: Verification and validation).
In a larger programme or project, acceptance criteria can be a combination of both approaches. Decisions on acceptance criteria should be considered as part of high-level design and incorporated into procurement and contractual documents, or agreements between organisations. Handover should not normally proceed until the acceptance criteria have been met.
‘Build-and-operate’ and outsourced contracts tend to use the outcome-based approach, or a combination of both, and are used if the sponsoring organisation is unlikely or unable to manage the solution on an ongoing basis.
Before transition, everything needed to operate, maintain and use the solution should be ready. Depending on the type of solution, this can include:
Asset data should be verified and prepared for transfer, taking account of security and other statutory requirements.
Transition into use should be planned and managed together with the management of the organisational and societal changes (see Figure 36.1 and Chapter 35: Management of organisational and societal change).
The transition and change management teams often depend on each other’s outputs. For example, the transition team may produce operating manuals that the change team needs, while the change team may manage the communications strategy that the transition team relies on. An appropriate multi-disciplinary team should be mobilised to plan and carry out the work, with each member providing their expertise.
In the case of upgrades to existing solutions, a typical goal is to minimise disruption to ongoing operations. This should be understood from the start of the programme or project, and defined as a user need, as significant work is often required to achieve continuity.
When the solution replaces an existing or legacy solution, the migration should be planned and managed so that users do not experience any unplanned interruption in services.
Even when a new solution is introduced, there is potential to disrupt other services. For example, a new online service leading to a spike in user numbers which destabilises the platform, or a new road increasing or decreasing traffic on existing roads. These wider impacts should be considered and planned for as far as possible.
Issues are still likely to be discovered after the solution has come into use. That is why the reference project life cycle (see Chapter 14: Programme and project life cycles) includes an initial operation and use stage.
Some issues could relate to defects that were not apparent at the point of handover, but others could relate to the user needs not being met, or to poor communications. Even the most thorough validation activities are unlikely to capture every scenario of use. All types of issue need to be recorded and acted on (see Chapter 21: Issue management).
Where a solution or part of a solution is supplied or operated by a supplier, there are often warranty, guarantee or maintenance clauses in the contract defining how these should be dealt with. In other cases, it is for the owners of the solution to decide what action to take.
As a programme or project moves towards completion, team members may face uncertainty about what comes next for them. At the same time, accountability and responsibility for the solution is shifting to the people who will own and operate it, which can create tensions.
The programme or project manager should be aware of these dynamics and support team members through the transition, for example by helping them prepare for or find new roles.
Planning for transition into use should start, in outline, as soon as the relevant user needs have been identified. By the time the high-level design is completed, an outline strategy should also be in place and the need for facilities, tools and resources known.
The transition strategy should reflect the user needs, especially the need for operational continuity. It should be compatible with the change management, verification, validation and integration strategies.
Where possible, most verification and validation should happen before transition into use to reduce the likelihood of faults being discovered during this period. The expected time and cost constraints associated with the transition strategy should be planned for and requirements factored into procurement and contract documentation.
Transition into service usually includes verification and validation activities encompassing the whole solution, often as demonstrations or operational trials. These activities can require extensive planning ahead, and sometimes special resources (such as facilities) which need to be booked ahead or even created specially.
The contracts with suppliers need to be understood in full and interpretations agreed in advance between parties if there is any ambiguity. If a dispute arises, it is the terms of the contract that prevail in arbitration. Be especially careful not to approve anything the contract does not require to be approved as often contracts leave approval to the end of a warranty (or similar period).
Transition into use comprises similar activities whether applied to the whole solution of individual parts of it. Transition normally happens towards the end of the programme or project life cycle when ownership moves from the senior responsible owner to the future solution owner or operator. Transition can also happen when the solution passes from one interim state to another, such as when a digital solution is moved to a test or trial environment or a building is handed over from the constructor to another supplier for fit out. The key activities are summarised in Figure 36.2.
The approach to transition should consider any processes, methods, tools and techniques to be used. This forms part of the overall governance and management framework for the work (see Chapter 4: Governance and management).
See 36.6.2 on preparing to transition for activities which inform the governance and management framework.
Overseeing transition into use ensures that the transition management is considered early and planned into the solution design and delivery strategy.
Transition of major solutions relies on coordinating many activities, often within a short time period. Requiring tracking of progress, understanding the results of related verification and validation activities, and maing timely decisions on whether the solution can be handed over.
It also makes sure that that the framework continues to fulfil its purpose and meets the needs of the work. This can be achieved by:
Detailed planning for transition should follow the approach in the transition strategy and reflect what is needed to handover, operate, maintain and use the solution .
The time units and detail for the plan should reflect the types of work, their criticality and the planning horizon (see Chapter 16: Planning). For example, a sensitive operational transition, such as a new digital service or changes to track layouts in railways, can take place over a weekend and requires planning down to hours and minutes; whereas transitioning a new prison into operations might be planned and monitored in term of weeks and months.
The plan should take account of risks associated with transition activities that can be problematic, such as data migration, with schedule buffers placed to avoid overruns. Concurrent or shadow running before handover can help reduce risk. Backout and contingency plans should be developed where needed, with timings and decision points factored into the transition schedule. If old solutions are to be decommissioned (see Chapter 37: Use and disposal), the plans for that should be integrated with the transition plan and dependencies managed.
Each activity in the transition plan should be tracked, assessed and analysed, if appropriate, collated into reports and take action to address any variances or problems which have been identified (see Chapter 17: Controlling).
Depending on the acceptance criteria, verification and validation of the whole solution, or of an operational part of it if transition is phased, should be carried out in a controlled environment. This should be followed by a readiness review before a decision is made part of a readiness review on whether to hand over the solution formally and release, activate or commission it (see 14.7.2 on gates and decision points). This is often called the ‘go or no go’ decision.
User and operator training is often undertaken before final handover using supporting operational and user documentation, so that users and operators are ready to take ownership at the point of handover.
Full asset management and other data should also be made available, represented as the ‘as built’ reference point (see Chapter 23: Traceability management).
The transition team should normally be kept on during the initial operation of the solution to deal with defects which were not resolved before releasing the solution and to support the new owners, sometimes known as hypercare.
Introduction of the solution and activation of interfaces should be completed and demonstrated in accordance with the acceptance criteria and, where relevant, contracts. The sponsoring body needs transition to be effective so that the solution can be used and benefits can start to be realised.
Suppliers also rely on such records for payments. Accurate record keeping should include:
Once the programme or project has been completed, the management framework should be closed and information archived in accordance with the sponsoring organisation’s information retention policy (see Chapter 24: Information and data management).
Page permissions updated for public launch.
First published for closed beta consultation.