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