The MO’s established risks, in addition to your network of stakeholders, are highly familiar to CSTAR, allowing us to deliver a substantially reduced level of overall risk. We fully understand the implications of SW being a 24/7 operational service, with implications on the MO’s responsibility to support UK government and Critical National Infrastructure providers. Our approach to risk therefore focuses on availability and integrity of all products, so that while enhancing the system we are also maintaining its operational resilience.
We take a proactive approach to risk and dependency management. For risks, this means continuously questioning what could go wrong, and actively tracking mitigating actions. For dependencies, this means working with stakeholders to ensure dependencies are met, leaning in to help them and where possible not allowing contractual boundaries to prevent us doing the right thing for the project.
Risk Management
CSTAR offers controlled delivery through robust governance to manage risk. We have a tried and tested approach to identifying risks and managing them in a way so that they are eliminated completely or brought within acceptable levels of tolerance. Where risks are rising outside of agreed levels or they are new, we will bring them to the attention of the customer and agree the most appropriate way to manage them.
At contract kick-off, our Delivery Lead will produce a Risk Management Plan to manage risk across all aspects of delivery. It will cover:
- A proposed structure of the risk register
- A proposed risk management process
- Roles and responsibilities for managing risk
- Communication and reporting lines
- The review and reporting cycle for risks
- Escalation procedures.
Using the plan, we will identify those factors that could adversely impact the project, for example, by delaying delivery or reducing the quality of the solution. CSTAR will maintain a Risks, Actions, Issues and Decision Log (RAID) for the duration of the project.
Our approach to risk management will be undertaken as an iterative process around three key areas:
Risk Identification
CSTAR propose a joint risk identification and evaluation exercise involving representation from the MO and CSTAR to ensure a holistic view of identifiable risks. Risk management is not a one-off activity. Every member of our team will be encouraged to identify risks and will be made aware of the communication lines and procedures for reporting risks throughout the contract.
Identified risks will be reported to the CSTAR Delivery Lead who will record them in the RAID log. For each risk this will record:
- A detailed description of the risk
- The perceived trigger event.
The Delivery Lead will ensure that all risks are reviewed at regular junctures and are reported at the monthly reviews.
Risk Analysis
For each identified risk, CSTAR will undertake a detailed analysis to determine:
- The probability of occurrence
- The impact of the risk should it occur.
CSTAR recognise that there are two distinct ways of expressing probability and impact
- Qualitative
- Quantitative (financial and time related).
CSTAR will apply qualitative methods to all risks as a rapid way of prioritising risks and assessing the level of impact prior to any quantitative assessment. Qualitative methods will also be used in cases where costs and/or revenue are not critical. Quantitative assessment will allow for effective commercial management of the project and will be applied where required.
CSTAR will apply one of the impact ratings in each risk.
- Low: Minimal impact
- Medium: Affects timescales, costs or performance milestones
- High: Significant timescales, cost or performance difficulties
- Critical: Little or no contingency action to redress impact.
Risk Response
CSTAR, in conjunction with the MO will be responsible for identifying appropriate risk response strategies. Typically, we will select one or more of the following risk management strategies:
- Transference – pass the impact of the risk to a third-party via, for example, an insurance policy
- Prevention – implement countermeasures to prevent the threat of risk occurring or prevent it having an impact on the project;
- Mitigation – take action to reduce the impact and/or probability of it happening, for example:
- Modifying plans to break dependencies or introduce contingency
- Introducing additional activities, such as a time-boxed spike to reduce the risk of a technical requirement
- Acceptance – decide to go ahead and accept the possibility that the risk will occur (believing that the risk will not occur, or where the countermeasure is too expensive)
- Contingency – plan and organise actions to come into force as and when the risk occurs.
Risk owners will be identified for individual risks. They will be selected on the basis of their ability to best manage the mitigating actions through to successful closure of the risk. As part of this contract, CSTAR will offer the MO free set up and use of the MooD Risk Manager tool, continuing for the duration of our delivery of the SW project.
Dependency Management
A Dependency Log will be maintained by the Delivery Lead, initially populated at bid stage and updated at project kick-off. Dates will be identified and communicated to relevant parties, along with the associated impact if the dependency is not met, ensuring all parties have a clear understanding of what is needed. As the project progresses, further dependencies may be identified and these will be immediately relayed to the relevant party. CSTAR will actively manage dependencies, supporting the MO to meet them, following our principle of working as ‘One Team’.
Dependencies will be reviewed at the monthly reviews. If we believe a dependency is at risk of impacting delivery, we will escalate this to the MO immediately so we can agree on a resolution plan.
In the event that dependencies cannot be met, following the Agile principle of ‘Customer collaboration over contract negotiation’, we will work with the MO to find alternative routes forward. An example of this, from our previous experience, would be in the event that the MO was unable to provide a Product Owner with sufficient time available to fulfil all duties of that role. In this case we would look to offer a CSTAR person to fill the role of proxy Product Owner, working closely with the MO to reduce the burden on their own Product Owner.
Grace Thiele 