Avoiding Padding Problems when Scheduling Projects
Avoiding Padding Problems when Scheduling Projects
By Kuntal Thakore
A Project Manager colleague 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 the 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 in all the tasks can result in an overly cautious project schedule as well as some 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 resources 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 one 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 that a 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 some 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 members to provide a range of estimates. In other words, asked team members to come up with estimates for best case scenario, worst case scenario and most likely scenario. Using the 90% confidence factor, one can come up with reasonable estimate.
-
As a Project Manager, you should provide sufficient time to the estimator. If the estimator is asked to estimate a task on the spot, he or she may feel pressured and provide a number just to get you off his/her back. Estimators should be provided enough time and encouraged 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 the project level buffers to all the team members to keep everyone on the same page.
-
Instead of asking for estimation of task duration you should ask 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 a hundred percent of their time. When an estimator provides an estimation of the effort, the numbers should reflect continuous, nonstop work.
General Notes
- 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.
-
For medium to large projects, a variety of project estimation software can be utilized effectively. There are also other methods such as the System Development Life Cycle (SDLC) which consists 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.
Kuntal Thakore, PMP, CSM has 13+ years of experience in Software Industry covering areas of Customer Service, Quality Assurance, IT administration and Software Development. Kuntal has managed and participated in IT and Software projects ranging in size from small to large corporate-wide projects. He is able to build cross-functional teams, negotiate various levels of hierarchy, and apply his experience to small and large businesses alike. He has strong customer oriented skills and technical development experience to work cross functionally for resolving customer issues. Kuntal holds degrees in Computer Science and lives in California’s Silicon Valley. He can be reached at bkthakore@gmail.com.
I would add that the best way to get accurate estimates is to gather data of prior estimates for not only similar jobs, but from the same people. Over time you’ll recognize those that tend to be optimistic and those that pad. This is also true at an organizational or regional level where different work cultures display different tendencies (just compare common Europe, US and Asia practices!).
At the same time, when adding a buffer at the project level, you need to be careful how you recognize project revenues and/or accrued costs according to what has been delivered. Leaving all the buffer until the end of the project will typically not please the CFO! If the project has distinct delivery milestones – for certain feature sets, say – it’s often wise to allocate buffers to each milestone based on the risks associated with reaching that milestone.
John D’s comment was good, and so was this post. I think this is a significant problem for project managers across the industry spectrum. Thank you for addressing it!