The purpose of solution development and integration is to ensure that the designed solution is developed and built in a defined way such that the different parts of the solution work together when in use.
Previous
Chapter 32. Solution designThe Teal Book: Part F
Chapter 33. Solution development and integration
33.1 Purpose of solution development and integration
33.2 Key points
- Preparation for solution development and integration starts when the high-level design is defined.
- The solution’s high-level design determines the development, integration, verification and validation strategies.
- Plan the resources, environments, tools and facilities to be ready when needed.
- Allow extra time for addressing problems and defects and any necessary redesign.
- Keep monitoring and measurement simple, timely and useful.
33.3 Why manage the development and integration of the solution?
No matter how creative and thorough the solution delivery team is in designing the solution to meet the user needs and requirements, unless that solution can be realised within the constraints, the desired outcomes and benefits are unlikely to be achieved.
Solution development and integration is normally when most cost is accrued so careful management of this work is needed to stay within the constraints defined in the plan and to deal with emerging risks and issues.
Attention to detail counts. Getting rail signalling or timetabling wrong can cause major delays and costs. Inadequate support for service changes can reduce employee moral. Even providing the wrong version of an instruction manual with a product can undermine confidence at best and be dangerous in the extreme.
33.4 What is solution development and integration?
‘Solution development’ covers a wide range of circumstances and types of output, including building infrastructure, developing digital solutions, delivering transformational change and providing military equipment.
Solution development and integration are usually the most visible aspect of solution delivery for programmes and projects which have physical outputs, such as buildings, roads and railways. Even digital services need physical components such as the hardware, servers, transmission media as well as the buildings and facilities to house them, whether in-house or contracted out. Equally, infrastructure, military and transformation solutions increasingly involve digital development and integration, which can be less visible but no less critical.
All solutions involve people. For some solutions, people are central to the development of the solution, as customers, service users or as employees involved in transformational change. Even back-office capabilities need people to service and maintain them, and require space such as offices, workshops, storage space and training facilities. All these groups of people often need communications, guidance or instruction manuals.
Solution integration is concerned with bringing these diverse outputs together to form a resilient solution that satisfies both the user needs and system requirements.
The Project delivery glossary defines solution integration as:
The progressive assembling of a solution’s components into the whole system.
The term ‘integration’ is often associated with engineering but in systems thinking it is much broader, encompassing human and environment aspects. Human aspects include training, resource capacity, skills, human factors, safety, occupational health, survivability, and habitability.
33.5 Who manages the development and integration of the solution?
For a programme or project, the senior responsible owner is accountable for ensuring a solution development and integration framework is in place and that it is effective.
The programme or project manager is responsible for ensuring the development and integration strategies and methods are in place, managed and used. They may not be an expert on all the types of outputs that comprise the solution. However, they should understand the language and terms used sufficiently to be able to communicate with the specialists enough to track performance. Strategies and methods should be owned, defined and used by a solution specialist, sometimes known as solution architect, product developer, change manager or organisational developer. The solution specialist usually works with designated component specialists, each responsible for one or more closely related outputs that comprise the parts of the solution.
Such outputs are managed in work packages, where the work package manager is usually a specialist in the component being worked on. The responsibilities normally follow the solution hierarchy (or system hierarchy, product breakdown structure, or in organisation design, the future state organisation structure). The role titles for people who manage development and integration differ widely, depending on the type of output and methodology used.
For larger scale and more complex work, the development and integration of the solution, its quality and other attributes, are often supported by a design authority or similar arrangement. This brings together people with the relevant expertise to make collective decisions on design, track progress and oversee the integration of the components that make up the solution.
33.6 How to manage development and integration
33.6.1 What to consider when developing and integrating the solution
33.6.1.1 Monitoring the work
It is impossible for a programme or project manager to verify or even see the progress on all but the smallest of projects. In the case of digital components of a solution the outputs are often invisible. It is important for the programme or project manager to come to an agreement with the development and integration specialists on how progress is to be objectively measured. This should include data for work that has been completed and forecasts for work yet to be completed.
Where work is undertaken by a supplier, the contract should include clauses requiring the provision of such data (see Chapter 25: Procurement and contract management). All data collected should serve a useful purpose and inform understanding of how work is proceeding. The best measures require minimal effort to collect, preferably as a part of doing the work, and should also be easily understood.
33.6.1.2 Agreeing the integration strategy
A solution specialist should develop an integration strategy, defining the approach to sequencing delivery and bringing together the various parts of the solution, including any special facilities or temporary environments required.
Managing integration should focus on the static and dynamic interfaces between parts of the solution, whether physical, digital or human. For example, a moving train must fit in a tunnel alongside the signalling and control equipment; digital systems need to pass data over reliable interfaces; and people need to communicate with each other and use the equipment.
Integration is closely associated with verification and validation (see Chapter 34: Verification and validation). Each time parts of a solution are joined up, the correctness of the interface needs to be verified and its functions validated. The integration strategy and verification and validation strategies should therefore be designed to work together.
The integration strategy should take account of:
- the way the high-level solution has been defined
- the delivery dates of the various parts of the solution
- the availability of people required to sustain those parts once in place
- the level of problems, defects and issues likely to be encountered, and time needed to address them
The people, tools, environments and facilities required to perform integration should be planned and designed in advance, when the high-level design of the solution is undertaken. Planning the integration of groups of closely related parts, sometimes called integration aggregates, can lead to the early identification of problems. Table 33.1 includes some commonly used integration strategies.
| Strategy | Commentary |
| Global integration | Also known as ‘big bang’. Integration is done in a single step, without any simulation of unavailable or higher risk parts of the solution. This increases risk, because problems are not detected until the end. Consequently, the impact of failure is usually greater and detecting root causes is more difficult. This strategy is reserved only for simpler, low risk solutions or situations where circumstances make it unavoidable. |
| With the stream | Parts of the solution are integrated as they become available, so integration starts sooner, but simulators are needed to emulate missing parts of the solution. It is often impossible to control the end-to-end functionality, however, so this is better reserved for controlled solutions with low technological risks. |
| Incremental | Parts of the solution are added incrementally, in a predefined order. Fault detection is usually localised in recently integrated parts. Simulators are used for missing parts. This is appropriate for any type of high-level design or architecture. |
| Subsets | Parts are integrated into subsets (aggregates) which are then integrated into the ‘whole’. This strategy enables simultaneous integration, early fault detection and partial delivery of a solution. The subsets are usually based on the solution’s sub-systems. |
| Criteria driven | The most critical or risky parts of the solution are verified and integrated first, allowing time for design changes if needed. |
33.6.1.3 Maintaining traceability
Traceability links every part of the solution back to the requirements and user needs that drove it. Maintaining two-way traceability from plan to work package, to design, to requirement, and to the individual parts of the solution, means the impact of any change request can be assessed efficiently and with confidence (see Chapter 23: Traceability management).
A change to a user need can have a significant effect on the plan, the design, including the build of the resultant outputs, the outcomes and benefits realised. Similarly, if it is found that a part of the solution cannot be built to the required specification, it is important to know which user needs or requirements are not being met and the impact that has on the viability of the overall programme or project.
33.6.1.4 Continuing verification and validation
Verification and validation should be undertaken throughout the development of a solution so that the quality and function of outputs can be assessed as each part of the solution is built (see Chapter 34: Verification and validation).
33.6.2 Preparing to develop and integrate the solution
33.6.2.1 Overview
Solution development and integration is a specialist discipline. The approach, documentation and tools used depend on the output being worked on. Regardless of what approach is adopted, people working in project delivery need to understand the context for the work so they can define and agree the management approaches to be used with those designing, developing and integrating the solution.
33.6.2.2 Start with the high-level design
Preparation for development and integration starts when the high-level design is defined (see Chapter 32: Solution design). Part of high-level design is ensuring the solution accounts for how the solution will be delivered, not just what it will look like when complete. User and system requirements should therefore reflect the strategies for development and integration, including logistics and resourcing. Defining the high-level design and the associated requirements is usually an iterative process.
33.6.2.3 Make sure your strategies are robust
The strategies for development and integration should be defined alongside those for verification and validation, which often require specialist resources, tools and facilities. Such strategies should be fully challenged, for example by panels of experts or peer review.
33.6.2.4 Make sure the management information systems are adequate
Management information systems for tracking risks, issues, change control and traceability should be established before development work starts, as should information systems for tracking verification and validation (see Chapter 24: Information and data management).
When development work starts, the measures and tools for tracking and reporting progress are likely to need updating to accommodate new types of work. In technology and engineering work, specialist systems are often needed to track the identification and resolution of defects found as a result of verification failures. Such systems are important throughout the life cycle of the work, and are particularly important during delivery before its transition into use.
33.6.3 Key activities in managing solution development and integration
33.6.3.1 Overview
Solution development and integration comprises a set of continuous activities undertaken during the life of a programme or project. The activities are iterative, influenced by the emerging risks and issues identified when undertaking the work, with similar activities repeated through the solution hierarchy, as summarised in Figure 33.1.
33.6.3.2 Develop and maintain the solution development and integration management framework
The approach to developing and integrating the solution and its 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 33.6.2 on preparing to develop and integrate the solution. The framework should be maintained to address relevant feedback from its use.
33.6.3.3 Oversee solution development and integration
An overall understanding of how development and integration work is progressing and what the prevailing risks are (see Chapter 20: Risk management) should be captured. Problems and defects identified during the work should be investigated to see if there is any pattern or underlying cause, which should be addressed (see Chapter 21: Issue management) .
The solution development and integration management framework should be monitored to make sure it remains effective and appropriate as the work proceeds.
33.6.3.4 Build solution
The progress of development or build of each part of the solution should be tracked, and problems or defects should be detected and rectified (see Chapter 17: Controlling and Chapter 21: Issue management). Outputs should be verified for compliance with specifications and validated for functionality as determined in the plan. If problems and defects cannot be rectified within the current specification, those parts of the solution may need redesigning or the requirements amending through change control (see Chapter 22: Change control).
33.6.3.5 Integrate solution
The integration of each part of the solution should be tracked, and problems and defects should be detected and addressed (see Chapter 17: Controlling and Chapter 21: Issue management). Interfaces should be verified for compliance with the specifications and validated for functionality as determined in the plan.
33.6.3.6 Approve solution
Once the development and integration work is complete it is normal practice for the solution to be formally accepted by the solution owner. This can be in total or incremental as each useable part is available. Depending on the circumstances such approval can be before, during or after the transition of the solution into operational use.
33.6.3.7 Close the solution development and integration management framework
Once the work has been completed, the management framework should be either merged into the management framework for the solution or closed. Information and data should be retained in accordance with the solution owner’s information retention policy (see Chapter 24: Data and information management).
Updates
Page permissions updated for public launch.
First published for closed beta consultation.