4

Project Managers are expected to guess the future, a difficult task even in sciences like meteorology. As many projects finish late (due to expanded scope, underestimated durations, etc), it is tempting to pad estimates.

When is it okay (or not okay) to do so? Off the top of my head, it is risky to share padded estimates with project team members (as they will expand their work to fit the expanded timelines), and risky to share padded estimates with management (as they will add some padding of their own before passing the schedule upwards). On the other hand, planning a schedule with no padding is pretty much guaranteed to lead to a late project.

Thoughts?

4 Answers 4

9

You should always work with a range of estimates: Most likely and worst case. Add margins at the risk spots in your schedule and at the end, but make them clear for all to see. That is the professional way of managing projects.

Manage your team members against the most likely estimates. They'll have no issue working on the edge when they know that there is room to manouvre when Murphy strikes.

When you have your contingencies worked out well, management will have no reason for padding.

In my experience, transparancy works best.

2
  • Well said. +1 for the estimate range. No such thing as a single-point estimate. Apr 1, 2011 at 11:18
  • +1 for range of estimates. There are great details about it in O'Reilly's Applied software Project Management, chapter III: Estimation. projektura.org/usp/…
    – Tiago Cardoso
    Apr 1, 2011 at 12:45
3

It is never okay to pad. Contingencies are calculated and added to the PMB to handle uncertainties in your time and cost estimates.

4
  • PMB = Project Management Baseline?
    – Sean Earp
    Mar 31, 2011 at 21:29
  • I'd say that contingencies are added to project budget. See my answer to this question: pm.stackexchange.com/questions/943/…
    – yegor256
    Apr 1, 2011 at 8:21
  • Contingencies can be both time and budget. You can add margins in your schedule; see Stephan's response below. Apr 1, 2011 at 10:48
  • Yes, PMB is project management baseline. Apr 1, 2011 at 10:49
1

It's better to under-promise and over-deliver than it is to over-promise and under-deliver. Padding your estimates by adding a safety buffer will help ensure you're in the first category and not the last category.

It's impossible to predict the future, especially if you're estimating something that contains many tasks you don't have experience with.

2
  • 1
    Beware of Parkinson's Law and Student Syndrome. Adding padding rarely delivers the under-promise, over-deliver notion but will most always increase costs. Apr 1, 2011 at 11:23
  • An aside Parkinson's Law as it applies to poorly speced things like a lot of software projects. There is often an endless opportunity to tweak things to make the UI a little nicer, or perf a bit better etc. Managers have to decide how much extra effort is worth it. But imo manage the cadence of the project against the most likely estimate. If there's slack I let my team go nuts gold plating a bit. I think it's a matter of professionalism to try to give customers/internal stakeholders not only a minimal solution but one they'll enjoy when budget (time and money) allows.
    – Mike
    Jan 6, 2020 at 15:01
0

'Padding and Estimate' is a skill and a base requirement for a PM - it's actually Risk Management, right? A plan is an map of where you are going and how long it will take to get there, neither are certain because neither have happened yet. You need to 'pad' or accommodate for a change in direction and a change to work effort based on events that have not happened yet (such as a change in developers, new technology, internal/external business changes/influences). A good approach is to compare prior projects for the same company/team and see how their original estimates matched up against the final. Another good approach is to develop a risk grid that includes a potential of occurrence and impact potential - with a range of time/$'s - you can use that as a 'risk pad' for the project.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.