Steve Rivkin, October 2012
This article describes how the close integration of risk management and requirements management can be used to advantage to link risks accurately via requirements to specific elements of design, thereby providing the capability to reduce the overall cost of designs.
On many large projects it is common practice for the client’s project team, prior to going out to tender, to produce an Initial Reference Design to help investigate any key risk areas that may have been identified. In particular, where construction is involved, it may be necessary to gain Approval in Principle for certain aspects of proposed construction. The Initial Reference Design serves a number of purposes:
- It establishes the feasibility of certain aspects of the design
- It assists in gaining a more accurate estimate of the overall cost of the project prior to going out to tender with the main contracts
- It helps to mitigate or de-risk those areas of high risk relating to the design which might deter prospective bidders.
Although, for the reasons given above, it is necessary to put effort into an initial design, such work can be costly. This is often exacerbated by the difficulty of scoping the areas necessary for design effort accurately, so that additional, unnecessary elements of design are created. To make matters worse, once the design has been used for the purposes described above, it is usually discarded because the project’s legal team would normally advise that main works contracts must be let against formal requirements, as opposed to requesting that contractors use the client’s design . It follows that a requirements process is necessary to enable the creation of a clear set of formal requirements with which to go out to tender. Such a process is described briefly in the next section.
Linking Requirements to the Design
In a previous article by the author  a rigorous ‘Requirements-driven Design’ approach was described which enabled each requirement at a given level of design to be linked directly to its corresponding design element. In this approach a requirements hierarchy is created (see Figure 1 below) where the requirements at each stage of the project, or level of the requirements hierarchy, are linked to their predecessors to show traceability, and where additional information related to the relationship between requirements at each level is stored [*]. The requirements are linked vertically in a hierarchy, whereby a requirement at a particular level is linked to several more detailed requirements at the next level down via a Satisfaction Argument (SA). The SA is used to contain text that describes how lower level requirements have been derived from higher level requirement, but at a level of detail appropriate to the next stage of the lifecycle.
Two more constructs are used: Compliance Arguments (CA) and Design Verification Arguments (DVA). The CA is used to link domain knowledge, standards, or legislation to a requirement that has been created to take account of this information. The argument is a field that contains an explanation of why the requirement is necessary. The DVA is used to link an element of the design to a specific requirement, and contains an explanation of how the referenced element implements the requirement. An additional field of the DVA, the Verification Evidence attribute, contains a reference(s) to a document(s) or drawing(s) that are part of the design documentation, and this reference indicates the section(s) or clause(s) that implement the specific requirement in the design. In this way, verification evidence is provided, showing where the requirement has been implemented in the design. If required, the structure can also allow for the addition of a ‘Value Engineering’ field, to contain the reasoning which explains the value (e.g. cost reduction, added benefits, etc.) of the approach taken for that aspect of the design. Requirements are derived for successive stages of the project lifecycle, and at appropriate points designs can be produced which meet the requirements at that level. The approach provides complete, auditable traceability from the Stakeholders’ Requirements, down through more detailed levels of requirements that correspond to the more detailed levels of design, and throughout the whole of the development lifecycle.
In addition to the management of requirements and design, an essential pre-requisite for managing a project is to put into place an effective Risk Management strategy so that any identified risks can be assessed and controlled, thereby enabling the project to continue towards meeting its objectives and producing its agreed deliverables. The next section describes a common approach to risk management. The subsequent section will describe how the close integration of risk management & requirements management can be used to advantage to link risks accurately to specific elements of design, thereby providing the capability for the project to reduce the overall cost of the design effort.
The Key elements in the implementation of any risk management strategy will be the Risk Management process and the Risk Register. The purpose of the Risk Register is to capture and maintain information on all of the identified threats and opportunities relating to the project . Each risk on the Risk Register is allocated a unique identifier (Risk ID) as well as details such as:
- Who raised the risk
- The category of risk
- The description of the risk (cause, risk event, effect)
- Probability, impact and expected value
- Risk owner
A Risk Register (Figure 2 below) would typically contain some of the following fields:
The severity/magnitude of a risk (or opportunity) is usually determined by its Risk Score, where the Risk Score is obtained by multiplying Probability by Impact (where 0 < Probability < 1, and 0 < Impact < 1). Whilst methods of risk management exist which use numerical values of Risk Score in the management of risk, a more common approach is to divide Probability and Impact into bands that signify levels from Very Low to Very High. An example of a range of probability bands could be as shown in Figure 3a below.
Similarly, the values of Impact could be divided into bands that signify Impact levels from Very Low to Very High, as shown in the example in Figure 3b.
A matrix can be constructed where the cells of the matrix reflect ranges of Risk Score, so that the highest Risk Score in the above example would be:
Probability(Very High) x Impact(very High)
Similarly, the lowest Risk Score would be:
Probability(Very Low) x Impact(very Low)
The importance of the Risk Score is that it captures the various combinations of Probability and Impact, such that a combination of Probability(Very High) and Impact(Very High) would constitute a very high Risk Score. The Risk Score of the previous example can be captured as the logical AND (represented by Λ) of the values of Probability = ‘VERY HIGH’ and Impact = ‘VERY HIGH’ (i.e. VHΛVH). A matrix of the various possible values of Risk Score is shown in Figure 4 below.
In the matrix, those risks that have a Risk Score corresponding to VHΛVH will be the highest level risks. A view could be taken that risks that have scores of HΛH, or VHΛH, could also be considered sufficiently high to fall into the key risks category (shown in red in the matrix). Moderate and lower Risk Scores are indicated by the yellow and green areas in the matrix. Individual risks can be given a Red/Amber/Green (RAG) status within the Risk Register, corresponding to their Risk Score according to the matrix. Whilst this approach is appropriate for most risk scoring, it is possible to have a situation where a risk has a Very Low Probability and a Very High Impact (VLΛVH), which would result in an Amber risk level. If this risk were to materialise, and there were no advanced warning signs that the risk was about to occur, the consequences could be severe (due to the Very High Impact). This illustrates that the Risk Management process needs to be more sophisticated than just taking the Risk Score as the main indicator of how to manage risks. A more detailed consideration of risk management is outside the scope of this paper, but within the context of the remainder of this article it is sufficient to say that a Risk Score can (in most circumstances) be used to identify the key risks for a project.
The management of project risks is conducted according to a Risk Management process, an example of which is shown graphically (at a high level) in Figure 5 below. All key areas of management of the project (e.g. Issue Management, Change Management, Requirements Management, Technical Assurance, etc.) should have well-defined processes. Whilst these processes must focus on their specific areas of management, it is important that they interact, and interface with, other management processes so that the overall management of the project is well-integrated.
Integrating Requirements and Risks
In the Risk Management Process diagram (Figure 5 above) one of the activities related to entering a new risk into the Risk Register is ‘Identify Requirements, Assumptions and Constraints’. This activity is present because this Risk Management process is closely integrated with the Requirements Management process. Whenever a new risk is entered into the Risk Register the Requirements Manager will check whether any of the existing requirements are impacted by the risk. If so, the ‘Risk ID’ attributes of the requirement(s) are updated and linked to the new risk’s Risk ID in the Risk Register.
A risk can also be identified when a new requirement is created. Sometimes, when a requirement is specified initially, there may be some aspects of the requirement which may not be known completely. For example, there may be an outstanding Request For Information (RFI [**]) which needs to be resolved before some specific details of the requirement can be quantified, or the results of functional, or performance modelling, may need to be obtained, resulting in qualification of the requirement. In other cases, a risk, or issue, may be identified in relation to a requirement. When requirements are specified in these circumstances, an assumption needs to be made that whilst the requirement has been documented in its current form, it may be subject to change when the outcome of the related, outstanding information is known. An Assumptions Management process for requirements must be established (see Figure 6 below), such that an assumption can be created when a requirement is specified, which states the nature of the dependency on the related information. The Assumptions Management process monitors the processes related to the assumptions (i.e. Risk Management, Issue Management, RFI), such that when the outcome of an assumption is resolved
(e.g. a risk has been resolved/mitigated, an issue has been resolved, or the information for an RFI has been received), the requirement can be stated in its final form.
In addition to the traceability provided by managing the requirements using the structures shown in Figure 1, a secondary level of traceability is created by integrating the Requirements Management process with other project processes. The Requirements Manager needs to work with the managers of other key processes to understand and document within the requirements database the relationship of the Requirements Management process to other processes. In DOORS®, the links to the other processes can be achieved by defining appropriate attributes (i.e. fields) within the requirements modules, such as ‘Risk ID’, ‘Issue ID’, and ‘RFI ID’. Additional attributes can be defined to manage the assumptions related to a requirement, such as: ‘Assumption’ (containing the text of the Assumption); ‘Predicated On’ (the outstanding information needed to resolve the assumption); and ‘Assumption Status’ (with values ‘Outstanding’, or ‘Resolved’). Similarly, the status of the requirement can be indicated by a status attribute ‘Compliance Level’, with values such as: ‘Not Completed’, ‘Assumption Raised’, ‘Non-compliant’, ‘Completed’. Consider the case of a requirement that has an assumption raised which is related to a risk. The text of the assumption would be entered into Assumption; Assumption Status would be set to Outstanding; the Compliance Level attribute would be set to Assumption Raised; if the risk had not already been identified the risk would be entered into the Risk register of the Risk process, and the next Risk ID in sequence in the Risk Register would be associated with the risk, and this would also be entered into Risk ID in the requirements module. When the risk was resolved, the text of the requirement would be updated if necessary, to reflect the outcome of the risk resolution, Assumption Status would be set to Resolved, and Compliance Level would be set to Completed.
On large projects, when the legal team for the Project becomes involved during the procurement stage, they invariably advise that the individual contracts for the Implementation phase must only be awarded against well specified sets of requirements, rather than against any preliminary designs (such as a Reference Design to gain Approval in Principle) that may have been produced by the Project Team. The reason for this is that, if the contract was based on the Reference Design, and this design caused subsequent problems, the contractors could claim that they were not liable because the contract obliged them to base their design on the Reference Design, which proved to be flawed. Awarding the contracts against appropriate subsets of the System Requirements places the risk on the contractors, because they have to meet the requirements specified in the contract, and where a Reference Design is provided, it is provided for information only, and the contractor carries the risk if they use any part of the Reference Design. As a consequence of this, as far as the Client is concerned the initial Reference Design has a clear, but limited, set of objectives as described above. Clearly, any way of reducing the scope, and therefore, the cost of the initial design will be desirable.
One of the main difficulties when producing the initial design is knowing how to scope the design such that it will provide the required information with a minimum of effort. Using a Requirements-driven approach which tightly links individual requirements to their corresponding design elements, and where the Requirements Management process is well integrated with the other project processes, can provide a means to produce an accurate scope for the initial design, greatly reducing the design costs.
Relating Risks to Design
In Figure 7 below a portion of the Risk Register is shown for one risk, with the risk the Risk ID and RAG Status fields identified. The risk score will be set according to the levels agreed for the Project. For example, high risks may be categorised as having Risk Scores of HΛH, VHΛH or VHΛVH and the RAG Status will be set to reflect this high score. In the representation of the set of all project risks shown in the circle in the diagram, it may be the case that for the purposes of an initial design only those elements of the design which are associated with risks that have a Red RAG Status will be documented. Under normal circumstances it would be difficult to identify the precise scope/extent of the areas of design to be completed because the detailed linkage would not exist between the Risks, the Requirements, and the corresponding Design elements. Using a Requirements-driven Design approach which has integrated the project processes well – in particular the Requirements Management and Risk Management processes, the requirements associated with individual risks can be identified. In turn, because each element of the design is linked directly its corresponding requirement, the scope of the initial design can be determined precisely so that only those aspects of the design specifically associated with the Red risks need to be documented. As a consequence of this the cost of producing the initial design can be kept to a minimum. Clearly, this approach can be extended to investigate design elements associated with specific risks with high risk scores at any stage of the lifecycle when designs are being produced.
Using a well-defined, rigorous Requirements Management process can, in itself, provide significant benefits , such as:
- The design evolves thoroughly from the stakeholder requirements down through successive levels of derived requirements
- The design brief will be clear, so that the design will require no iteration
- There will be a full, auditable traceability through the requirements hierarchy and to every element of each level of design
- Project-wide visibility, and use of natural language, promotes better understanding for both the project team and the stakeholders
The approach described in this article shows that added value can be achieved by closely integrating the key project processes.
In particular, close integration of the Risk Management and Requirements Management processes adds additional benefits by using the fact that the risks can be linked directly to specific requirements which can, in turn, be linked to their associated design elements. This allows design effort to be focused very precisely to address the key risks identified in the project, so that a fuller understanding of, and subsequent mitigation/elimination of the various risks, can be achieved with a minimum of design effort and consequent cost reduction.
1 Rivkin, S, (April 2010) Managing Complexity in Large Development Programmes (Part 2), Project Manager Today
2 IBM Rational® DOORS®®, IBM Corporation Software Group, Route 100 Somers, NY 10589 U.S.A)
3 (2009) Managing Successful Projects with PRINCE2 Section 8 Risk, Office of Government Commerce
[*] The structures shown in Figure 1 were implemented using the DOORS (Dynamic Object Oriented Requirements System) database, which is a specialist requirements database , but this does not preclude the use of a different database or implementation mechanism.
[**] Note: RFI in this context is a request for additional information to qualify a requirement, and should not be confused with the term RFI which is often used by bidders when requesting information in relation to an Invitation to tender.
About the author
BTech MSc PhD CEng MBCS CITP FAPM
Steve is a Programme Manager at Acando UK, specialising in systems integration, requirements management, and project/programme management. He has managed a number of high profile software development projects in various sectors. He has also defined and implemented Requirements Management strategies in the rail industry using the DOORS® Requirements Database. Steve is a Committee Member of the North West Branch of the Association for Project Management (APM). He has co-authored the Requirements Management section for the APM’s Body of Knowledge 6th Edition, and given workshops and presentations in the nuclear sector describing a Requirements-driven Design approach to system development.
Steve can be contacted at:
firstname.lastname@example.org, Tel: +44 (0) 1928 796 800, Mob: +44 (0) 7808 768800
Acando UK website: www.acando.co.uk