To highlight the problem we’ll create an example project.
We budget
As the project progresses we discover that the design phase actually took 5 weeks. Typically what happens in this situation is that the build time gets reduced by a week to make up the time, so the business still get the project finished in the original 6 month estimate:
The better thing to do is to re-adjust the estimates based on the updated data (as the meteorologist does in our previous example). Our original estimate for the design phase of the project was off by 25%, luckily we figured this out at the 1st stage in the project.
If the original estimate for the design phase of the project was off by 25%, then we should assume that the rest of our estimations were also off by the same amount. It would be ideal to be able to simply adjust our estimates and tell the business that we we’re off by 25%, but most people don’t work in an organisation that allows shifting deadlines around in that way.
Statistically speaking, estimates are off by a factor of 4 (in both directions), so a project with a 1 year estimation could take as little as 3 months to complete, or as much as 4 years. This is because at the time of original estimation, the information appears to be fresh and current, and we have a high confidence level as to how we are going to handle the project.
We haven’t taken into account how the information will change over time (and in software development, it usually does). This is why it is critical that estimates are adjusted over time and as information/data becomes available. The most difficult part of this idea is communicating it to the wider organisation.
At the start of the project when you gave the original estimate, it would have been taken away as the hard and fast deadlineas to when the project will be delivered, it may have been communicated around the business and even made its way into a power point presentation somewhere along the line.
Any deviation from the ‘deadline’ could be seen as a negative, effecting how the digital/development teams appear to the rest of the organisation and possibly having an impact on staff morale.
The problem is that all of the details are rarely known at the start of a project, regardless of what methodology you use. You have to readjust estimations during the project life-cycle as new information and accurate data becomes available, and as more details emerge you’ll find that your estimations become more accurate (see ‘The cone of uncertainty‘).