Part F: Introduction

The purpose of the solution delivery practices is to make sure the right solution is developed to the required quality, in a way that can be maintained over time.

The practices in this part of The Teal Book contribute to the quality of the solution. The solution delivery practices should be managed and monitored using the planning and control practices (see Part E: Planning and control).

A portfolio, programme or project manager does not need to be a solution delivery expert. But as the person accountable for managing the work, they need to understand enough to be confident that an appropriate solution is developed within the constraints defined in the business case and that progress can be tracked. See Figure F. 1.

Solution delivery practices apply to any type of solution or part of a solution, whether technical or people-based, using any delivery approach such as adaptive, iterative, incremental or predictive. For example, it is usually necessary to iterate the requirements and the design to achieve a viable solution which represents value for money.

The practices in Part E: Planning and Control and Part F: Solution delivery of The Teal Book should work together, as the outputs from one are often the inputs to another practice. The primary relationships and information flows among the practices in The Teal Book are shown in Figure F. 2.

Just as the practices needed to plan and control the work need to function together, the components (also called elements) of the resultant solution need to work together. The design, development, integration, operation and disposal of a solution, the environment it operates in and the other solutions it interacts with, all need to be considered. The behaviour of the ‘whole’ is usually different to the sum of the behaviours of the individual parts. This holistic way of looking at a solution is called systems thinking. Systems thinking can be applied to disciplines as diverse as social sciences, engineering and management, often in combination. It focuses on relationships, causality, feedback loops and emergence and is well-suited to complex situations.

A system is an equivalent to a solution and has its own solution or system life cycle, from concept through to disposal.

The Project delivery glossary defines a system as:

Arrangement of parts or components that work together to provide a product, service or outcome.

A solution needs to be designed for all the phases of a system life cycle. Table F. 1 shows some examples. The number and naming of the phases should be chosen to emphasise what is important with respect to the solution being delivered. Do not confuse a solution or system life cycle with a programme or project life cycle (see Chapter 14: Programme and project life cycles) nor with a systems development life cycle (which is a development approach for digital solutions).

Different techniques can be used to analyse a solution using a systems approach. One common technique is solution hierarchy (also called a system hierarchy or product breakdown structure). This breaks a solution down into its component parts, grouping smaller parts under larger ones.

The solution hierarchy can be useful for assigning accountability. Each component has a manager who is responsible for everything within it,  including all the levels below it, and any gaps or overlaps between components.

In many cases a solution relies on other independently managed systems to meet its requirements. In this case, a system of systems needs to be considered.

The Project delivery glossary defines a system of systems as:

A collection of systems which can operate independently fulfilling a purpose on their own, are independently acquired and managed, and can maintain a continual independent operational existence.

The system of interest is the specific system whose life cycle is under consideration. In The Teal Book, this means the solution itself. As government services become more connected, understanding how systems interact is increasingly important.

Systems thinking is most needed when a solution becomes complex as opposed to complicated. A complicated system is one which involves the management of a large number of requirements and components where the outcomes are predictable and reproducible. On the other hand, a complex system is one where the relationships are not always predictable and reproducible; they can evolve and have emergent behaviour. To manage a complicated system, it is necessary to coordinate a large number of components comprising the solution; this is known as traceability management (see Chapter 23: Traceability management). To manage a complex solution, it is essential to navigate an emerging landscape, observe, interpret, learn and act. Complex systems often include the natural environment and people as essential components, and their behaviour determines the outcome. Where people are concerned the management of organisational or societal change is necessary if the outcomes are to be achieved (see Chapter 35: Management of organisational and societal change).

The names of roles relating to solution delivery vary widely depending on the outputs delivered and delivery approach used. Generally, there should be one person accountable for the integrity of the whole solution, called a solution architect in The Teal Book. Other names include system engineer chief engineer. This person is supported by teams of specialists, each addressing their respective part of the solution.