The purpose of use and disposal is to:
- use, maintain and operate the solution to fulfil its defined purpose
- shut down all or part of a solution and dispose of or reassign any residual facilities and materials
The Teal Book: Part F
The purpose of use and disposal is to:
Until a solution is used, no outcomes and benefits can be realised. How a solution is used determines how efficient and effective it is and whether it is sustainable over the period it was designed for.
For example:
When a solution or part of a solution comes to the end of its useful life, it needs to be shut down and then disposed of. The cost and time involved can be significant, especially in cases such as nuclear decommissioning. The approach to disposal needs to be planned into the design and risks identified.
Unless use and disposal are actively managed, policy aims and objectives are unlikely to be achieved.
Use is the operation and maintenance of a solution so that it continues to fulfil its intended purpose., which can be known as the sustainment model. This includes routine maintenance and minor upgrades, which are often managed as business as usual. In many cases, particularly in digital and data or transformation work, parts of a solution are progressively renewed or upgraded through continuous improvement. If the changes are significant, they may be managed as a new project.
Disposal is the planned shutdown and removal of a solution, or part of a solution, when it is no longer needed. Depending on the nature of the solution, this might be describes as retiring, withdrawing or closing it.
Use and disposal is relevant to project delivery regardless of how the sponsoring organisation chooses to organise its work. For example:
The senior responsible owner has overall accountability for the direction of the programme or project. As such, the senior responsible owner has the primary stake in making sure the solution is used and eventually disposed of appropriately. Formally the senior responsible owner’s accountability for the programme or project ends when the programme or project is closed. Before this, however, they should ensure that accountability for the ongoing use and eventual disposal of the solution has been agreed and is in place.
The specialist team which owns the solution is accountable for its use and disposal as soon as the solution has been handed over (see Chapter 36: Transition into use). The models of ownership vary considerably and there is no set pattern to cover all circumstances. The accountabilities therefore need to be defined on a case by case basis as part of the design of the solution.
The operations manager is the role overseeing the use and disposal of a solution, within the context of any other related activities. This role could be undertaken by a chief operating officer or, at a lower level, by a manager with accountability for a set of related services, such as on a digital platform
The solution owner is the role with direct responsibility for the solution. This could be a product manager, service manager or manager of a policy intervention
The project delivery team usually have a supporting role during initial use to deal with faults and resolve outstanding defects, as shown in the reference project life cycle (see Chapter 14: Programme and project life cycles). This is usually under a project manager. The initial use period is often governed by contractual maintenance, warranties or guarantees in the contract agreement to cover latent defects. A year is not an unusual time period for this. 
If use is included within the scope of a portfolio, programme or project, the portfolio, programme or project manager, respectively, has an oversight responsibility for use. Figure 37.2 is an example of a programme or project life cycle where operation and disposal are in the scope.

