The Art of Communicating Estimates

I was recently approached by one of our business partners, who wanted my help in submitting a budget estimate for a proposed project.  I asked a bunch of questions about the goals, and what she hoped to accomplish.  Then I asked about constraints and assumptions.  Then I asked about the business case – what did the ROI depend on?  At this point, she started to get impatient – what did all this have to do with the cost?  I replied, “I just want to be sure we’re talking about the same result, before we start talking about the ingredients.”

I then prompted her to tell me about her vision for migrating the users and their history and work in progress to the new solution.  She really hadn’t considered that part, but we talked about alternatives, pros and cons.  As we discussed more of the bits and pieces of implementing, she began to realize it was about more than just software licenses.  I asked about the availability of her folks to participate in requirements elicitation, and assist in testing, and her brow furrowed.  “We can bring in temporary help, if your people can’t be available.”  I agreed to estimate it both ways.

I made a few phone calls and Emails, looked up a few recent invoices to get some relevant labor rates, asked one of our systems engineers for a quote on a server, and summed it all up in an Email:

  • Project goals
  • Assumptions
  • Constraints
  • Risks
  • Alternative transition strategies
  • Alternative staffing strategies
  • Alternative timelines

I then estimated the costs for each component:

  • Hardware $$ (+/- 10%)
  • Software licenses $$ (+/- 10%)
  • First year of software support $$ (20% of software license cost)
  • Training $$ (+/- 25%)
  • Installation, configuration, and QA labor $$ (+/- 30%)
  • Requirements elicitation labor $$ for each staffing strategy (+/- a percentage for each alternative)
  • Cutover labor $$ for each transition strategy (+/- a percentage for each alternative)
  • Project management $$ for each timeline (+/- 15%)

“The top end is more than twice the low end.  How do I get this down to a single number?”  You can’t, I replied, but you can narrow the range.  Choose among the alternatives, then validate your assumptions, and reduce some of the variability of the components.  Finally, since there’s not much chance of all the estimates being exactly x% high or low, we’ll estimate the range at some fraction of the sum of the maximum variances, and use that as our range.

A few days later, she had settled on a dollar amount, plus or minus 20%.  Congratulations, I said.  “Not really,” she replied.  “At this cost, the business case doesn’t work, so we’re not going to pursue it.”  So, you saved us a bunch of money and wasted effort?  Nice work, I said.

This entry was posted in Best Practices and tagged by Dave Gordon. Bookmark the permalink.

About Dave Gordon

Dave Gordon is a project manager with over twenty five years of experience in implementing human capital management and payroll systems, including SaaS solutions like Workday and premises-based ERP solutions like PeopleSoft and ADP Enterprise. He has an MS in IT with a concentration in project management, and a BS in Business. In addition to his articles and blog posts, he curates a weekly roundup of articles on project management, and he has authored or contributed to several books on project management.

1 thought on “The Art of Communicating Estimates

  1. Dave,

    Great info, and example to back it up! I read through it several times, realizing I learned a couple things each time.
    Thanks for taking the time to post it!


Comments are closed.