3

We like to underpromise and overdeliver. If we don't pad, we become very late. I have heard some PM's especially on 1.0 projects that are much more difficult to predict will multiply the estimate by 3x sometimes. I would love to hear what other PMs do on padding their estimates.

Improve this question
2
  • Somewhat related: pm.stackexchange.com/questions/27792. Ideally you should not pad but add buffers for various risks (estimation risk is one of them: not enough info, not enough time, missing key people with expertise to refine the estimates, etc). Also ideally, uper management and clients should understand that an estimate is not a promise and should engage in communication/decision-making with the developers when reality hits, to reestimate or replan stuff. Unfortunately that doesn't happen and developers need to pad estimates to protect themselves from the wrath of others
    – Bogdan
    Jun 10, 2021 at 20:20
  • Watched a printer implementation project: it followed the « 90%of the project takes 90% of the time while the last 10% takes 90% of the time » perfectly - The IT head and I had a good laugh as non-IT managers had defined the time...
    – Solar Mike
    Jun 11, 2021 at 17:01

2 Answers 2

Reset to default
7

Add Slack and Remove Fear; Garnish with Trust; Stir Well and Serve

There can't be a single, canonical answer to this question except "Maybe you shouldn't." It really depends on what you're optimizing for. If your project has a lot of known-unknowns or unknown-unknowns, then you can't really fix that with padded estimates. Instead, you need to address those issues head-on during project initiation, or through techniques like story spikes or iterative decomposition of the work.

With that said, some common techniques for avoiding overruns (with analogs in many different frameworks) include:

  1. Using relative estimates, and rounding up to the nearest Fibonacci number.
  2. Using the "Scotty principle" and multiplying all your estimates by 200-400%.
  3. Applying fudge factors like 0.6 or 0.8 to velocity estimates based on things like newness of the team or complexity of the problem domain.
  4. Using statistical ranges for estimates, rather than fixed-value estimates.
  5. Adding slack to all work packages.

The problem with all of these approaches (as well as others) is that they each solve for certain assumptions, whether spoken or unspoken. In your case, the unspoken assumption is that Bad Things℠ will happen to you or the team when estimates are treated like money-back guarantees.

Rather than trying to pad your estimates, I'd recommend the following:

  1. Ensure estimates are treated as probability forecasts with acknowledged margins of error.
  2. Give the team sufficient political backing to make honest estimates, with the expectation that estimation will become more accurate (but never exact) over time.
  3. Treat missed estimates as validated learning opportunities, not blame-and-deflect exercises.
  4. Use iterative, incremental, or just-in-time planning along with time-and-materials budgeting to avoid the whole issue in the first place.
  5. Make sure that the project team has sufficient slack in every aspect of its process to create flex.

When people on a project are afraid to be honest in their estimates there is usually a political or process problem in play. Root that out vigorously; reward honesty, collaborative problem-solving, and effective communications rather than sweeping problems under the rug with inflated estimates.

Improve this answer
1
  • 1
    you hit this answer out of the park!!!!! Thank you. I think another issue is optics around 'random stuff' being inserted and I need to give visibility into that as well && usually I see a 20% of random stuff come in but on so many 1.0 projects in flight, I see much higher insertion rates and I need to start tracking those as well.
    – Dean Hiller
    Jun 11, 2021 at 12:42
0

Estimation is a big topic but I think the best answer here is also the simplest: use relative estimation techniques (story points and measured velocity) rather than absolute estimation. Relative estimates tend to be more accurate, make it easier to set accurate expectations and there's no need to pad out your estimates if you track velocity over time. Padding is only relevant for absolute estimates.

My assumption is that you take a continuous/iterative delivery approach to software development.

Improve this answer

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.