The Teal Book: Part E
The purpose of managing traceability is to ensure the relationships between the different components (or elements) of a solution and the associated management documentation are understood throughout the life cycle, such that, at any point in time:
In some sectors, traceability management can be known as configuration management or parts management.
Changes to requirements, designs, plans and management frameworks are inevitable when a solution is being developed and when in use. Unless the versions of, and relationships among, every element of the solution and its related management documentation are known, it is difficult to determine the impact of any but the simplest proposed change.
Traceability also ensures that a solution, or any part of it, can be reproduced at different points in the life cycle. This is particularly important in software development and manufacturing.
Without effective traceability management, teams risk:
By managing traceability effectively, change control is simplified and verification, integration and validation are more reliable.
Project delivery is made up of 2 fundamental types of work for which traceability needs to be managed:
This work helps ensure the integrity of the solution so that all of the components come together as planned and the output or outcome is delivered as scoped (see Part F: Solution delivery). It also ensures that contracts are properly specified and contractual documentation is maintained where suppliers are delivering some or all of the solution (see Chapter 25: Procurement and contract management).
The relationship between a solution’s components can span many levels. A single change can ripple across these relationships, which is why maintaining traceability matters to inform better decision making.
Consider a change request raised to amend a user need. This could require the system specification to be changed, resulting in a modified high-level design and consequent changes to the impacted component of the solution’s design. If that element is already in place this could require rework. If that element is within a supplier’s contract, the agreement might have to be changed by formal variation. This work could cost more and take longer, which could affect the viability of the programme or project to deliver the business case.
Traceability also underpins verification. Tests run on part of the solution are not valid unless they are reproducible through a defined baseline, which records the version, environment and conditions for the verification.
Figure 23.1 shows a simplified traceability scenario, to illustrate the above points. It also shows how traceability can highlight missing parts in the plan or contracts. In the figure, work package ‘x’ is not covered in any contract and component ‘z’ has no work associated with it. There should be two-way traceability from the higher-level to the lower-level components and back that comprise a solution as well as among different components.
The Project delivery glossary defines two-way traceability as:
The ability to trace both forward and backward (for example, from requirement to an element of the solution and from the solution element back to requirement). It can also be applied in other areas, such as to output-outcome-benefits mapping, and solution-plan mapping.
Benefits mapping uses traceability to connect objectives to benefits, tracing a path through the requirements, deliverables (solution components), outputs (parts of a solution), the solution and outcomes. The benefits map is a high-level view of overall traceability, ensuring the scope of the work and resulting benefits meet a policy need or the organisation’s strategic objectives, rather than controlling the components of the solution and its management documentation.
Chapter 19: Benefits management covers how to develop a benefits map.
The portfolio director and senior responsible owner are accountable for ensuring there is effective traceability management for their respective portfolio, programmes and projects.
The programme or project manager is directly accountable for ensuring traceability among the various management documents and data sets, including the business case, plans and associated baselines. Whilst not directly responsible for traceability among the components of the solution, the programme or project manager is accountable for seeing that it is done properly. If not done properly, there would be no evidential basis for decision-making and the programme or project should be considered out of control.
If a solution crosses organisational, programme or project boundaries, the solution architecture and configuration need to be held by a nominated team. This can be under a portfolio manager if the solution is contained within that portfolio.
The specialist team who owns the solution is accountable for traceability throughout the life of the solution from determining the user needs through design, development, verification and validation, transition and into use. Once in use the respective versions, status, relationships and baselines should be maintained until disposed of. If, however, use and disposal is within the scope of a portfolio, programme or project, the portfolio, programme or project manager has overall accountability for making sure it is done. Change of ownership for the solution usually passes from a development team to the ongoing owners as a part of transition (see Chapter 36: Transition into use).
If the solution or part of it is being undertaken by a supplier, the respective contract should state the obligations regarding traceability and include the amount of information the supplier is required to disclose and the rights of the sponsoring organisation to review or audit the work and records. In some cases, management and design systems need to be interoperable to enable the rapid exchange of data and information.
For large or complicated solutions, traceability is managed and undertaken by specialist traceability managers, usually in a support office. The role and job titles vary, usually known as ‘configuration manager’.
Traceability is closely related to change control and information and data management and should be managed together, as shown in.
Effective change management depends on understanding how user needs, requirements, design, the as-built solution and related contracts connect. A change in any of these can affect the others.
Change control and traceability are therefore closely related. Some disciplines treat together under the term ‘configuration management’, using a unified management tool.
Those working on or responsible for a solution should be confident they are working with the right versions of documentation and interfacing with the correct versions of the solution’s parts.
Where a solution involves physical components, the interface is usually visible. However, where these are not visible (for example, where components are performed off-site and integrated later, or where parts of the solution are digital or involve transformation in working practices or behavioural change), those working on those components know exactly what they are interfacing with and how.
Formal documentation and, where appropriate, drawings are usually held in data repositories, uniquely referenced and version controlled. Traceability is used to group specific versions of the data and information to define a ‘baseline’ against which work is done.
The Project delivery glossary defines a baseline as:
A reference basis for comparison against which performance is monitored and controlled.
A baseline groups together separate but related information. In project delivery, baselines typically apply to management documentation, plans and sets of data related to the solution.
For example, a baseline might bring together the version of the business case that matches the approved project plan, and the parts of the plan (such as time, cost, benefits) that make up an integrated plan.
The less integrated the documentation, the more important it is to trace the relationships between different parts. For example, a change to a plan should not be approved if it no longer fits within the constraints of the approved business case. In that case, the business case would also need to be revised and approved. Planning and control baselines include those related to the planning constraints, such as benefits, time and cost baselines.
For solution delivery, a baseline brings together the related and mutually compatible parts of a solution. Solution baselines are common in digital solutions but apply in all types of work.
Baselines are typically produced at critical points in the life cycle and build on each other as work progresses. Once a baseline has been set, any changes are subject to change control.
In a programme and project, a baseline with an appropriate horizon should be set as soon as work to initiate has been completed. It is then typically updated in readiness for and forms part of business cases. Where a change to the baseline plan or management documentation is approved, the change will likely have an effect on the business case which will need to be approved as part the change approval.
Different development methodologies have their own naming for baselines, but typical solution baselines relate to:
Baselines are also taken before formal verification and validation activities, especially leading up to and during integration. It is important to specify what each supplier (whether internal or external) is accountable for and recorded in an ‘allocated baseline’.
In many disciplines the first time a baseline is created it is preceded by a formal review of the solution to validate that solution. These reviews are primarily focused on the adequacy of the solution to meet the objectives and the adequacy of the associated management frameworks. The names of such reviews usually match the name of the baseline that is being reviewed (for example, a system requirement review looks at the requirements baseline).
For a large or complex solution such reviews can take many days of specialist work. The scope and timing of these reviews should be coordinated to inform the formal assurance reviews and decisions points (also known as gates), before starting a new phase of work (see Chapter 4: Governance and management).
In some cases, an approved part of a solution needs changing, for example to resolve an issue in another part to rectify a newly discovered defect. As soon as that part is changed, the previous approval is nullified, and that part of the solution would need to be verified again.
Similarly, when a new component is introduced it is often necessary to verify the existing parts of the solution again along with the new component in case it has introduced problems elsewhere. This can happen in both digital solutions (where it is called regression testing) and physical solutions. A physical example is where sightlines from the train driver to signals on a platform were approved but later obscured when passenger signage was hung. It can also happen in transformation work, for example, where a decision to delay one service change prevents rollout of other service changes dependent on it.
Preparation for traceability management should start as part of initiating the portfolio, programme or project. However, not everything needs to be traceable. Tools and information that support the implementation of the governance and management framework only needed to be dated, such as actions, minutes of meetings, risk, issue, change control registers.
The items that need to be traceable are the outputs, products and deliverables that need to be approved. This includes outputs, products and deliverables hat make up the plan, solution design and management documentation that describe the governance and management framework. Each output, product, deliverable that requires approval is often called a traceability or configuration item and should be uniquely identified with its version and status.
Choosing the right level of output, product or deliverable for traceability management helps make sure the workload is proportionate. It is often simpler to cluster related outputs, products or deliverables and manage them as a single item. Verification of the individual outputs, products and deliverables making up the item would still be carried out by those managing that work, but would not appear in the traceability records until the whole group is verified.
Traceability items for the solution can be structured in groups, in a product breakdown structure, as a hierarchical list of all the deliverables that make up a solution.
As each output, product or deliverable is verified, successful completion should represent a milestone on the schedule, thereby tying the plan to each deliverable.
Suppliers are responsible for ensuring traceability is managed for their allocated work or parts of the solution. The outputs, products and deliverables should also be traceable and verifiable items within the traceability management framework.
Once the scale and complexity of the work is known, appropriate tools and processes can be defined, together with the resources to use them. For simple solutions or when the work is outsourced or contracted out, the data can be handled through spreadsheets. For more complicated solutions, specialist tools are needed to manage the volume of data and relationships and make it available to those who need it when they need it. The processes and tools need to be able to work with the change control and information management processes and tools and are often dependent on the tool chosen.
Traceability comprises the activities summarised in Figure 23.4 and needed throughout the project delivery and solution’s life cycle. There are many variants of these activities, often designed for specific types or output or relating to proprietary digital traceability management systems.
The approach to managing traceability 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). The important aspects of this activity are discussed in more detail in 23.6.2.1 on choosing which deliverables need to be traceable. The management framework should be monitored to make sure it remains effective and appropriate as the work proceeds and address relevant feedback from its use.
The components of the plan, solution design and management documentation which need to be traced should be identified and the links defined. If models and interim solutions are needed, these should also be included.
Items are normally organised in a hierarchy based on either the solution hierarchy or the management documentation hierachy. Each item should have a unique identifier, with two-way traceability running both ways between higher and lower levels of the hierarchy and across the elements at the same level.
Baselines should be defined which represent a specific point in time and show achievement though the solution’s life cycle. These can be derived from the development, verification, validation, integration and transition strategies. Each baseline should include the traceability items that comprise it and the two-way relationships among them.
When formal changes to items are approved, the relevant version, status and relationships should be updated. This is managed through change control, see Chapter 22: Change control.
The status of each baseline and its constituent items, and its relationship to other items, should be available to those who need them to undertake their work. Regular reports can be run to give an overview of progress, for example showing the number of items in each status within the relevant baseline (see Chapter 18: Reporting).
Auditing verifies the actual traceability items against their expected status at any given moment and verifies that the processes being used conform to the management framework. If the data held becomes dated or is incorrect it can have serious consequences for the completion of the work and, in some cases, lead to contract disputes.
Once the solution has been fully disposed of, the information should be archived in accordance with the sponsoring organisation’s information retention policy (see Chapter 24: Information and data management) and the management framework closed.
Page permissions updated for public launch.
First published for closed beta consultation.