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. Typically the origins are mystical: we use this number because we’ve always used this number. That’s not a good basis for doing much of anything.
Here’s the list of the common ones, plus some better 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.
- Pad estimates by 20% (or insert magic number here). Asking “why this number?” typically is answered with “this is the way we’ve always done it”. Should get these people 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 compare your estimates with what actually happened. Put it up on a big whiteboard, sit down with a handful of your team leaders, and maybe a friendly client, and discuss two things:
- What factors explain the difference between the estimate and reality?
- What smarter things could you have done to have a better schedule?
Unless you ask questions like these your estimates are still going to be guesses. It’s only when you study all the slips and adjustments you’ve forgotten about over the course of the project that you can see how magical, or bogus, your estimate was. Then you learn from your estimates, instead of ignoring them.
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 of each other 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 attention on the assumptions made in the original schedule, note the (kinds of) things you missed and apply that knowledge, as a team, the next time around. Don’t fight the last war – the next project won’t be same as the last – but make sure to learn from it.
Magic numbers never rarely 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
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?
I’ve heard that one before – good one. But didn’t know it (may have) come from Knuth.
I had a prof who always liked to apply the golden ratio. http://en.wikipedia.org/wiki/Golden_ratio
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.
Also check out the nice write-up Joel posted a while ago: http://www.joelonsoftware.com/items/2007/10/26.html
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.
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!?
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?
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.
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.
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
If Tolstoy were a project manager, he might have said,
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.
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.
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
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.
So I guess I also use the PERT technique. :-)
@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.
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!
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.
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.
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.
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.)
For me, I take into consideration of who’s on what, their experience, and past performance. Are they new to the task? Are there examples they can follow? Is there anyone to help them out if they need it? For me, it’s not just a math formula. There’s an art to it as well. And sometimes it works out well. Sometimes not so well. But learning that I’ve missed a factor is good.
Jesus rule: add 10% for “Jesus, I can’t believe we forgot about that”
https://twitter.com/odannyboy/status/346044717701677056
I once worked for a company that used historical data and a complex algorithm to get better estimates. They were using FogBugz Evidence-Based Scheduling: http://www.fogcreek.com/fogbugz/evidence-based-scheduling/
It works by collecting data about he accuracy of the estimates of each developer and using algorithms to forecast more precise deadlines.
I think it’s a bit mental! ; )
Too much accuracy always lead to false expectation. Project managers love precise numbers, but it’s just another bias, a way to fight the uncertainty with fake security. And then after getting estimates precise to the hour, they multiply by totally random magic numbers! It’s often really a tragicomic theatre.
Also, what I don’t like about magic numbers in general is the lack of transparency towards developers. It feels patronising.
If the estimates are always wrong, then I believe there is a lot of value in sharing the data with the team, so that everyone has an opportunity to learn and improve.