Chapter 32. Solution design

For all but the simplest solutions, a systems approach should be taken to designing the solution. This makes sure the needs of stakeholders, including the sponsoring organisation are met and that all aspects of the solution work together (see Chapter 33: Solution development and integration).

The solution or system hierarchy provides clarity on the scope of each component and the interfaces between them, whether social, physical or virtual. The entire solution should be considered when investigating options, and high-level design (often called a high level target operating model, system architecture or outline design) is selected.

The high-level design can then be progressively broken down into its component parts, including those managed by suppliers, to product a detailed design.

Those designing the solution do not generally have complete freedom to define it. The design is often constrained by legal and regulatory requirements, and by constraints imposed by the sponsoring organisation and government policies.

Government policy constraints are often enacted in law but can also be implemented on a voluntary basis, for example through a code of practice with trade or professional associations, local government bodies or charities. From a systems perspective, the design of a solution should not detract from or conflict with other solutions for implementing government policy, whether in development or enacted.

Regulatory requirements exist including those for aviation, railways, building control and environment, and health and safety. Such regulations are imposed by law and must be factored into the design, build, use and disposal of every solution. Legal requirements also include social aspects such as equality and diversity, data privacy and human rights.

Constraints imposed by sponsoring organisations often include security requirements, digital architectures and the selection of technical parts, for example a digital service or building asset management. The Government Functional Standard for Digital requires greater sharing of data and technology across government and the pooling of resources, through shared services.

The solution design should include the outputs needed to achieve the desired outcomes. This means the design should, depending on the need, reflect requirements relating to people, software, equipment, operations and maintenance products, manufacturing, security, information, organisation design, supply chain, performance characteristics and desired behaviours.

Different phases of the solution’s life cycle often need their own designs, represented by interim operating models. The design should address not only the needs of end users but also the needs of each phase, including feasibility and integration, verification and validation, transition into use, ongoing support and maintenance, and eventual disposal.

For feasibility and integration, the design should support those building or developing the solution and putting its parts together. This might include the ability to build components offsite or in a separate environment and integrate them incrementally, or to develop and implement transformation progressively (see Chapter 33: Solution development and integration).

For verification and validation, the design should support making sure the solution is built correctly, works as intended and serves the right needs (see Chapter 34: Verification and validation).

For transition, the design should support putting the solution into service, whether in full of incrementally. This could include staging environments for digital systems, such as for data migration or training, or formal trials and shadow operation (see Chapter 34: Verification and validation, Chapter 35: Management of organisational and societal change and Chapter 36: Transition into use).

For support and maintenance, the design should make sure end users have the capacity and responsiveness needed. For example in a new digital system or operational building, or where vehicles and machinery can be serviced within required downtime constraints (see Chapter 37: Use and disposal).

For disposal, the design should make sure those dismantling all or part of the solution can do so in a sustainable manner. For example, when decommissioning a nuclear facility (see Chapter 37: Use and disposal).

The high-level design is the foundation for and sets the constraints for all the above.

The methods and processes for designing solutions vary in terminology, approach and the way they are documented. Design methods are often part of an overall development methodology for a particular type of output, and can be proprietary or developed in-house.

The approaches, however, have many features in common. A programme or project manager does not need be a specialist design methods, but does need enough understanding to frame decisions and track and control progress on design work. The means of tracking progress should be understood and appropriate to the type of work and people involved.

The main challenge with design work, which involves being creative, is that much of it is intangible, cannot be observed and can be difficult to predict. Planning needs to take into account the uncertainty over the cost and duration of design work (see Chapter 16: Planning).

As the concept for a solution emerges, not every option will meet the needs and requirements to the same extent. A balance needs to be made between what  can be fulfilled and the proposed design.

Different design concepts have different risk profiles, both overall and for specific parts of the design as well as for the phases of the solution life cycle where those risks are most apparent. For example, a risk could be responded to by specifying more expensive materials or additional people, or by putting in place a regime of regular inspections to verify a component continues to meet its requirements. These options have different cost implications, and each choice alters the nature of the risk being taken.

Because of this balance between user needs, requirements and design, these activities are usually iterative.

Traditionally, validation against user needs has been done as part of formal trials, once the whole solution is in operation, such as in sea trials or for a new approach to social benefits.

However, validation should be carried out throughout the design of a solution, using techniques such as prototyping, simulation, virtual reality walkthroughs or model offices. This helps validate that what is proposed is likely to meet the needs before final outputs are developed or built (see Chapter 34: Verification and validation).

Solution design is a specialist discipline and the approach, documentation and tools used depend on the methodology chosen for a particular output. Regardless of the method adopted, those working in project delivery need to understand the context for the work, the management approach being used and why it was chosen.

Understanding the user needs and requirements provides the context for designing the solution. User needs and requirements include end user needs, business requirements and both functional and non-functional requirements (see Chapter 31: User needs and requirements).

A management framework should be defined and established, which is appropriate to the solution as a whole and for each separate component of the solution (see 32.6.1.4 on choosing the appropriate design approach). For most programmes and projects, several methods are likely to be needed, each reflecting the appropriate practices for that type of work (see Chapter 10: Tailoring to the nature and context of the work).

The methods should be organised so that they can be consolidated to form the whole solution and to support monitoring and reporting. The solution design activities in 32.6.3 can be used as a basis for checking the processes and procedures being used.

Preparation for designing the solution is the responsibility of the solution designers. How they are organised depends on the solution hierarchy. At a programme level, the focus should be on the high-level design and how the solution is made up of its component parts. The individual components are likely to be managed at project or work package level.

It is important to be able to trace the design work package to the plan to make sure dependencies are properly reflected and decisions are identified. There should be a management framework to manage traceability from a design component to its requirements and among groups of closely associated system components.

Without this, tracing the impact of risks, issues and subsequent changes can be time-consuming and prone to error, leading to poor and costly decisions. See Chapter 22: Change control and Chapter 23: Traceability management.

Solution design comprises a set of continuous activities undertaken throughout the life of a programme or project. The activities are influenced by the user needs and requirements and by issues identified when undertaking the work. The activities are recursive and iterative through the solution hierarchy and are summarised in Figure 32.2.

The approach to designing the solution and its component parts should be defined including 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). The important aspects of this activity are discussed in more detail in section 32.6.2.3 on defining the solution design framework. The framework should be maintained to address relevant feedback from its use.

An overall understanding of how the design work is progressing should be maintained throughout. The design of the solution should be planned in a hierarchy and traceable to the requirements. Some requirements can be validated individually, and others only after integration of closely related parts or of the full solution. Once work is underway, an overall view progress towards fulfilling requirements needs to be assessed and corrective action taken if needed (see Chapter 17: Controlling).

The solution design framework needs to be monitored to make sure it remains effective and appropriate as the work proceeds.

The team undertaking the high-level design should consider a range of options (design approaches, design concepts, or preliminary designs) that can satisfy user needs and requirements. This should takr into account the availability of resources (internal and supply chain), risk, complexity and value for money. The Government Functional Standard for Project Delivery requires the options to be assessed in accordance with Government Functional Standard for Analysis. After analysis is completed, a preferred solution should be recommended for detailed design.

The Government Functional Standard for Digital should be complied with for digital components of the design

The Government Functional Standard for Property should be complied with for buildings and facilities which are components of the design

Once approved, the high-level design should be baselined (often called a high level target operating model. system architecture baseline). Changes to the high-level design require the baseline to be changed formally (see Chapter 22: Change control and Chapter 23: Traceability management).

Design often requires balancing one set of needs and design solutions with alternatives (see 31.6.1.4 on balancing requirements and design). The types of analysis needed include costs analysis, affordability, risk, feasibility, operational conflicts, trade-off in requirements and evaluation of strategies such as for integration and validation. These analyses are usually quantitative and involve modelling and simulation.

The results inform the choice of architectural option, the selection of appropriate components in the solution design and which user needs and requirements can be fulfilled, whether fully or partially. The formality and rigour of the analysis depend on how important the information is and how much information is available. This activity can also be used to support any aspect of solution delivery where choices need to be justified and decisions made.

While the high-level design is conceptual, the detailed design should focus on the realisation of the design in terms of components of the solution, such as process, structure, software, physical components, human operations and services. The solution should be specified in enough detail to enable its parts to be verified as compliant. There should be two-way traceability between the high-level design, design components and the plan. The form it takes is dependent on the component for example, process flow maps for business operations, drawings for civil engineering works.

Once the detailed design has been approved, it should be baselined (often called a solution or system design baseline). Changes to the detailed design require the baseline to be changed formally (see Chapter 22: Change control and Chapter 23: Traceability management).

Once the programme or project has been completed and requirements management is no longer needed, the management framework should be merged into the management framework for the solution or closed. Information and data should be retained in accordance with the sponsoring organisation’s information retention policy (see Chapter 24: Information and data management).