We often hear the term schedule risk, however, it is generally a Red Herring. Stating that the schedule might stretch is about as useful as saying that eating can cause you to gain weight.
You may be correct but it gives you no leverage to solve the problem
Schedules slip as a result of a problem, if you want to solve the problem then you must identify the root cause. Any problem will result in a task taking longer than expected and potentially affecting the schedule.
Risk and uncertainty are two sides of the same coin. Without uncertainty there is no risk.
No Uncertainty = No Risk
A risk is a contingent liability; a risk is a future event that is uncertain that has consequences.
The key words are future and uncertain.
If 6 months remain and the deadline is in 2 months then there is no schedule risk because there is no uncertainty.
6 months late means that the earliest that the critical path items can finish is in 6 months. Just because the project has not hit the deadline and senior staff doesn’t understand the project is late does not qualify the team to talk as if the outcome is uncertain.
It is disingenuous and cowardly to suggest to senior staff that a deadline is possible when you know that it is not.
When the team knows that they are late, they often talk about tasks as being risky simply because they hope that miracles can happen1.
Hope is not a strategy
In fact, Kahneman points out all of us are wired to bet (pray?) on unlikely outcomes when faced with certain losses, i.e. we double down when faced with a loss. Team members know about the negative consequences of failure and make projects seem possible simply because they want to delay the pain. Even worse, as the situation gets more desperate people will take bigger and bigger risks.
Using the term schedule risk when a project is not feasible essentially robs the managers of making a course correction until the point where very little can be done.
At a minimum, money can be saved by winding the project down. Few people have the intestinal fortitude to speak out when they know that a project is late. Unfortunately, cowardice is very common.
If you take a paycheck then you have an obligation to your organization to tell them when a project is late.
So it makes no sense to talk about schedule risk when:
- The project is late and you know it
- The project is not late but you see schedule items slipping
In the latter case you are much better to talk about why things are slipping rather than using the term schedule risk. By talking about the root cause of the slippage, especially early in a project, can lead to you either solving the problem or adjusting the project deadline. Either way, you will have a greater chance of ending up with a feasible project.
- Jones, Capers. SCORING AND EVALUATING SOFTWARE METHODS, PRACTICES, AND RESULTS. 2008.
- Jones, Capers. The Economics of Software Quality. 2011
- Kahneman, Daniel. Thinking, Fast and Slow. 2011
You must log in to post a comment.