The Estimation Trap: Why Your Project Timelines Are Always Off
See how small changes in your estimation process can lead to big improvements in project performance.
The most important activity for any project, which will help everyone from individual resource to organization, is consistently off the mark. Understand why that happens and how to do it practically.
Why Estimate?
Estimation is required to do anything, it is the basis of gathering all the required resources. The task estimations will help you to plan the project.
Good or bad, a plan is a must.
And so are the estimations - accurate, inaccurate or guesstimate.
In one case where you plan without estimate, it uses something called guesstimate. It means guess the estimate.
Contributing Factors
Estimation dictionary meaning is ‘opinion or judgement’. The nature of the activity is your opinion. Getting estimation right is always tricky and challenging due to so many variables.
E.g. We consider a resource with the same exp to have the same productivity, but these are two different persons - the productivity will be always different. How will be estimation absorb that variation.
Estimation has to have a base, even in the case of guesstimate.
The base for estimating needs to be built upon. Each step of your development has potential to derail the estimations. Be it the developers, availability of tools/stuff to customer input delays. Let’s take one example to understand estimation gone wrong.
Thing that contribute to the estimation are;
Experienced estimator
Previous execution timeline (the actual delayed)
Usage of resources
Dependencies
Feedback delays
Reuse
Experienced estimator
If you have experience as project manager in the same organization and on a similar type of project. Then the estimations are likely to be more accurate since you know the pain that happened when you executed the project which estimated less than required efforts.
Similarly, for architects, leads, developers - the previous experience counts
Previous execution timeline (the actual delayed)
An easier approach when we lack a team of experience resources. Take a sample of previously executed projects. It is very critical to look at lessons learned (good & bad) section and change request.
Lessons learn show where the time could be saved for future projects.
CR Change request - Whenever CR are accepted, they kind of reset the project timeline. While sampling, you could look at the initial plan and the final plan, and you might wonder the project took twice the time, CR might have contributed to that.
So using CR data you can normalize the inflated timeline and then process the data for your estimation.
Usage of resources
This is a bit complex due to the nature of resources involved. I will list a few here, this is very specific to your project.
Skilled team
availability of target/hardware
Availability of test platform
customer acceptance testing
3rd party software/libraries
Based on the availability of the resource, you would be able to complete the task. Hence, the estimation for the task will vary accordingly.
Feedbacks
If you have milestone release, the feedback shall be received by a particular time to incorporate the changes. The more delay in feedback, the more last minute efforts required to squeeze the change. The customer shall be notified about feedback window, or it would be considered as Change Request.
Reuse
Almost all organization love to reuse to save cost. This is always done at the quote phase of any project. And yet it remains the single most reason for wrong estimations.
Reuse is the most critical factor that skews the estimations in reality.
One of my project was supposed to be based upon an earlier released product. Our project was a cluster from automotive domain. The target was to change the processor to the latest version and no change in application software. Technically, update the BSP (base support package - driver layer in embedded SW) and we are done.
Just for fun, submit this below poll based on your experience.
The application did not change as decided. Make a wild guess what could have happened.
The requirements team had to start from a clean slate (no reuse of requirements) and in order to define requirement the team did reverse engineering to the application based on the behavior. Suddenly, the same application did not remain the same at all.
You might say the application behavior was the same, how could this have an impact on requirements. It was the same largely, but the nitty-gritty turned the SW world upside down. Now we had to now update the ‘reuse’ SW to match the new requirements.
E.g. A requirement - press a button for 10 seconds and then take action. Existing reused SW was taking action after 10 and button released. New requirement - take action after 10 seconds, ignore button release.
This appears minor, but to incorporate the change we had to add a new software path (increase MC/DC) and add guards for the next action mapped to the button. There were similar changes carried in hardware as well, eventually spread like wildfire.
Disaster by all means, you might be wondering what happened to the estimations. Estimations went from 6 person months to 60+ person months.
There was a good amount of debate around it. The strategy to reverse engineer was always there, but the impact could not be foreseen and whoever did estimation could not have any clue the amount of havoc that will be followed. This resulted in project cost significantly overrun, project in red from day 1 and SW team escalations.
Were the software developers at fault?
If you consider ‘Reuse’, ensure it’s from system level. If you reuse requirement only, then you could successfully save efforts/costs. Else, it’s just to reduce the cost at quote level.
Best way to estimate
Let’s explore what could be done, so we are able to estimate more realistically. I am considering the most common scenarios below. Note that the list is not comprehensive, it is only meant as food for thought.
With Base - Similar programs are executed
Base with changes
Processor
hardware section
libraries
…
Without Base - Complete new development
With Base
In this case, we have a timeline of previously executed project with similar requirements.
While considering base, ensure that whether it was a new product development (NPD) or reuse or anything in-between. As a starting reference, the maximum time would be the same as that of the base program.
Next step, check each sub topic and review the estimations.
E.g. The base program is NPD, one section is to calculate the software effort to create a library A. If this library is to be reused with little changes then you could consider the 10% efforts on integration. If this library is to be used with 25% changes, then the efforts will be directly linked to whether you got the same developer or not.
Extend this logic to all subsection on what is being changed.
Without Base
No basis for any evaluation, what could be the estimate.
In this case, consider the no of modules you plan to develop. List the modules, go through each of them, evaluate is it complete new development or could be reused from partially. This will be a long process, but the figure will be more realistic. If not realistic figure, it will help you to identify the weakness for development of a particular module(s). This will help to plan much better and assign the right resources from day one.
Summary
Estimation is hard, try to evaluate at deeper level. Remember, ‘Devil is in the details’. Do peer reviews with other teams. Strictly go through lesson learned and filed issues. While running a project, try to review the original plan and the current plan in order to mark what went off track and what caused it. This you could add to Wrong lesson learned section or good if went the other way.