Estimating the Unknown: Dates or Budgets, Part 1

Almost every manager I know wants to know when a project will be done. Some managers decree when a project will be done. Some managers think they can decree both the date and the feature set. There is one other tiny small subset, those managers who ask, “When can you finish this set of ranked features?”

And, some managers want you to estimate the budget as well as the date. And now, you’re off into la-la land. Look, if you had any predictive power, you’d be off somewhere gambling, making a ton of money. But, you do have options. All of them require iterating on the estimates and the project.

First, a couple of cautions:

  1. Never, ever, ever provide a single date for a project or a single point for a budget without a range or a confidence level.
  2. Expect to iterate on the release date and on the budget, and train your managers to expect that from you.
  3. If you get a ranked feature set, you can provide working product in the order in which your managers want the work done, while you keep refining your estimates. This has to be good for everyone.
  4. If you can say this without being patronizing, practice saying, “Remember, the definition of estimate is guess.”

First, remember that a project is a system. And, a system has multiple aspects.

Project Pyramid

If you’ve been managing projects for a while, you know that there is no iron triangle. Instead, there is more of a project pyramid. On the outside, there are the typical corporate constraints: Who will work on the project (the people and their capabilities), the work environment, and the cost to release. Most often, those are fixed by the organization. “Bud, we’ll give you 50 people, 5 months, and this pile of money to go do that project. OK?”

Whether or not it’s ok, you’re supposed to nod your head like a bobble-headed doll. But, if your management has not thought about the constraints, they may be asking you to smush more features in insufficient time that the people can accomplish, given the requested time to release, with the expected number of low defects in the expected cost to release.

The time to release is dependent on the number of people and their capabilities and the project environment. You can make anything work. And, there are delays with geographically distributed teams, lifecycles that do not include iteration with long lists of features.

This is why estimation of the budget or the time to release is so difficult.

Tags: , , , , , ,
Previous/Next Posts
« »


  1. Paul Leclerc

    I like your “project pyramid”. It gives another picture to point at and have a conversation. You explain that the outside edges are corporate constraints. What would you call the inside edges (Low defects, etc)?

    • johanna

      The inside edges are what the customer wants: A specific feature set, at a reasonable level of quality by a certain date.

  2. Doog Sieliga

    How do you deal with the case in which a consulting firm is asked to provide a fixed-price bid on a solution? Their goal is to make a profit, so they absolutely can’t underestimate. On the other hand, they are in competition with other firms, so they can’t add too much of a cushion. There seems to be a force that is driving these firms to start with a low-ball estimate to win the contract, and then beg for mercy when the budget runs out and the project is only half done. What is your advice for the consulting firms, and the customers of those firms?

    • johanna

      Doog, this require a significant blog or series. I am drafting. Look for it next week when I am past jet lag.



  1. Blog IT – Mateusz Mrozewski » Daily Dose of Reading #1 - [...] Estimating the Unknown: Dates or Budgets, Part 1 [...]
  2. Estimating the Unknown: Projects or Budgets, Part 3 | Managing Product Development - [...] need to know in what order your manager wants the features in. Why? Because if you look back at…
  3. Estimating the Unknown: Dates or Budgets, Part 5 | Managing Product Development - [...] discussed this in Part 1. You have more degrees of freedom than just the feature set or the release…
  4. Estimating the Unknown - [...] be done” says Johanna Rothman at the beginning of this series of blog posts that deal with project schedule…
  5. Articles of November: บทความที่น่าสนใจในเดือนพ.ย. | - [...] ใบให้สนุกๆ … ผู้เขียนซึ่งมีความเชี่ยวชาญในเรื่อง Agile Development มากแนะนำว่า “อย่าเด็ดขาดที่จะตอบหัวหน้าด้วยตัวเลขเพียงตัวเลขเดียวโดยไม่ระบุขอบเขตความน่าจะเป็นและระดับความมั่นใจของเราไปพร้อมกันด้วย” เช่น “อ๋อ งานนี้ใช้เงิน 1 ล้านบาทครับ ผมว่าวันที่ 15 พ.ค. ปีหน้าก็เสร็จครับ” … ฆ่าตัวตายชัดๆครับ ฮ่าๆๆ…
  6. Estimating the Unknown – Series of Posts by Johanna Rothman | Can I change this later??? - [...] Estimating the Unknown: Dates or Budgets, Part 1 [...]
  7. Why Does Management Care About Velocity? | All of Java - [...] the tush. Those are just the project conditions. Take a look at the project pyramid I have…
  8. Estimating the Unknown: Dates or Budgets, Part 1 | Managing Product Development | Brain Dump - [...] Dates or Budgets, Part 1 | Managing Product Development Posted on 2012/05/10 by mschinz…
  9. The Case For and Against Estimates: Part 5 – Technology Up2date - […] driving the project? They were told the date to release. Well, that changed to feature set. (See Estimating the…

Submit a Comment

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