Project Estimation
from Martin L. Shoemaker Consulting

Here's a classic conversation:

Manager	Project Lead
So how long will it take?	I don't know.
What do you mean, you don't know?	I'll know when the job is done.
Well, you must have some idea.	If I did, I'd tell you.
Well, just give me a ballpark figure.	I can't.
Why can't you?	Because...
...you don't know. You said that. But can't you give me a rough guess?	Ten years, ten billion dollars. It won't be worse than that.
Very funny. Look, management wants me to fill out this report; and one of the fields in this report is when the work can be delivered. If I don't fill out this report, my boss is going to get on my case.	I'm very sorry, but I can't help you.
Look, just give me a date. Any date, just so I can fill out this report. I won't hold you to it...

And to be helpful (or just to brush off the manager), the project lead gives in and gives a date. "After all, they won't hold me to it..." And the next day, that date (or worse, an accelerated date) has been published in the annual report, and leaked to the press, and set in stone.

Who's to blame? Everyone:

• Top management made a serious mistake if they accelerated the date. This tactic -- setting impossible goals -- is seen as a way to motivate people to do the most they can do. It's even taught in management schools. Unfortunately, it only works with certain personality types; and the average development team doesn't fit the type. Most developers are motivated by winning: if you give the team a barely possible goal, they'll be highly motivated to attain it; but as soon as they believe the goal is impossible, they'll find another game where they can win. If top management wants to motivate people, they need to understand the limits of the possible. That means they need a reliable estimate of the size of the project; and they need to understand the pieces that make up that estimate, so they can evaluate trade-offs to meet their business goals.
• The manager made a serious mistake by asking how long the project would take, instead of how large the project was. Given the size, it's the manager's job to determine the allocation of resources and the resulting schedule. And that size comes in the form of an estimate.
• The project lead made a serious mistake by trying to ignore the question. While size and schedule and resources aren't nearly as much fun as new technologies and cool code, they're the key elements in managing the business. Top management and the manager aren't wrong to ask the question; but the project lead gave the wrong answer. The right answer isn't "I don't know"; it's "I don't know, but I'll have an answer in two weeks." Or two days, or two months, or whatever is appropriate for the size of the project. The project lead needs to provide an answer in the form of a well-thought-out estimate.

Estimation is a key bridge between the requirements and the schedule, and it's not something you can do off the top of your head. A good estimate requires some amount of up-front analysis and design, followed by application of some specific estimating techniques. This process takes time up front; but it's time well spent, because it lets you know what's possible and keeps you from committing to disastrous schedules.

But what if you have no experience with detailed software size estimates? That's where Martin L. Shoemaker Consulting can help. We can teach you the basics of estimation, and show you the strengths and weaknesses of various approaches. Then, when you select an approach (or perhaps multiple approaches), we can help you to derive an estimate for your system.

For more information on project estimation, please contact us.

 Copyright © 2003 by Martin L. Shoemaker