top of page

Reflection on “Estimates are Just That by Jackson, April 2012”

The article “Estimates are Just That” discussed the estimation process in project management, taking into consideration the rapidly changing business environment and its impact of the estimation process, knowing that any change in the business environment can not only generate increased risk for the schedule and cost, but also can change the interests of the sponsors, making the environment fluctuate even more. However, understanding the cost structure and getting more clarification on costs, can give project managers a better opportunity for good decision-making.

The article discussed some of the most famous estimation methodologies; The analogous technique (it is also called top-down estimating), which can be used when deliverables are similar in nature, knowing that it should be avoided if the projects require more precise estimates in early phase. The Parametric estimates, which can be used when historical data is very sophisticated, that can lead to a higher level of accuracy, however, it should be avoided if the project is being carried out in an economy with very fast escalating inflation. Finally, the bottom-up (or quantity takeoff) technique, this can be used when we have detailed documents, and avoided when time or requirements are not clear.

Some of the lessons learned are that project managers manage estimates throughout the projects’ life cycle, keeping in mind the following; Steering clear of too precise estimates. Considering leveraging cost estimating experts; knowing that great estimating teams is worth their weight in gold. Giving stakeholders a behind-the scenes look, which means that you should show stakeholders what is behind the estimate and how you got there. Finally, keeping an open dialogue with stakeholders, especially when original estimates are being adjusted during the project life-cycle, stakeholders should be aware of that.

Personally, I find the final judge for the overall performance throughout the project lifecycle is the customer satisfaction; in many projects that I worked on, the project went over budget and also beyond schedule, but still the customer was satisfied. For many customer, when they see how well did you do on the project, they understand that project did not fail during execution, but the project fail only to estimate the cost and schedule, and because their money or investment was utilized in the best way possible, many times they found themselves satisfied with the outcomes.

What I also found from my own experience is that the main job for the project manager is to communicate, and getting heavily involved in the communication process. Keeping the sponsors updated with the changes to the original estimate can eliminate the surprises which sponsors hate the most. To get a better estimation, I used to divide my scope of work into much small parts presented in tasks, and that most of the time gave me a better understanding to what the final schedule would look like, and with that much of detailed data, I was able to avoid the pressure coming from my top management and my clients as well. My manager, who was the head of the design department is a very supportive person; however, he wanted us to provide alternatives when we say “the proposed schedule from the client does not work”; so we used to support our claims by strong set of data every single time, and I believe that was a healthy practice that my department did.

bottom of page