A project manager friend of mine recently transitioned into software industry from hardware manufacturing. He was complaining about the problems he’s been having to come up with good schedule for mid-size software project.
Specifically, he was referring to the problem of padding in estimation for tasks. Being new to software industry, he was not sure whether the estimates provided by his team members were accurate or padded.
The padding refers to extra time added to a schedule that isn’t really needed but that is added just to feel confident in the estimate. The impact of padding could be significant on project schedule. The quality of the estimates directly affects whether or not the project can meet scope, cost and schedule commitments. The accumulation of padding all the tasks can result in overly cautious project schedules and uncertainties across the project schedule.
According to one estimate , the average company completes only 37% of IT projects on time, while only 42% finish on budget. Much of this is attributed to the difficulties in gathering accurate estimates of effort.
The reasons for padding the estimate could be many. The resource might have multiple projects that they work on. They have overlapping work from those projects. They have nonscheduled time or they are given conflicting priorities. Rita Mulchay explained it nicely in her PMP preparation book by summing up team member’s thoughts:
“I have no idea how long it will take. I do not even know what I’m being asked to do. So, what do I say? I will make my best guess and double it! ”
There are a number of approaches project manager could take to address the issue of padding:
- Use expert judgment. Let the experts review the estimates provided by estimators. The experts can identify cases where the estimation doesn’t seem right. These could be senior or principle software engineers within the company.
- Use estimating techniques such as stochastic estimation. Ask team member to provide a range of estimates. For example, asked member to come up with task estimate for best case scenario, worst case scenario and most likely scenario. Using the 90% confidence factor, one can come up with reasonable estimate.
- As project manager, you should provide sufficient time to estimator. If estimator is asked to estimate a task on the spot, estimator may feel pressured and provide a number just to get us off their back. Estimators should be provided enough time and encouraged them to think carefully and thoroughly to come up with estimate.
- To minimize the schedule risks of your project, it’s
- better to apply the padding at the project level instead of at the individual task level. This is commonly referred to as buffer. Make sure to communicate about project level buffers to all the team members to keep everyone on the same page.
- Instead of asking for estimation of task duration asked in terms of task effort. This helps avoid introducing padding into the estimation process. Also, understand that people are human beings and no one works hundred percent of their time. When estimator provides an estimation of the effort, the numbers should reflect continuous, nonstop work.
Over the weekend, I facilitated fabulous workshop on Advanced Microsoft Project sponsored by PMI Silicon Valley chapter. According to instructor, every time software developer is interrupted it takes 14 minutes on average to get back to development work.
Additionally, I have experienced that software quality assurance engineers generally estimate efforts over cautiously whereas software developers tend to provide over-optimistic estimates. Understanding and factoring such elements can help improve accuracy of estimates.
Lastly, for medium to large projects project estimation software such as Cost Xert or KnowledgePlan can be utilized effectively. There are also other methods such as System Development Life Cycle (SDLC) which consist of a set of best practices that lets engineers break projects down into recognizable and repeatable steps, processes, tasks and outcomes, each of which can be accurately estimated.