I have been doing some seminars on IT asset management for a client and as a result I have been talking to a lot of IT managers of some fairly large organizations. One of them mentioned to me his rule of π that 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: anytime 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 π. 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 have had general contractors who weren’t the best at this, but then 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 the mythical man-month and other works talking about how the more developers you add to a project, the longer it will take. But this isn’t just about that.
Maybe it is 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 is more 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, when 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, does that make you feel like you really 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 my 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 for production purposes. Did anyone ask them to add the feature? Probably not, they just took it on their own initiative because it seemed like a good idea at the time.
When I taught high school computer networking, believe me I heard it all when a student was late with his homework. (And you should know, I didn’t let my students slide. A deadline is a deadline, after all. Most of them only made that mistake the first time, and then cooperated quite nicely afterwards.)
If we are going to move towards more realistic estimates, we need to do a better job of anticipating the problems with our projects, and also need to be able to communicate up and down the food chain when the first hint of delay or feature creep hits.
Think about the rule of π the next time someone asks you about when you will be done with something you are working on, and try to give it some thought before you commit.
- ► 2010 (39)
- ► 2009 (55)
- ▼ April (4)
- David Strom
- David Strom has looked at hundreds of computer products over a more than 20 year career in IT and computer journalism. He was the founding editor-in-chief of Network Computing magazine, and now writes for Baseline, Information Security, Tom's Hardware, and the New York Times.