Magic numbers of project management

No matter where I go, or what industry I’m talking to, if I ask enough questions of people who have schedules for important things eventually I hear a magic number.

A magic number is a mystical multiplier used to figure out schedules. Sometimes it’s small. Other times it’s large. But regardless of the size, very smart people managing very important things bet their projects on these numbers without having any logical reason for doing so.

Here’s the list of the common ones, plus some alternative non-magical ways to compute proper estimates.

Common magic numbers in the wild:

You know you have a magic number if you apply math to an estimate without any understanding of why it works instead of a larger or smaller number.
Double all estimates (2X). This is the most common one I see. It’s often used as a joke in some places, and taken deadly seriously in others. Often it’s historic: someone did it eons ago so now everyone does it.
Add 20% (or 50%). Also very common. Also cultural origins. Asking “why not 40%” results in, “this is the way we’ve always done it”. Should get these guys to talk with the 2x guys over some beers. It’d be fascinating.
Secret padding. This is where the team manager takes estimates from subteams, applies a secret number, possibly a different secret number per engineer or team, to arrive at the actual schedule.
Know other secret numbers? Please leave a comment. I love these.

What to do instead

The simplest, sanest step in the world, a step few people do, is when a project ends go back and review your estimates and compare against the reality. Put it up on a big whiteboard, sit down with a handful of your team leaders, and discuss two things: what factors explain the difference, and what smarter things you might have done to have a better schedule.

Even if you use a magic number, how do you know its magic is real? It’s pure faith unless you go back, study all the slips and adjustments you’ve forgotten about over the course of the project, and see how magical, or bogus, that number really was.

The best way to think about estimates is that it’s a culture, not a formula. It’s no accident better teams are better at staying on schedule. They ask better questions and care about things most people on projects ignore. What are those things? You discover them for your kind of projects by going back and studying. Focus leadership attention on the dozens of factors that contribute to scheduling, note some basic and fundamental things you missed, and consider applying that knowledge, as a team, the next time around. Don’t fight the last war, but make sure to learn from it.

Magic numbers can never work because every project is different. A riskier project might deserve a multiplier of 5x. A simple project might need no multiplier at all. The blind application of a near random number only serves to confuse everyone involved about why schedules work and why.

Also see:

Wideband Delphi. Every team should do this exercise every six months. It shows everyone it’s ok to discuss and share estimates instead of doing them privately and that estimates get better when they are a team effort. The social effects is the most powerful thing – the goal isn’t perfect estimates, it’s a team comfortable collaborating to make everyone better at estimating, as well as asking better questions about requirements, assignments and just about everything. Few are taught in school how to use their peers to generate better estimates and this instructs them.
Cone of uncertainty: A basic PM concept many executives/managers running projects have never heard of. If you buy it, it’s clear the unavoidable high variance of early estimates runs against the business cycle of many organizations, forcing big bets way too early, setting up bad schedules (and schedule guilt) from the beginning.
Exploring requirements, by Weinberg and Grause. The real problem of estimates is often the failure to generate good, design worthy, client comprehended project requirements. Who cares if you have a solid estimate for something no one actually wanted? The best, most realistic, least jargon-y and most in-the-trenches, book I’ve seen on this mystical process is Weinberg’s.

Have you used or have seen another magic number? Please leave a comment.

Posted Thursday, September 24th, 2009 at 9:46 am

in Management | 27 Comments » |

Patrick McDonough - September 15, 2009 at 9:51 am

Isn’t “Knuth’s Rule” sort of a magic number?

1) make your estimate
2) add one
3) take the next unit

Guess I will need one hour, hence say two days.
Or it will last three weeks, hence say four month.

I hear this a lot from coders. Btw is this really from Donald Knuth?

Scott Berkun - September 15, 2009 at 1:10 pm

Ryan: The golden ratio is funny in this conversation because it actually is a functioning magic number (much like Pi). ~1.61 is a surprisingly useful and common number in nature, construction and lots of other things.

Typhoonandrew - September 15, 2009 at 5:38 pm

I always liked:
A. (min time + (4x normal time) + max time)/6.

eg. It will take around 5 hours to do, but might be really simple and be 2 hours; but if it all goes to hell it might take 16 hours.

