For Technology Projects, Multiply by PiBy David Strom | Posted 2008-04-01 Email Print
Re-Thinking HR: What Every CIO Needs to Know About Tomorrow's Workforce
The Strominator examines the rule of "n" for IT project estimation and completion.
I have been talking to a lot of IT managers of some fairly large organizations lately about managing their assets. One of them mentioned to me his rule of π, which I thought was worth sharing. As in the Greek letter that is a geometric constant of 3.14159. (I used to know more decimal places, and yes, I was one of those kinds of people back in high school.)
His rule is simple: Any time a consultant or an employee gives you an estimate of what something costs or how long it will take to complete, he multiples the estimate by π. If someone says a project will take two months, it really will take a bit longer than six. And so forth.
I got a good laugh out of his π rule, but then I got to thinking. Why are IT people so miserable at estimating costs and time to complete work? Maybe they are the worst group of people—certainly I’ve had general contractors who weren’t the best at this, but I guess I should consider myself lucky that they were only a few days off schedule rather than by such a huge factor.
Sure, we’ve all read about the mythical man-month and other works that claim the more developers you add to a project, the longer it will take. But this isn’t just about that.
Maybe it’s because IT people really want to serve their clients and set themselves up for unreasonable expectations right off the bat by underestimating their work product. Or maybe it is because the work product is so ephemeral to begin with. I mean, it isn’t like a construction crew trying to rebuild a bridge or erect a new office building.
I guess I am overly sensitive to this because so much of my job revolves around hitting particular deadlines that are very definite. If I miss one, someone else along the editorial production process has to make up the slack, because the magazine has to be printed at a specific time or the article has to be posted online for a particular moment. I am proud to say that I hit all of my deadlines except for some unusual circumstances.
But when it comes to IT projects, a deadline seems to be more of a guideline than something hard and fast. The report isn’t done? Oh well, we can wait another week; not to worry. Or how about the opposite: Your boss gives you an artificially early deadline, you actually deliver the work on time, and then he tells you that he was really not counting on getting it today and will be too busy to review it until next week. Boy, how does that make you feel, after you moved heaven and earth to get the work to him as agreed?
Sure, things are sometimes out of your control. People make mistakes, code has bugs, equipment takes longer than anticipated to configure, the dog ate your homework, etc. Some of the delay can be explained by developers who want to add “just one more feature” before they lock down the code and send it to production. Did anyone ask them to add the feature? Probably not; they just did it on their own initiative because it seemed like a good idea at the time.
When I taught computer networking in high school, believe me, I heard it all from students who were late handing in their homework. (And, you should know, I didn’t let my students slide. A deadline is a deadline, after all. Most of them made that mistake only the first time, and then cooperated quite nicely afterward.)
If we’re going to move toward more realistic estimates, we have to do a better job of anticipating the problems with our projects, and we also need to be able to communicate up and down the line when we spot the first hint of delay or feature creep.
Think about the rule of π the next time someone asks you when you will be done with something you’re working on, and try to give it some thought before you commit.