Missing deadlines and/or poor estimates

• Semantics: “It took a longer time” VS “We didn't see that coming.”

• The engineer's assessment of the schedule quality.

• Does the deadline include a probability?

Of course, there are many causes of a missed deadline, and all the classic concerns apply. Here, however, we go beyond these concerns, and then it is important to distinguish between two immediate structures leading to scheduling slips.

If there is a useful Work Breakdown Structure, with all relevant tasks defined, then a missed deadline is due to poor task estimation. This is the assumption in classic project management.

The solution is to work on better estimation techniques, and then you are looking for the use of three-point estimation, multiple expert consensus, and historical data. 

However, in complex projects, this is not the case. These techniques do not apply to tasks that you are not aware of!

You may try to chunk the tasks up to a higher level where the task has a longer duration(weeks or months) and include a mix of simple and complex tasks. This is a reasonable technique, as long as you accept the total variation and include plenty of slack in the plan to level out the variance. What happens, however, introduces a significant business case risk, that you must be aware of. Due to optimism bias, the schedule is now based on an overly optimistic version of those high-level estimates that now include unknown complex tasks. This increases the total business-case risk significantly, and you are the one to mitigate this.

A powerful technique introduced by Bent Flyvbjerg is Reference Cost Forecasting (RFC) from his great book “How big things get done”.  The value of this increases with the complexity of projects, and is applicable to higher levels of tasks. The idea is to find historical data for similar tasks. These “outside in” data will somehow include the uncertainty introduced by unknown tasks, at least in the given context. Normal “inside out” estimates will never. The challenge is finding relevant cases, but it is worse trying. The process itself creates a valuable perspective on the estimation accuracy. 

When facing a delay there are two strategies:

1. Accept the delay

2. Avoid the delay

In the critical moment of deciding which strategy to apply, the political pressure is most likely so high that it makes “accepting” looks like “not an option”. I acknowledge that. However, at the end of the project, the political reality has vanished, and the engineering reality has prevailed. The project became delayed, and in this process, the “political reality” was nudged to accept. The brave alternative is to accept the leadership responsibility, accept the delay, and address the root cause with appropriate actions.

The steering group and project management must be able to explain the reason for the delay and take appropriate action.  The action must improve two structures:

1. Better estimates for a realistic schedule

2. Rescheduling, including appropriate slack

Avoiding the delay is highly likely to fail. It will at best demonstrate some action, but it backfires.

Do use the principle of Reference Cost Forecasting to get an outside-in view on estimates.

Do not add resources! Accept the inevitable delay. It will come anyway, and it is cheaper with the existing team.

Do not set up incentives for working harder. Laziness is not an issue, and insinuating is merely an insult.

Remove all incentives that support underestimation.

A detailed analysis of the distribution of delays due to poor estimation of known tasks, and new tasks.

A plan for improved estimates

A RCF based estimate

A realistic schedule, including the probability of meeting it.