How To Quickly Give Your Boss An Accurate Estimate
“A drive-by estimate occurs when a senior manager corners a subordinate and demands an immediate answer to the estimation questions: “When can we get this project done?” “How much will it cost?” and “How many people do we need?” Depending on how much pressure is applied, the unhappy estimator must produce some numbers and do it quickly, usually without much research. Estimates derived this way are normally of low quality and making any kind of critical business decision based on them is dangerous and often costly.” The Goldilock Estimate, Communications of the ACM, Oct 2012.
I see this every day, it seems. We complain about being asked to provide a quick estimate and we are not given the time to “do it right.” The problem is, however, not that we’ve been surprised with an unreasonable request for a quick estimate. The problem is, in my experience, that we have not prepared ourselves to give quick estimates.
I’ll ask folks how many times they’ve gotten these demands for quick estimates. They say ‘all the time.’ Ok, great, so what are we doing to be able to meet this need for quick estimates? Nothing.
Why nothing? Well, because we have a formal process that takes weeks or months to crank out an estimate and that is how we “should” do estimates. So, how well does this process work? We don’t know because it is rarely used, and when we have used it completely, the project didn’t perform (on time, good quality) any better than other projects that didn’t use the formal method. It just took more time to do the estimate. But next time, I am assured, it will provide a great estimate!
When I was the development director, I had an account manager ask me how long it would take to deliver a new software feature. Before he could explain the details of the feature, I told him nine months. He freaked. We delivered it in nine months. The customer thanked us for finally meeting our promise.
The demand in the emergency meeting was for when would we fix the defect just reported by the customer? I, as the project manager, said it should be fixed by this time next week. Everyone howled. It was fixed by next week. The project was delivered on time and was the first time any project had been delivered on time in the memory of the organization.
How could we answer these demands so quickly and accurately? Simply put, we knew we needed to do this kind of thing and so we prepared for it. We didn’t argue that it was unreasonable or that we needed to follow a different process. We just found a way to do it.
Once we changed our own mindset and stopped railing against the assumed unreasonableness, we came to realize that we could do good estimates quickly. People were often shocked when we quickly provided good estimates. The shocks were almost always because it was longer and more expensive than people were imagining — which is common when finally providing accurate estimates!
For more details see: Yes, You Can Quickly And Accurately Estimate And Commit Your Project
What cushioned the impact was that our customers were rarely shocked by our estimates and that we then delivered as promised, on schedule, on budget, and with good quality. We often got congratulations from our customers for finally providing good estimates and delivering on them.
If we know senior managers will regularly be asking for quick estimates, then we quite clearly need to be prepared to make such estimates. Once we decided to try and solve this problem, we found it much easier and more doable than everyone assumed. The project management tool that worked in this case was the willingness to accept a challenge that conventional wisdom would never even consider.
What would you need to know about your projects to be able to make quick and accurate estimates?
23 thoughts on “How To Quickly Give Your Boss An Accurate Estimate”
Comments are closed.
Kailas,
Absolutely, the requirements are important. But at least in my experience, it is often not the case that the requirements drive the schedule. I know this sound unintuitive, but I cover this paradox here http://pmtoolsthatwork.com/is-your-project-schedule-really-driven-by-your-requirements/.
Good observation.
Bruce
Thanks for sharing the thoughts. But IT am still not sure if this would work in more than 10-15% of cases. How can anybody be sure about estimates before understanding at least how many features does it involve?
More comments and responses:
Victor Hunt:
Bruce,
So what you are saying is that you should have your “historical data” in your back pocket, so that you can use it for quick estimates. Good point.
On 01/18/13 7:32 AM, Bruce Benson wrote:
——————–
Victor,
What I would add is that this time can be applied in advance. We want to know how we perform now, which then allows us to make those quick estimates when the opportunity arises.
Good point.
Bruce
More comments and responses from around the web:
Héctor Cordobés:
Yes, I utterly agree with your clarification.
Good estimates are needed in any serious project, but they are only meaningful when they are the result of a reasonable and agreed process and not just the urge from management. Good communication is instrumental.
BR
-Héctor
On 01/18/13 7:38 AM, Bruce Benson wrote:
——————–
Héctor,
I agree,when the quick estimate is your typical not well done estimate. But you make a good point in that not only should we be ready to provide a quick estimate, but that we also need to be regularly keeping the bosses informed so that they have knowledge they need and they better understand what they are getting when we give them the quick estimate.
Good thought. Thanks.
Bruce
More comments from around the web:
Date: 1/24/2013
Subject: RE: Bruce, Thanks for the article. But one thing, I believe you need to have a certain level of “maturity” within your organization to be…
Bruce,
I agree that is a good method towards getting a start on a baseline, but I believe the “face-to-face” interview process needs to be followed in order to get the “hidden agenda” regarding any change. There are things that are documented and there are those things which are believed but not stated/documented. You have a better chance of getting to that level of information/detail by conducting interviews.
Thanks
Bob
More comments from around the web:
Navneet Randhawa • We track actuals. I have created a excel tool to give a good ballpark estimate (based on historical project data). The tool has buckets for small, medium, large projects. Tool accounts for complexity and back end vs user interface changes. We are 95% accurate with our estimates (when we compare them to actuals at end of the project)
Capers Jones • All,
I’m building a fast estimating tool covered by three U.S. patent applications.
It sizes applications in about 90 seconds and does full estimates in about 4 minutes. The default metrics for size are IFPUG function points and logical code statements. But it is metric neutral and also predicts size in story points, use-case points, and 12 other metrics.
The tool can predict results from 34 development methods, 129 programming languages, and all 5 levels of the CMMI.
It can be set for IT projects, web aps, smart phone aps, commercial software, government aps, military aps, systems and embedded, etc. All of these are a bit different in cost structures.
It also predicts requirements growth during development and for 5 years after the initial release. Of course it also predicts maintenance, enhancement, and customer support.
There are some special features not found in other estimation tools:
1) It predicts the odds of litigation for outsource projects.
2) It predicts the litigation costs for both the plaintiff and defendant.
3) It predicts the number of rounds of venture funding for start ups.
4) It predicts training costs for users of complex systems
5) It predicts a large number of risks including cancellation
The 34 methods it predicts are shown below.
It is under development and not yet a commercial product, although I use it daily. The tool is called Software Risk Master.
If anyone is interested in a few samples send an email with a valid return to Capers.Jones3@gmail.com.
Regards,
Capers Jones
1 Mashup
2 Hybrid
3 IntegraNova
4 TSP/PSP
5 Microsoft Solutions Framework
6 RUP
7 XP
8 Agile/Scrum
9 Data state design
10 T-VEC
11 Information engineering (IE)
12 Object Oriented
13 RAD
14 EVO
15 Jackson
16 SADT
17 Spiral
18 SSADM
19 Iterative
20 Flow based
21 Iterative
22 Flow based
23 V-Model
24 Prince2
25 Merise
26 DSDM
27 Clean room
28 ISO/IEC
29 Waterfall
30 Pair programming
31 DoD 2167
32 Proofs of correctness
33 Cowboy
34 None
Kalyanasundaram Ramanathan • Navneet – Can you share your estimation tool to kalyan1971@gmail.com please?
James Heires, PMP • Navneet,
This is a good start to collect actuals and iteratively (I assume) tailor the estimating relationship with new/updated actuals. You don’t specify what actual measures you are collecting, but in my experience, if you’re attempting to estimate effort and/or duration, you will need to collect the SEI ‘core measures’ of size, time, effort and defects (all by SDLC phase). In addition, estimation models should produce a range of estimates with associated probabilities, since by nature, estimates often deal with a great deal of uncertainty.
James
P.S. Sorry to flag Capers’ post as inappropriate, but this is not the place to self-promote your new do-it-all tool.
Capers Jones • James,
Fine – I’ll leave this group.
I’ll mention that James’ recommendation of phase level data won’t work. There is no way to validate phases. You need activity-level data. Too many activities span multiple phases such as project management, technical writing, quality assurance, etc.
Also for most companies historical data “leaks” and only covers 37% of true software costs. The most common leaks are unpaid overtime,project management, and the work of part-time specialists.
For those who want to understand benchmarks I have a free catalog produced as a public service and available at no charge,
It is a catalog of software benchmark providers and it lists 23 groups including SEI, ISBSG, QSM, Galorath, Q/P Management Group, etc. There is no charge for the groups to be listed and no charge for the catalog, which is not copyrighted and can be freely distributed.
The total number of projects benchmarked by these 23 groups is about 91,000. ISBSG is the biggest source of downloadable benchmarks with more than 5,000. Some Air Force benchmarks can also be downloaded – around 500 as I recall.
The catalog also lists 76 books about software cost estimation including those by Boehm, McConnell, Galorath, Roetzheim, etc.
The catalog is is not a commercial book and is a pure public service distributed because the software community needs better benchmarks..
This is my last post on this group.
Capers Jones
Bruce Benson •
I really like tools but they too often overwhelm the users and the managers. I had great success with SEER-SEM for example, but I only used it because it was mandated. I generally used what Navneet appears to have created. Once we get the method working, then we’ll often wrap some automation around it to make it simpler for others to pick it up and use it.
I do like packages that give me an option to pick the method I want to try (or try them all or whatever data I enter gets propagated – where possible – to the other methods, etc.). If there is a tool I always look to see if it keeps a good database of my inputs and allows me to import and export that data. Ideally, there is an api or webservice interface that allows me to automate using the tool. If I can’t automate its use and mash it up to our current process and tools, then I don’t like to invest in learning and using the tool.
Responding to a post by saying “hey, I got a tool” is a perfectly acceptable comment. I guess we should ban Navneet for mentioning her tool – she may be fishing for requests. In fact, if anyone has any response beyond generalities (i.e., concrete tools or anything that might cost money) they should be banned? I know, spam is a problem, but when we degenerate to silly/stupid we need to stop and think about what we are doing (gee, I just gave away the secret to my consulting business).
More comments from around the web:
Bob Vandenberg • Bruce,
Thanks for the article. But one thing, I believe you need to have a certain level of “maturity” within your organization to be able to give accurate “snapshot” estimate.
Bruce Benson • Bob,
We do need information on the performance and state of the team/organization to make the estimate. With that said, we’ve always been able to dig it up. In some cases it came from finding old status reports and meeting minutes and pulling out of them real data on what happened and when (schedule, cost, requirements, etc.). It is the case that the more mature and more organized the organization the easier it is to find the information and hence make a good, quick estimate.
Good point,
Bruce
More comments from around the web:
Héctor Cordobés • Sometimes I feel that making a quick estimate is solving the wrong problem. Which should be making the manager understand what is going on /and then/ making a fair and somehow coarse estimate.
Bruce Benson • Héctor,
I agree,when the quick estimate is your typical not well done estimate. But you make a good point in that not only should we be ready to provide a quick estimate, but that we also need to be regularly keeping the bosses informed so that they have knowledge they need and they better understand what they are getting when we give them the quick estimate.
Good thought. Thanks.
Bruce
More comments from around the web:
Victor Hunt • @Bruce: thank you for this eye-catching topic.
The accuracy of estimates is proportional to the time needed to make the estimate: more accuracy requires more time.
Another way of putting it is: the margin of estimates is inverse-proportional to the time needed make the estimate. The less time available, the bigger the margin. There is a time-margin trade-off.
This time-margin trade-off is a law of nature: it takes time to gather information for your estimate. I agree that a proper mindset will help as mentioned in the article, but you are still bound by that time-margin trade-off
Bruce Benson • Victor,
What I would add is that this time can be applied in advance. We want to know how we perform now, which then allows us to make those quick estimates when the opportunity arises.
Good point.
Bruce
Bob, great job on getting them to simply know their averages. I’ve found that to be a very simple approach that works amazingly very well for many organizations. Good luck and keep it up.
I hear you on the years it takes large companies to change Bruce. This is one area I constantly work with our customers on, that is, how to take advantage of the data-capturing ability they have available to them, and then how to use that data. One now calculates the average time it takes to complete specific task types, and then updates that data in their project templates that are used by all their PMs. Since their projects are customer driven as well, this results in better estimates/delivery times. Win-win.
Bob,
That’s the trick and the insight. The data is there if we take the time to dig it up (I know, I’ve done it). In many cases it only takes one person to start tracking the data.
I recall a big breakthrough I had, when I was tracking and publishing global metrics to support management of my project, was when an influential manager said in a global conference call “yeah, but did you see Bruce’s numbers? We need to be doing something different here …”.
Those metrics became the way all projects did business within a few years (yes, years, but I’ll take it and it was a very big company).
Good comment, thanks.
Bruce
Great examples of using what should be basic project metrics Bruce, but how many companies actually track and use the data to even get to there? In my opinion, even though they could do it, they often don’t, with the main argument against being that it creates too much of a burden on PMs and resources. This seems to me the tail wagging the dog, but I see often enough.
More comments from around the web:
Bruce, I agree, this is mostly humorous. When it comes to answering a drive-by estimate an engineer can often apply past experience. The old rule of making a gut-level guess and then doubling it still holds. But, while reading the article, I noticed something that I think makes such things as drive-by estimates worthwhile: they force engineers to think seriously about schedule.
By Steven Brovero
More comments from around the web:
Ronald (NSN – US/Irv Manahan • I have been estimating the details of Moto projects for years and feel that I am good at it and you can usually take that to the bank. Sometimes the customer won’t buy off on all of the details but most of the time my management agrees with me. How am I able to do this time after time? I only estimate jobs that I have done many times myself and I have been doing this type of work for 27+ years.
More Comments from around the web:
Blaine Bateman, EAF LLC • Hi Bruce. Good posts and advice. In his book “How to Measure Anything” Douglas Hubbard gives lots of good ideas about how to approach quantitative estimates.
More comments from around the web:
Andy Rozylowicz • Estimating projects is about scoping content, time and resources. It can be done quickly. I always found that turning the question into a bounding exercise made it easier. That is, instead of trying to exactly calculate resource and time, given some content, I asked if you can do it in 1 day, 1 week, 1 month, 6 months…. Similarly for staff. Using templates help too. And ask several people, not just the expert. In fact, expert estimates are often the worst.
Bruce Benson • Andy,
I like the bounding approach. When we know how our organization performs, it is often fairly easy to get that ballpark right using bounding like this.
Yes, too often I’ve found it also true that “expert” estimates are the worst.
Thanks for the feedback,
Bruce
More comments from around the web:
Lee R. Lambert • Be real, if someone is asking for an ACCURATE estimate then they may not understand the process of estimating. If they were accurate, they wouldn’t be called estimates!
Theresa Santoscoy • Mr. Lambert thank you for this comment, estimates are general and meant to give quick views of about where the project is at. What number or activity comes out the estimate will tell enough to your boss to indicate if more information is needed at that point. Of course if a job is well done then a quick estimate can be good enough to satisfy a bosses position.
Stephen Maas, MBA, MPM, PMP® • Quick Accurate Estimate. That’s an oxymoron.
Bruce Benson • Lee, Stephen,
Everything is an estimate, of course, in predicting the future of cost, schedule, etc. Some are more accurate than others. More accurate means that they are more representative of what ultimately happens than other estimates.
When can we get accurate quick estimates? When we know how our team/organization performs. How do we know how they perform? Know their recent past performance.
For organizations that regularly miss their estimated schedule, for example, a method that works well is to dig up the history on past schedule performance. What we typically see, for example, is that project estimates vary from 12 to 15 months, but the actual schedules from end to end (often including multiple replannings) averages 18 months (yes, real example, Fortune 50 company). The solution? The next project is planned for 18 months.
I had a business manager come out of the project/product executive approval board with an approval to launch a new product in 12 months. I told him he was already six months late. A few months into the project, we were into crisis mode as early milestones were being missed. We were then told that we would lose 120+ engineers because another project, trying to finish, was way behind and also in crisis. I proposed a new plan, one that coincidentally aligned with 18 months from the original approval. Note, there was no adjustment to the plan because of any of the crisis or the loss of 120 engineers. What happened? We hit the schedule (within two weeks) and got great compliments from our biggest European customer for finally delivering a new product when we said we would.
In another case and another company, an account manager came into my office and started to outline what his customer wanted. Before he got a few words out, I told him he could tell the customer that it would be delivered in the 3rd quarter of next year (the account manager freaked). Again we nailed it and the customer thanked us for finally delivering new software on time. What did I know? I knew it was taking us an average of nine months to deliver new software releases. I also knew that we regularly promised new functionality to our customers “in a few months” (seriously). I knew 9 months would be a lot closer than “a few months” even when I didn’t know the requirements.
We’ve done the same with estimating time to repair reported defects, add new features to electronic products and deliver new software features. In all cases we could give quick and accurate estimates — based upon past performance — that were significantly better than estimates given in the past (i.e., we delivered when we said we would deliver).
Too many folks see a quick estimate as a throw away — but in fact if we know how we perform (which is a bit of a challenge, but doable, that’s another discussion), the quick elevator estimate can become the project plan.
Thanks for the feedback
Bruce
Comments from around the web:
Steward Copper • Sorry, but I can’t find the answer to the mentioned question in the article. You say that we need to be prepared, we just need to find a way to do it. And so on. I’ve read your success stories… But how do you choose if to say nine months or maybe ten before carefully studying the requirements, resources and technologies?
Bruce Benson • Steward, good points. Context is important in getting to good estimates. What this means, for example, is that if we regularly underestimate our projects, by months, then what I’ve always done — successfully — is to use the average of our previous projects to be our current estimate. So the first step was to move us closer to a good estimate and somewhat un-intuitively that didn’t require analyzing the requirements — at least not for figuring the overall schedule duration.
So as in a few real world examples, we were regularly 3-4 months late in delivering mass market electronic devices to customers. We estimated everything from 12 to 15 months, but when we averaged up all the actuals (how long it really took) the average was right at 18 months. So I chose 18 months as the schedule and then hit is on the nose (within two weeks). The customer thanked us for finally delivering when we said we would deliver (after years of not doing so). We also in one case were sure the testers hadn’t tested the product when they reported only one defect after a week of testing. Normally, they would have reported dozens and even into the hundreds in a week. Using an achievable schedule always resulted in a huge bump to quality as well as being on time.
So the indicator here is that if we collect up and average up the original estimates and compare then to the actual results and we find that we are almost always late (such organizations are typically *always* late) then just choosing the average is a much improved estimate over past estimates.
(Note, getting good data can be a challenge but is doable, see: pmtoolsthatwork.com/5-reasons-managing-projects-objectively-is-hard/)
Note that using an average is an aggressive schedule. It suggests that we’ll only meet our schedules half the time. However, for organizations that are always late, hitting 50% is a huge improvement. Even better however, is that when we’ve used the average no team has ever been late by more than two weeks. So while it is statistically aggressive in actual use it is very achievable.
The other context of importance here is that these organizations were producing pretty much the same things, over and over. That is they produced a new electronics product or released a new version of their software. While the requirements were always different, when we looked at the track record for how long it finally took, the variance in the actual time it took was always much smaller than anyone would have guessed before seeing the data. I describe this phenomena as the People + Process + Tools used to produce a product has a greater impact on the schedule (and cost, etc.) than does the actual requirements. This is another somewhat un-intuitive dynamic I see regularly. (For more on this see: pmtoolsthatwork.com/is-your-project-schedule-really-driven-by-your-requirements/)
Good question. Hope this helps.
Bruce