So (2+(5×4)+16) = 6.3 hours.

B. Lunchbreak.
Whatever the dev can do quickly instead of taking lunch.

Wil McClennen - September 15, 2009 at 6:00 pm

I have a magic number that I always (yes, that’s an absolute) when team members provide me an estimate of their work … it’s 1.

My job as PM is to provide inputs to the estimating process for my team – historicals, analogies, and the like. I may also help out with process if ‘actuals’ are lacking (as in, ‘how would you eat this elephant?’). Other than that, if it’s your work, it’s your estimate.

Now, if said team member looks like a deer in headlights at the thought of estimating a task, I may try to shuffle it off critical path (because there are other magic numbers I can use there).

Fun, huh!?

Justin Warren - September 15, 2009 at 8:19 pm

Given that it’s an estimate, you don’t have to be spot on. If your ‘magic number’ gets you to within the expected tolerance, isn’t that ok?

And if your magic number comes from looking at past accuracy of estimates, aren’t you just getting better at estimating?

If you have a bad slice in golf, and you compensate to get on the green, are you a worse player than someone without a slice who doesn’t need to compensate?

Payson Hall - September 15, 2009 at 9:36 pm

The best magic number I know is 6… if someone is assigned to your project “full time” and I get honest and credible estimates in person hours, then I assume 6 hours per day is a full time allocation. This accounts for non-productive time (expense reports, mentoring, coffee) and usually balances out sick days etc.

I too am a big fan of credible estimates that are based in data… in my experience the faulty assumption of a 40 hour work week is often the culprit for projects I’m reviewing.

Thanks for the thought provoking post.

Scott Berkun - September 15, 2009 at 9:46 pm

Justin:

If your “magic number” is based on reviewing past data then it’s not magical. It’s at least based on some evidence from reality.

I mostly wanted to criticize people who have faith in a number or formula but never examine if it’s actually effective or not, which I do believe is the large majority.

And for the record, in the golf case, yes, you are worse. You can never hit as far if you’re slicing then if your swing and timing are centered.

Scott Berkun - September 15, 2009 at 9:50 pm

TyphoonAndrew: Just fyi, your A is commonly called a PERT estimate, which is a kind of weighted estimation.

http://blogs.techrepublic.com.com/project-management/?p=120

Charles Seybold - September 16, 2009 at 12:25 am

If Tolstoy were a project manager, he might have said, “All magic numbers are magic in the same way”. In other words, it’s not that people are necessarily bad at making accurate estimates. Rather, the tools we use don’t give us much of a choice. They don’t account for one critical variable: uncertainty. Unless you can capture and manage uncertainty, every project plan is going to suffer from ‘magic numbers’.

This is precisely why estimation is seen as a ‘dark art’ — by asking teams to estimate their time in rigid, single points you’re basically forcing them into a corner. Inexperienced developers are often over optimistic in their estimates while more experienced developers tend to give themselves some extra wiggle room and sandbag their estimates. The answer? Ranged estimates (which is one of the features that differentiates our offering, LiquidPlanner, from the many other project management tools in the market). By enabling individuals to estimate their time in best and worst case scenarios you change the entire dynamic. Ranged estimates allow for an honest dialogue between team (more thoughts on estimation here: http://bit.ly/uXiMt).

You raise another extremely important point: the best way to get better at estimating is to go back and compare historical estimates to actual deliverables. Historical project data is one of the most valuable yet underutilized pieces of business intelligence a company has at its disposal. Unfortunately, most project plans are either tossed or teams are too busy iterating on the next deliverable to properly analyze their past estimates. One of the nice advantages of the new generation of online project management systems is that project data is never lost (or shouldn’t be).

Project visualization charts – such as the Cone of Uncertainty, among others — are valuable as they provide all project constituents with visibility across the entire project horizon. It’s an area I think we’ll be seeing quite a bit more innovation in as more project data becomes exposed.

Matt - September 16, 2009 at 12:49 am

We usually spend an hour or two on a good, thorough estimtate for a project’s up-front design work, then spend 30 seconds estimating development. Since pretty much any number we give will be wrong, we just write down 1.5x the design time and call it a day.

Funny thing is, it’s usually pretty accurate.

Bothering to reflect « testkeis - September 16, 2009 at 9:27 am

[...] @ 00:27 A friend just shared a link over at twitter to a blog post by Scott Berkun — The magic numbers of project management. The part on “What to do instead” just made me nod in agreement… especially at [...]

Michael Petruk - September 16, 2009 at 10:32 am

There are two ideas about the post:
1) Is it really impossible to estimate closer to reality or one can improve that skill?
2) Double the time for a client and halve the estimated time for a team.

