Change Driven Risk Management
What is CDRM?
Change Driven Risk Management (CDRM) is a technical framework to assess and manage risk over the project lifecycle. Utilising a spreadsheet-based tool, CDRM informs the relationship between change and risk mitigation methods as a customised Checklist.
It is part of the bank's testing compliance process and must be completed by the Project Management and Test Management communities within Technology Services during project Commence.
It is part of the bank's testing compliance process and must be completed by the Project Management and Test Management communities within Technology Services during project Commence.
When CDRM is combined with a programme- or application platform-level Test Strategy it removes the need for a project-level Test Strategy. Note that CDRM is mandatory, while a Test Strategy is not.
Why should projects use CDRM?
CDRM is a technique which projects can use to document a risk-based assessment of the planned changes for their project. In this way it will enable projects to target testing only where there is a significant business or technical risk based on change.
The technique also allows for continuous evaluation of executed tests, the results of which may modify the risk level of non-executed planned tests and effect their removal from the test plan. This will remove unnecessary testing, and help reduce project costs and deliver changes faster, while still controlling risk.
The technique also allows for continuous evaluation of executed tests, the results of which may modify the risk level of non-executed planned tests and effect their removal from the test plan. This will remove unnecessary testing, and help reduce project costs and deliver changes faster, while still controlling risk.
When do you need to start CDRM?
The Project Manager and the Test Manager are required to provide CDRM input and analyse CDRM output during the Commence stage in the project lifecycle. They must provide feedback, via the use of the CDRM comments fields, on the advice given within the CDRM checklist.
As the project progresses through Analysis, Design, Construction, Testing and Implementation the Project Manager must annotate the checklist via the status and date fields to indicate progress with regard to the scheduling and execution of mitigation methods, and revisit the answers to the input questions as more information becomes available.
As the project progresses through Analysis, Design, Construction, Testing and Implementation the Project Manager must annotate the checklist via the status and date fields to indicate progress with regard to the scheduling and execution of mitigation methods, and revisit the answers to the input questions as more information becomes available.
What inputs are needed?
A good understanding of the scope of the project being undertaken, much of which can be extracted from the Business Change Request, Terms of Reference and high-level Project Plan.
Subsequently, when the CDRM questions and checklist are revisited throughout the development lifecycle, additional input will be required in the form of key lifecycle deliverables such as the Requirements Specification, the Application Design and the Component Designs.
There is no requirement to input any explicit relationships between change, risk and mitigation as the CDRM spreadsheet is “rule based”, and contains a generic set of relationships between types of change, categories of risks and risk mitigation methods. Application-specific knowledge is required to detail any application-specific risks that overrule the generic rules mentioned above.
The CDRM spreadsheet must not be embedded or included in any other documents, it can only be linked to. This is required as the CDRM tool will be updated throughout the project lifecycle, and this will only be practical if it is kept as a separate document
Subsequently, when the CDRM questions and checklist are revisited throughout the development lifecycle, additional input will be required in the form of key lifecycle deliverables such as the Requirements Specification, the Application Design and the Component Designs.
There is no requirement to input any explicit relationships between change, risk and mitigation as the CDRM spreadsheet is “rule based”, and contains a generic set of relationships between types of change, categories of risks and risk mitigation methods. Application-specific knowledge is required to detail any application-specific risks that overrule the generic rules mentioned above.
The CDRM spreadsheet must not be embedded or included in any other documents, it can only be linked to. This is required as the CDRM tool will be updated throughout the project lifecycle, and this will only be practical if it is kept as a separate document
How to go about it?
As projects come in various sizes, some of which can be similar in size and complexity to a programme, it is important to note that CDRM is very effective on an application by application basis. If a programme or project is changing a number of applications then CDRM output must be produced for each application.
To date over seventy mitigation methods have been identified of which under half are testing; use reviews to mitigate risk; use CDRM to help you identify effective methods you may not be familiar with.
The Testing Types matrix indicates where each of the mitigation methods is placed in relation to the development lifecycle stages. Note that this diagram corresponds to the standard testing V-model.
To date over seventy mitigation methods have been identified of which under half are testing; use reviews to mitigate risk; use CDRM to help you identify effective methods you may not be familiar with.
The Testing Types matrix indicates where each of the mitigation methods is placed in relation to the development lifecycle stages. Note that this diagram corresponds to the standard testing V-model.
Types of Reviews and Tests
There are many different types of testing - not all of them applicable to any one project. Selecting which tests will be used for a project forms part of the strategy for testing on a project. In order to select the right types of tests to carry out it is necessary to apply the Change Driven Risk Management (CDRM) technique. CDRM uses the relationship between types of change and types of review and test to generate a customised checklist of methods to use throughout the lifecycle.
Post a Comment