Disposal can be full, partial or continuous and can relate to a whole solution or just part of it. It can involve disbanding an operation and redeploying employees, disposing of a building or IT hardware, dismantling a major piece of infrastructure – or a combination of these.
At its simplest, disposal is managed by the operational team. For more complex situations, for example, disposal needs to be managed as a programme.
Just as the high-level design determines (and is determined by) the integration strategy, so is use and disposal constrained by the design. The breakdown of the solution into workable components determines the extent to which parts of the solution can be used independently and before other parts can be accepted for use. Similarly, the approach to disposal is determined by the way the solution is put together and can be dismantled.
A full design should include the requirement for partial or full disposal of the solution. For partial disposal, the design should accommodate the replacement of parts to increase the active life of the solution. For full disposal, the decommissioning and withdrawal of the full solution should have been designed for. In older solutions, reaching the end of their life span, it might be found that either the solution was not designed for disposal, or the methods proposed at the time have become outdated, inappropriate or even illegal. In this case a new disposal strategy needs to be developed, within the constraints of the ‘as-built’ solution and prevailing regulations.
In the case of upgrades to or replacement of existing solutions, disruption to ongoing operations and services should be minimised. This should have been understood from the start and defined as a user need, as significant work is often required to achieve such continuity.
Where a solution is no longer required, operations do not need to be maintained. However, anyone affected should be informed of what this means for them. If the solution is being replaced, the work for transitioning the new solution and disposing of the old solution needs to be coordinated. This often needs to be managed as a programme.
Planning for use and disposal should start early as soon as the relevant user needs have been identified. By the time the high-level design is completed (see Chapter 32: Solution design (requires sign in)), the need for associated facilities, tools, logistics and resources for operation should be known.
Use and disposal requirements should be identified and addressed during the development of the design, not after the solution has been handed over. The design should account for both the solution itself and any interim states it passes through.
Few solutions can be sustained without maintenance. The extent of maintenance required can vary on the type of solution and the environment it operates in, not forgetting that maintenance usually requires ongoing and reliable sources of spare parts.
In addition, demands on the solution can change such as users requiring additional functionality, regulatory authorities changing their rules or demand growing more than expected. Often, minor changes can be introduced as business as usual or included in maintenance work. Whether such work is considered new or just a part of ongoing use and maintenance needs to be understood, as it can affect funding and resourcing.
Digital products are often designed for continuous evolution through software and hardware updates, with ongoing provision for this allocated in operating budgets. However, the changes are categorised and managed, the primary focus should be on ensuring the solution continues to provide a useful and beneficial purpose.
In addition, demands on the solution can change such as users requiring additional functionality, regulatory authorities changing their rules or demand growing more than expected. Often, minor changes can be introduced as business as usual, included in maintenance work or continuous improvement. Whether such work is considered new or just a part of ongoing use and maintenance needs to be understood, as it can affect funding and resourcing.
Monitoring can be done through a range of techniques depending on what is being monitored. Where appropriate and feasible, continuous and remote monitoring, such as using a digital twin in infrastructure (see Chapter 24: Information and data management) and telemetry, should be considered with thresholds for alerting corrective and preventative action. Techniques associated with evaluation can be appropriate (see Chapter 2: Policy and evaluation).
The time between introduction and disposal of a solution can span many years, and the social, working and operating environment can change significantly over that time. Plans for disposal should be reviewed carefully when considering whether to extend the life of, evolve or dispose of a solution. Assumptions on costs and other social, economic and environmental impacts need to be tested to determine if they are still valid, as these can change the balance of a decision.
Financial accounting impacts should also be understood, and early advice sought from the responsible organisation’s finance team. Any change in asset value has an effect on the organisation’s accounts and should be planned for well in advance.
Use and disposal compromises a set of activities that commence once part of the solution transitions into use. The activities for use and disposal are summarised in Figure 37.3.

The use and disposal management framework should be developed before any part of the solution transitions into use. The activities for preparing to manage use and disposal feed into the management framework (see 37.6.2 on preparing to use and dispose of the solution). This forms part of the overall governance and management framework for the work (see Chapter 4: Governance and management).
The framework should define the approach to using and disposal of the solution including any processes, methods, tools and techniques to be used
It is essential to maintain an overall view of how the use of the solution and later disposal is progressing and what the prevailing risks and issues (see Chapter 20:Risk management and Chapter 21: Issue management) are from both internal and external sources.
An overall view of performance indicators, such as user feedback, operational metrics and financial measures, needs to be maintained, and preventative and corrective action taken as necessary. Non-functional performance such as accuracy, security, availability, usability and timeliness should not be neglected.
The management framework for use and disposal should be monitored to make sure it remains effective and appropriate as the work proceeds.
The solution should be used, operated and maintained as defined. Records should be kept up to date so that the status of the solution is known at all times as this is fundamental to future decisions that might be needed on changes (see Chapter 22: Change control). In particular, pay attention to:
Shutdown of the solution should be planned so that impacted stakeholders are aware of what is happening, when and how it could affect them. The withdrawal of capabilities needs to be sequenced to minimise unexpected side effects.This should be managed as organisational or societal change (see Chapter 35: Management of organisational and societal change). Those accountable for the ultimate disposal of the solution and its parts should plan disposal to be environmentally sustainable. For physical assets, options such as storing, dismantling, reusing for another purpose, recycling, reprocessing and destroying should be considered. Data assets should be handled in accordance with government requirements (see Chapter 24: Information and data management). The choice should take into consideration factors such as costs, disposal sites, environmental impact, health and safety issues, handling, transportation, relocation as well as relevant regulatory requirements.
The solution or parts of the solution should be shut down in accordance with the plan taking account of continuity needs, if any.
Once the solution or parts of the solution have been shut down, they should be disposed of in accordance with the plan for disposal. Information on the action taken and assets disposed of should be recorded, reported and stored, as this can be important for lessons learned (see Chapter 38: Learning from experience) and future decision-making, for example on land use.
Once the solution has been fully disposed of, the management framework should be closed. Information and data should be retained in accordance with the solution owner’s information retention policy (see Chapter 24: Data and information management).
Page permissions updated for public launch.
First published for closed beta consultation.