Why Managers Ask for Estimates and What They Need to Know

In many of my transitioning to agile clients, the managers want to know when the project will be done. Or, they want to know how much the project will cost. (I have a new book about this, Predicting the Unpredictable: Pragmatic Approaches to Estimating Cost or Schedule.)

Managers ask for estimates because they want to know something about their ability to recognize revenue this year. How many projects can they release? What is the projected effect on revenue; customer acquisition and retention; and on service revenue (training, support, all that kind of service). We pay managers big bucks so they can project out for “a while” and plan for the business.

You need to know this in your life, too. If you are an employee, you know approximately how much money you will make in a year. You might make more if you get a bonus. You might make less if you get laid off. But, you have an idea, which allows you to budget for mortgages, vacations, and kid’s braces.

Remember, in waterfall, there was no benefit until the end of the project. You couldn’t realize any benefit from a project until it was complete: not revenue, not capitalization, not any effect on what customers saw. Nothing.

When you use agile, you have options if you can release early. Remember the potential for release frequency?

If you can do continuous deployment or even release something more often, you can realize the benefits of the project before the end.

If you are agile, you don’t need to estimate a lot to tell them when they can first receive value from your work. You can capitalize software early. Your customers can see the benefits early. You might be able to acquire more customers early.

Agile changes the benefits equation for projects.

Agile is about the ability to change. We see this at the team level clearly. When the team finishes a feature, the team is ready for the next feature. It doesn’t matter if you work in flow or timeboxes, you can change the features either for the next feature (flow) or at the next timebox. You can change what the team does.

Agile is most successful when teams finish features every day (or more often). The faster you finish a feature, the faster the team gets feedback on the feature. The more flexibility the product owners has to update/change the backlog for the team (either for flow or the next timebox). The teams do have to complete their work on a feature in a reasonable amount of time. If your cycle time gets too high, no one sees the flow of features. If you don’t get to done at the end of the iteration, you don’t get the benefit of agile. Teams need to learn how to get to done quickly on small features, so they can demo and get feedback on their progress.

What does this fast delivery/fast feedback cycle do for senior managers?

It allows senior managers to change their questions. Instead of “When will this be done?” or “How much will it cost?” senior managers can ask, “When will I see the first bit of value? Can we turn that value into revenue? When can we capitalize the work?”

Those questions change the way teams and senior management work together.

When teams do agile/lean, and they have a constant flow of features, managers don’t need “assurances” or “commitments to estimates” from the teams. Instead, the team estimates a much smaller chunk of work–time to first delivery value.

You might not know precisely when you can deliver that first value. But, as soon as the team works together if they understand agile/lean, they can create a reasonable estimate. They can update that estimate if necessary.

What else can teams do?

  • Work to a target. If the teams and the product owners know that management has a desired release date, they can work to it. Teams can track their feature flow through their systems, understanding their cycle time. They can use timeboxes for focus. They can measure how close to done they are with a product backlog burnup chart.
  • Demo as you proceed. Always demo to the product owners. Depending on the pressure for revenue/whatever, ask the senior managers to participate in the demo. That way, they can see the product’s progress as you add more features.
  • Keep the backlog item size small. It doesn’t matter how much is in the backlog if the size of every item is small. The smaller the backlog items, the easier it is for teams to estimate. It’s also easier for teams to maintain a flow of features into the ever-evolving system. Who knows? You might be done earlier than you expect.

With agile, you don’t have to set the strategy for a year, fund the projects, and expect that the projects will complete within that year. A year is a long time in almost every market. Managers might want the ability to change their strategy, and still get to a first “delivery of value” date.

Our metrics need to change. Cost to release or time to release is inadequate. They are inadequate because we can change the backlog at any time.

Instead, consider these metrics:

  • Time to release value: How long will it take us to release something for revenue? (The smaller the number, the better.)
  • Frequency of release: How often can we release? (The higher the frequency, the better.)
  • Run rate (What the team costs per unit time)
  • When you capitalize software. I will admit too much ignorance here to provide you guidance.

I have other measurement suggestions for programs in Organizing An Agile Program, Part 5: Measurements That Might Mean Something to a Program.

It’s not about #noestimates. It’s about which estimates your managers need. Managers have a fiduciary responsibility to the organization. You have the responsibility to release often, at least internally. The more often you release, the fewer time/cost estimates your managers need. The more your managers can take advantage of capitalizing software and what the software can do for the organization and the customers.

Your managers need estimates. And, they need to change the estimates they request. It’s all about your organization’s transition to agile.

PredictingUnpredictable-smallP.S. I wrote a book about estimation: See Predicting the Unpredictable: Pragmatic Approaches to Estimating Cost or Schedule.

7 Replies to “Why Managers Ask for Estimates and What They Need to Know”

  1. Managers frequently need estimates because they have alternatives to consider. I may have a choice between having an internal team develop custom software, or buying and implementing packaged software, or contracting for software as a service, or outsourcing the business function to some third party, or simply adding low-cost people and doing the task manually. If I can get estimates for all but that custom software development alternative, I’ll probably remove it from my list.

    1. Dave, you are correct. In that case, you need a gross estimate–because the cost of a detailed estimate is almost always too high. And, you might not be using agile approaches for projects.

      INMHO, choosing to do a project based solely on cost if it is part of your core value, what you provide to your customers, is a bad idea. Why would you outsource part of your value? On the other hand, there are many projects you might be able to outsource, to keep your people on your value-laden projects.

      You might want to take a look at Why Cost is the Wrong Question for Evaluating Projects in Your Project Portfolio to see more of my thinking.

      If your organization needs to move quickly to adapt, you want more options than long waterfall projects that only provide value at the end. If you have more time flexibility, using cost as one of your “which projects provide us more value now?” questions does make sense.

      1. Thanks, I read it when you published it, liked it, and linked to it from my weekly-round-up. We agree on the key points.

        People who make decisions based solely on acquisition cost probably have other bad habits. However, I would suggest that any decision model that doesn’t consider life cycle cost, in addition to the transition cost to an eventual replacement, is a recipe for waste. I helped some folks replace their ERP system a few years ago, when the last programmer who had been a party to their unfettered customization left and they could no longer absorb the maintenance costs. I don’t know what their original expectation for the life span was, but they junked it early. Now they’re on a SaaS system, with predictable operating costs, and going forward, they can spend their capital funds on things that generate revenue.

        Check out Toby Elwin’s blog post on the increasing rate of turnover of the annual Fortune 500 list – companies are failing, and doing it ever more quickly. Not all lousy decisions are handed down from the executive suite – many of them originate in parts of the company where people with specialized knowledge can’t be bothered to provide estimates, identify and escalate risks, or otherwise help navigate. Agile methods should not be justification for non-participation in business decision making.

Leave a Reply