My-Project-Management-Expert.com - September 16, 2009 at 1:55 pm

Great post which really hits the hammer on the nail!

Too many project manager’s believe there are magic numbers like, 20% contingency or 10% budget tolerance. The reality is that these are all figure in the air guesses, nothing more.

Things such as project cost estimation and contingency approach are learn’t with experience, not by wishfully using “magic numbers”.

Regards

Susan de Sousa
Site Editor http://www.my-project-management-expert.com

bryce johnson - September 16, 2009 at 2:45 pm

I’ve always been comfortable using an Optimistic/Realistic/Pessimistic model which is:
- How long do I think it will take
- What if Stuff goes wrong.
- What if stuff goes so wrong I have to do it twice.

Then I average the numbers.

I make sure that the last number is never equal to or greater then 200% of the first number. I also break down tasks so that the optimisitc estimate is never more then 8 hours.

PM Hut - September 17, 2009 at 12:53 pm

@bryce: Does this technique always work for you? I’m curious because I know that sometimes stuff can go really really wrong where even doubling the estimates won’t cut it. Also, can you explain “I make sure that the last number is never equal to or greater then 200% of the first number.” I’m not sure I follow why you have this rule.

I did publish this NASA article on the art of scheduling, it tackles the issue from a different perspective.

Captain Oblivious - September 24, 2009 at 2:08 pm

I once had a PM tell me that she doubled all my estimates… I told her I knew that, so I always cut my estimates in half before giving them to her… you should have seen the look on her face!

Chris Mahan - September 24, 2009 at 9:27 pm

My favorite magic number is this:

A 5 second job takes 5 minutes.

A 5 minutes job takes 5 hours.

A 5 hour job takes 5 days.

A 5 days job takes 5 weeks.

A 5 week job takes 5 months.

A 5 months job takes 5 quarters.

A 5 quarter job takes 5 years.

Although to be honest these 5 year jobs don’t quite make it to the end.

Neil - September 25, 2009 at 8:53 am

My previous team had a magic number: 4 hours. There was nothing magic about it though, as we had detailed data to back it up.

In an 8 hour day the amount of focused developer work that got done was always 4 hours. We used Scrum with task-level data reporting of time spent and could calculate at the end of every sprint how well people did. No matter how much big talk a developer gave at the start of a sprint about being able to get “5 hours done” or “schedule me for 6″, it always wound up being right around 4.

Of course, it could be the number caused itself to be valid, but regardless, scheduling for somehting other than 4 with this particular team always meant unfinished work at the end of a sprint.

Sarah - September 26, 2009 at 5:16 am

The magic numbers come from the project review. As a PM you learn from your project review that this person underestimates by x amount, and this person over estimates by x amount, so you adjust their estimates accordingly from historic data and past experience. More projects, more data, more ability to refine the process and the estimates.

Principles of Product Development Flow - review & retrospective « Positive Incline - October 6, 2009 at 9:49 am

[...] indispensible things that I’m simply not missing. And let’s face it: so often they’re rubbish anyway! Create [decentralized] systems to harvest the early cheap opportunities [...]

PH Lippel - November 3, 2009 at 1:32 pm

I had a research colleague/mentor named Bob who, when trying to get me to rationalize my own overly optimistic schedule estimates, said his graduate thesis advisor always multiplied Bob’s time projections by 2*pi. (Forgotten factors of 2*pi are quite common in early stages of a math or physics calculations.)

Random Thoughts on Estimation - December 15, 2009 at 12:53 pm

[...] they head towards wild guesses with some magic number applied, which may have some sense but not when used instead of real [...]