Estimating the Unknown: Projects or Budgets, Part 2

So now that you know why it's so difficult to estimate what do you do when someone asks you for an estimate?

Preconditions for Estimation

First, you ask a question back: “What's most important to you? If it's 3 weeks before the end of the project, and we haven't finished all the features and we have ‘too many' defects, what are you going to say?

  • Release anyway? That says time to release is king.
  • Are you going to say ‘these features better work'?
  • or are you going to say, ‘these defects better not show up'?”
Project Pyramid

You can have only one #1 priority in any given project or program. You might have a right-behind-it #2 priority and a right behind-that #3 priority, but you need to know where your degrees of freedom are.

Remember that project pyramid from before? This is your chance to rank each of the vectors in the pyramid. If feature set is first, fine. If time to release is first, fine, if cost is first, fine. If low defects is first, fine. Whatever is first, you don't really care, as long as you know and as long as you only have one #1 priority. You run into trouble on estimates when your management wants to fix two out of the six sides to the pyramid—or worse—more than two sides.

When your managers say to you, “Here's the team, here's the office space, here's the budget, here's the feature set, and here's the time,” you only have defects left to negotiate. And, we all know what happens. The defects go sky high, and you also de-scope at the end of the project because you run out of time. That's because you have too many fixed constraints.

Insist on a Ranked Backlog

If you really want to estimate a date or a budget, here is how to do it. You have these preconditions:

  1. You must have a ranked backlog. You don't need a final backlog. You can certainly accommodate a changing backlog. But you need a ranked backlog. This way, if the backlog changes, you know that you and the team are working on the work in the correct order.
  2. The team who will do the work is the team who is doing all the estimation. Only the team who is doing the work can estimate the work. Otherwise the estimate is not useful. Surrogate estimators are biased estimators.
  3. You report all estimates with a confidence range. If you report estimates as a single point in time, people think your estimates are accurate and precise. If you report them as a confidence range, people realize how inaccurate and imprecise your estimates are, and you have a shot of people treating them as real estimates.

Once you've met the preconditions, you can estimate. And the reason I have projects or budgets in the title of these posts is that the same reasoning works for both project dates and budgets. Hang in there with me, all will be clear at the end.

The series:

And, the book: Predicting the Unpredictable.

3 thoughts on “Estimating the Unknown: Projects or Budgets, Part 2”

  1. Pingback: Blog IT – Mateusz Mrozewski » Daily Dose of Reading #3

  2. I encountered that the team tends to over-estimate time putting too much cushion in it. One of my team ever estimated a SINGLE screen for 2-week implementation, and ended up implemented it with 2 days. -_-;

  3. Pingback: Estimating the Unknown – Series of Posts by Johanna Rothman | Can I change this later???

Leave a Comment

Your email address will not be published.

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

%d bloggers like this: