As discussed in the previous post, there are two factors which have a strong influence on the success of a customer project, they are:
- Defining meaningful business outcomes, and associated qualitative and quantitative metrics for measuring success.
- Understanding and jointly managing the risk inherent in the project.
This blog post focuses on the 2nd of these.
We encourage the discussion of project risk right from the first conversation with customers, through to the ultimate delivery of the project and often the start of an ongoing support and ops agreement. To aid the discussion we use something called the Cone of Uncertainty, which provides a lens which everyone can agree on through which we can determine the current level of risk perceived on a project.
The Cone of Uncertainty is a well-known feature within project management. It refers to the project risk at project conception, when relatively little is known, versus on delivery when risks have been mitigated, or issues resulting from risks have been addressed. We can reduce our risk on a project by doing work to reduce the risk (or variability) within the project.
At the outset, this work may focus on outcomes and stakeholders, and move towards defining the user stories, and within time specific items of work to code and test pieces of functionality. The place on the Cone of Uncertainty determines the potential error in estimation for a project.
Consider building a house, if I ask you to for a quote to build my house - how much would you charge? The uncertainty is huge, perhaps this is a bungalow on a small plot of land, or perhaps it’s a mansion on a country estate. As work is refined, we may be discussing real stone floor vs. lino. The more we can determine the lower the risk.
To help us assess risk, we collectively ask five questions, and based on the answers get a score for our position on the Cone of Uncertainty. The questions cover:
- What is the current stage of the project?
- How well-defined are the project requirements?
- How confident is the team about the project timeline?
- What is the level of stakeholder alignment and understanding of the project scope?
- Does the team have experience with this type of implementation, hardware, and services?
Assessing risk is part of the picture, the flip side is managing risk, and engaging our customers in discussions around the risks within a project. For all projects we maintain a Risks and Issues Epic, which allows us to share and manage risks on the project, this will be reviewed at regular points during the project. We also hold pre-mortems before the start of each project, this looks to:
- Consider you are in the future and the project has failed, how might this have happened?
- Based on these failures, what mitigations could be taken now to reduce the risk of this occurring?
Typically various internal stakeholders take part on the pre-mortem, issues are identified, grouped, and voted on for biggest area of concern, and then tickets are written to create work now which seeks to reduce the risk of this problem occurring.
At the end of project we also carry out a post-mortem, which looks to review what lessons we can learn from this project to either improve our process, approach, recommend technologies etc. in order that future projects benefit.
I hope this has given you an insight into how we manage risk for the benefit of our customers. In the next post we will talk about How we typically develop.