Padding Your Project Timelines

by | Jul 25, 2006 | Miscellaneous

Jim Cahill

Chief Blogger, Editor

I read a fascinating piece about methods of estimating software project schedules. It was written by Shenling Yang, a senior software engineer for the DeltaV system. I bring it up here because many project managers and project engineers are faced with similar questions of how to best estimate project schedules.

Shenling starts by citing an InformationWeek magazine piece entitled, To Err is Human, To Estimate, Devine from several years ago which states:

A recent study of 100 companies found the average company completes only 37% of major IT projects on time, while only 42% finish on budget.

Shenling attributes much of this to the difficulties in gathering accurate estimates of software development effort. The quality of the estimates directly affects whether or not the project team can meet scope, quality, and schedule commitments.

A common method of estimation is the bottom-up, task level approach, relying on the judgment of the team members in performing the tasks. This method, coined “Expert Judgment” by Robert Hughes in an Information and Software Technology article is subject to human biases. There are many biases that have an impact on project estimates, and Shenling cites prudence bias as one of the biggest.

This bias is the accumulation of padding all the tasks which can result in overly cautious project schedules and uncertainties across the project schedule. In our nature there is a tendency to procrastinate or delay the start since of the task knowing this padding exists.

A better approach Shenling points to is project schedule-based padding to handle risks and uncertainties. A great analogy she uses is a local store with 5 checkout counters. If there are individual lines for each counter, your chances of getting stuck in a slow line are greater. If there is one line feeding the 5 counters your risk of “getting stuck” is reduced since the uncertainty of the speed of checkout at a particular counter is reduced.

To minimize the schedule risks of your project it’s better to apply the padding at the project level, and not at the individual task level. The overall project manager should clearly communicate this padding to all the team members in order to keep everyone on the same page and going in the right direction. Great words of wisdom, I’d say.

Submit a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Submit a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Subscribe for Updates

Follow Us

We invite you to follow us on Facebook, LinkedIn, Twitter and YouTube to keep up to date on all the latest news, events and innovations to help you take on and solve your toughest challenges.

Want to re-purpose, reuse or translate content?

Please do, Just link back to the post and send us a quick note so we can share your work. Thanks!

Our Global Community

Emerson Exchange 365

The opinions expressed here are the personal opinions of the authors. Content published here is not read or approved by Emerson before it is posted and does not necessarily represent the views and opinions of Emerson.