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.
What you have written deserves a book or two, hardly a blog post…or response. Each section could be parsed to some benefit.
How long would that take? Well, that needs a breakdown of What would that take? Some immediate organization, some thoughts on what needs researching, some thoughts on where the research would lead, some idea of what assets will be available to start, and what assets will be required post-research. Some idea of the historical precedent is needed – will the corporate desire to get it ‘right’, to some high standard prevent a target from being reached that might be ‘good enough’ for others? How much energy is available to get any newly found requirements the permissions required to follow-up or utilize?
Add a percentage for false leads. Add a percentage for tail chasing. Add a percentage for administration. Add a percentage for late coming bright ideas.
Goodness. My response is getting out of hand.
I had a good experience talking to the chief engineer of a project on day, asking what the project would take. I got a general outline and the usual ‘a couple of days’ and ‘a few lines of code’ answers to the time question. The next day I went back and asked the ‘what does it take’ question about one line of the general outline. Got several more particulars. Did the same thing in short bursts for daze…days. Finally, a usable answer was available. And still, all the vagaries of the research and development unknowns manifested themselves.
Try that with an artist who has to develop a piece of art. R&D ain’t so obvious a need, but it is there.
Peer pressure variants (If I don’t do it, the responsibility lands on my co-workers, or Gee, I’ll look like a fool if I hand in something substandard), money, glory, fear, deadlines that can’t move (the convention starts on this date and the product must be shown, working and ready to buy online), deadlines that can shift (the convention starts on this date and the product must be shown, and the main parts need to be working.)
A book or two, perhaps a philosophy.
This is so true it hurts. It’s not just IT projects.
I’ve been burning the midnight oil, the candle at both ends and my eyes out trying to meet self-imposed deadlines to produce a set of market documentation for a client who would in fact have been perfectly ok with a longer lead time.
Why the self-delusion? Partly, it’s misguidedly aspirational (I will be super-efficient on this project as I never was before); partly it’s wilfully ignoring the fact that thinking about something before you do it is part of the process and takes time; and for the most part it’s that I hope I’ll work faster if I have a looming deadline.
Great article.
Actually I was pretty good at estimating IT projects. Could hit the dates accurately and the budget. I always figured out the actual budget and put in a 10% cost overrun. Why? The unknown always came into play. Even did an ISO 9001 very large scale project which hit the date and budget. It was bottom up and then we locked the date. When the date started to slip we negotiated features (added some, dropped others) and hit the date worldwide for delivery.
The key is working with a team who is not afraid to say what is happening and have weekly bull sessions. Market windows are key factors and missing them puts you in a world of hurt.
In the early days before I figured this out I had a formula: multiply by 2 and take the next unit of measurement. So a 2 week project = 4 months. Pretty cynical.
Another reader writes:
My take on this from my time in IT is that deadlines were fuzzy because they were allowed to be. I met my deadlines because I always assumed I had to but other managers were often allowed to routinely miss deadlines with little consequence.
I once had an IT software manager tell me he had the best job in the company. He and his team could spend six months at a time writing requirements with the client for their next project. Then, before any real volume of code was written, the requirements were changed by the client or the project dropped entirely and they could begin again. He told me he never had to actually deliver a working application.
He did this for the better part of 5 years…
Another reader writes:
it is ridiculous that we consultants are so miserable about time estimate. i’ve never been on on a project that’s met it’s time estimate. most have exceeded the time line miserably. a very few have have made it within what i would consider a “normal over- extension”. when that does happen it’s normally been because my consulting group has to deal with a way out of control database or some sort of system outage beyond what the client company would ever admit or even know about.
data management has been the wild buffalo. just as my group is implementing some new functionality in Java on a client’s web site, the data people inform us that “there’s a new installation of Oracle going in on the weekend” – which shuts us down for 3 days through the following Wednesday.
another buffalo is the “change requirements by appearance” approach of so many on the business side of management. here’s what i mean:
originally, the requirements on a project demanded that all users enter their user name, email and password; all of a sudden management says, “all we need are the user name and password. trash the email as a requirement.”;
where do we put the email;
reply: “on the user’s info page”;
there never was a user’s info page in the requirements;
the job continues for 2 more weeks as management decides what to put on the user info page and where to store it;
if i feel cynical that week, i could sit back and wait for the more changes to come. but since i simply cannot be the wisest monkey in the jungle, i figure i better befriend somebody in management to help figure out what’s going on and become part of the decision making process. i then help management come up with an ad-hoc process that solves this problem, management feels good about itself, and i complete the project with a happy client.
thanks for the article. “the rule of pi” is a good one and pretty much matches the real time spent on the projects i’ve been on.
I just saw this article by Jeff Atwood. For my part the biggest work-inflator is “I didn’t really know what I wanted till you delivered what I asked for”.
Pingback: One down › guys like dolls