“If you do not actively attack risks, they will actively attack you”
– Tom Gilb
What I usually see in the risk tables of project or service plans are “deliver late”, “surpass the budget”, or “does not pass customer acceptance due to unclear requirements”.
At the same time, teams most often complain from not being able to meet deadlines, and surpassing budget.
Obviously we are rather attacked than attacking risks.
Why analyse defect data?
What can we do to protect better the projects and the services from the risks?
Logically, understanding better the causes and the circumstances for the problems should help.
Have you checked what part of the total delivery time (lead time) is effective development, rework due to defects, or waiting for some input? In other words do you know the efficiency of your process?
When estimating the delivery time, did you include the time for rework and waiting?
My experience shows that few companies systematically analyse their defects and blockers with the aim to understand their root causes and act on them. Blockers are sort of defects in some of the processes involved in carrying out the work, e.g. managing suppliers, scheduling, handling customer information, etc.
Several times I have seen surprise on the faces when people realize that resolving blockers and fixing defects takes them more than 30% of the total estimated effort, prolongs project duration with more than 20%, and affects significantly customer satisfaction.
If you want that your work be fit for purpose, you should listen to your defect data (including blockers) and act adequately.
How to analyse defect data?
Analyse defect data is not so difficult – there are several techniques that help with this. The main reason for not taking advantage from this valuable source of information is that the majority of the companies still do not collect data about defects and/or do not know what this data say.
A simple practice that you can use to learn from your defect data is to follow these steps:
- Classify the defects based on criteria that emerge from telling the story of each defect. For instance, we started working without getting commitment from the customer about the functionality, dependencies with another system were not taken into account, the person involved was new and with insufficient domain knowledge, etc.
- Analyse the causes and look for patterns. Although each story has its individual aspects, problems share great part of the roots.
Focus on the lead time and efficiency of resolving the defect or blocker - Decide how to address the causes as to prevent them from occurring.
What do defects have to do with risks?
Most of the problems are recurring at least until we manage to preclude them completely.
This means that we have to be prepared to see our experience again in the future. The point here is how we can identify the risk well in advance and effectively avoid it.
Mirroring the past through the “now” point is a simple and helpful technique.
The problem from the past becomes a risk in the future. The causes from the past convert to risk symptoms that we have to carefully watch for.
Which is the right place to discuss risks?
Lots of teams try to mitigate their risks individually and independently on the others. This is not very effective especially when there are dependencies between the services.
I assume you conduct some periodic meetings at which you review your projects and services. If you use the Kanban routines (cadences), the ideal place is the Risk Review meeting.
Image copied with permission from David J Anderson’s post “Kanban cadences”.
Make sure that you have a good understanding of the entire context to be able to make pragmatic decisions about how to hedge risks.
Summary
- At team level not understanding the causes for the defects and blockers makes you vulnerable to project and service risks
- At organization level not addressing properly the risks reduces your fitness for your business purpose.
- Applying a pragmatic approach to defect analysis, understood and shared by all stakeholders, facilitates risk hedging.
