A Risk is any potential threat to success.
Many risks will be within a projects or programmes or other delivery team’s sphere of influence and actions may be taken to remove or address these risks. Some risks will be beyond the immediate sphere of influence, these should be identified and escalated to Business Leaders via the Bubble Up process or some other escalation route.
Risks may be within the sphere of influence of the business and so mitigating action can be taken. However, some risks may not even be within the sphere influence of the business instead affected by external factors, it is still essential that these risks are identified and escalated as they may be important in influencing the strategic direction of the business.
Risk Impact is the effect of a risk actually occurring, becoming an issue. Impact is best quantified in terms of resource usage (time/money/people) and/or effect on Business Value (POFL). The risk impact and perceived probability help us asses which risks to focus our efforts on. During Portfolio Selection, and Continuous Investment Review, Risk Impact may be useful in helping to choose an option to take forward from Business Cases and inform start/stop decisions. Risk Impact will also inform Build or Buy decisions.
This uncertainty represents schedule risk since estimates will be so inaccurate initially, at Business Case and Portfolio Request level through to early Programme estimates and Project Estimates.
An Estimate is an approximate calculation or judgement of the value, number, quantity, or extent of something
- Confident: We understand the process, human and technical aspects. We have good numerical assessments based on past evidence. Although we can’t predict the future, we are confident in our estimates.
- Reasonable: We have some confidence in our analysis, but we can expect numbers to change as we learn more. We don’t expect our estimates to change significantly enough to affect start/stop decisions.
- Cautious: Although we don’t expect significant change, there is sufficient risk that our estimates could change significantly as we learn more about the work.
- Uncertain: We have little confidence in our estimates as there is high complexity, or significant unknowns. Our estimates may change significantly as we learn more.
Risk Driven Lifecycle
We recommend adopting a risk driven lifecycle, feeding back refined estimates and risk knowledge throughout the business. A risk driven lifecycle involves doing the risky things first, to understand those risks and inform continued work on the programme or project. Essentially reducing the cone of uncertainty as quickly as possible. The Standard Milestones in Holistic Software Development build in the Risk Driven Lifecycle to programmes and projects where they exist, but a risk-driven approach can be taken without using Milestones by simply attacking risky things first.
A Milestone is a significant event or decision point in the lifetime of a project.
Holistic Software Development uses a standard set of layered Milestones to drive the Risk-Driven Lifecycle. Milestones are a useful way of tracking top-level guesses about when scope will be delivered. Like estimates, they should not be treated as deadlines.
These risks may relate to requirements or technical uncertainty which are within the projects sphere of influence. Delivery teams can identify activity that can reduce or eliminate the top risks, this may involve building technical solutions to address specific technical challenges (prototyping or spiking). The result of early risk mitigation is increased understanding of overall scope, proven architecture (from spiking) and elaboration of poorly understood requirements all of which reduce uncertainty and improve estimates (where they are used).
Successful risk reduction may lead the business to commitment of more fund/resources to the project, conversely inability to reduce risk may be a signal that a different approach is required. This may even result in project cancellation or redirection, early cancellation of projects that aren’t addressing their risks successfully is a positive indicator for the organization. HSD uses Continuous Investment Review to drive this analysis.
Programmes or Projects whose risk profile is static are also candidates for investigation as there may be issues around the ways of working.
Risks can be mitigated in a number of ways:
- Avoidance – the risk is eliminated by not doing activities that might cause it to occur, or it goes away by itself (this is often impractical, though most desirable, in a business context)
- Reduction – the risk impact is reduced by resolving parts of the risk (e.g. by sharing knowledge, by finding expertise, by spiking a technical problem, by demonstrating progress etc.)
- Sharing – sharing is often misrepresented as “transfer” however a business can never entirely transfer a risk (e.g. by outsourcing) as the impact of the risk occurring will still affect the business as a customer to the transferred entity. However, some types of risk impact, such as financial and reputational, can be shared.
- Retention – involves budgeting and planning for a risk to happen, to the extent of assuming it will happen.