How long does it take to do a project? Software developers are asked this very question on regular basis. This is how every project begins. Why is it important? Because “time is money” and many software projects are priced mostly by time spent on the project. “We will take your project estimate in hours, multiply them by your rate in $/h, and we have our price.” Ask any consultant or IT staffer about that. Let’s look at estimates in the Real World(tm).

“Doing estimates? Software developers are hardly unique in this respect”. True, some other professions required to give time estimates too, but in my opinion the underlying process is not complicated enough, especially, if that work was done before countless times (e.g., in the case of lawyers). Sometimes there are unpredictable external events (e.g., in the case of construction industry). But the work itself is quite straightforward in most cases.

So programmers of all levels (from a “fresher” to PM) are required to give estimates. And they do. The evidence of quality of their estimates is immortalized in modern folklore. Anecdotal evidence suggests doubling (tripling, and so on) a programmer’s estimate or even switching to next time unit (e.g, 1 week ⇒ 1 month), or combining these approaches. It is frequently discussed topic and you can find a lot of references on the Net. Fine examples with helpful hints can be found here and here.

Of course, you can find smart books, which argue that this is a part of project management “science”. There are many techniques to do it. Some of them are listed in this Wikipedia article. These methods are good, they do work in certain cases, but at the end of the day you still have to make some guestimates directly or indirectly. When they don’t work? From my experience fancy methods rarely scale down (small projects, teams of 1-3 programmers), usually don’t scale up well (huge projects), and don’t work for “tricky” projects, where design is the biggest unknown.

Smaller projects

What to do with small projects? The only viable solution is to design the damn thing, split it up by tasks, and estimate tasks on individual basis. Clearly a good design can be a costly undertaking. Fortunately in can be done in iterations. A quality of produced estimate will be proportional to the level of details of your design. A general design can be used to produce an OOM (order-of-magnitude estimate in PM’s jargon). Sometimes it’s called VROOM (very rough OOM). A detailed design can be used to produce a pretty accurate estimate. But we know better than to rely on detailed design.

It all sounds simple, but the devil is in details. In this case it is in “split it up by tasks” part. The real reason for programmers producing unrealistic estimates is how they define tasks, or what they consider to be “tasks”. Usually programmer comes up with a time estimate reflecting how long it will take to code the piece. He “forgets” to include thinking before coding (!), testing cycles, writing documentation (if your team has a dedicated technical writer, you should schedule meetings between her and programmers responsible for different pieces of code), meetings with programmers, who provide some code he uses, meetings with programmers, who use his code, joint debugging sessions, team meetings, and so on. Frequently programmer doesn’t even consider “non-programming” tasks.

But how to estimate individual tasks? You can either split them down to more atomic tasks, or derive their cost from your own experience. In fact a programmer “sees the task” (makes a detailed design of a simple component in his/her head) evaluating the cost. Now this is a fine point missed by many: different people can “see” tasks differently. If one person produces an estimate and another one implements it, be ready for a formal detailed design document, otherwise you are in for some nasty surprises in the course of the project. Make sure that your team supports the estimate, and “makes good on promise”.

Scary story

Does it look obvious to you? Let me share a story from the Real World(tm). Some time ago I interviewed ~20 people for a project manager position in one of the big companies. I explained that the position involves producing a lot of estimates for a maintenance work (modifications, enhancements, new additions) for existing applications (BTW, regulated by the government — one more issue to consider). While technical part is covered by a team leader, PM has to represent the team in front of management, clients, other teams, and so on. I asked everyone a simple question: “You were sent a feature request. You have to provide an estimate. Explain how you would do it.”

I expected them to mention some estimation methodologies, or tools, but their answers shocked me. Majority answered: “I will base my estimate on my experience”. What experience? Nobody had 100% relevant experience judging by their resumes. One answered: “I will ask you to help me”. Yeah, right, like I have nothing else to do. The rest has provided equally nonsensical answers. Only one guy answered that he will ask his developers and his team lead to advise him on the estimate. Incidentally it was the formal procedure mandated by the company rules, and the common-sense answer I was looking for.

If you think that I interviewed some random guys, think again — all of them were experienced PMs (!), some of them were certified (!), some of them attended prestigious schools (!).

Bigger projects

Let’s go back to estimation. While splitting tasks recursively you will soon realize that their number grows fast like a snowball. The more programmers you have involved in a project, the more errors you introduce in your estimate. Same goes for dependencies on external projects, bureaucratic expenses, and other non-technical issues. How to deal with them? The only way to combat such complex systems is to use statistics. Basically it means that you produce estimates using historical data for your team, or your company, or your industry. Unfortunately in most cases this statistics is unavailable or nonexistent. What to do now?

While there are several ways to go about it, the solution, which worked for me, is a product called Construx Estimate (free registration is required, so far I didn’t have any spam from them). It has five good things going for it:

• It is free.
• It is a child of Steve McConnell, the guy who wrote Code Complete, Rapid Development, Software Project Survival Guide, Professional Software Development, and of course Software Estimation.
• And it is free.
• It really works.
• Did I mention it’s free?

(Note: I am not affiliated with Construx in any way.)

I was skeptical when I decided to try it for the first time. And it did produce wrong results. But soon I realized that I didn’t turn all knobs. After fine-tuning it consistently produced right results.

Construx Estimate uses some well known algorithms (SLIM, Cocomo 2.0, Monte Carlo simulation), and comes with statistics organized by project types. Download it now and play with it. It is a small program, which can be explored in 15 minutes. Some helpful hints:

1. It doesn’t produce good estimates for small projects. In fact it assumes that your project has >=5000 lines of code equivalent, >=6 month long, requires >=18 staff-month effort, and uses at peak >=3 people — at least two of these criteria should be met.
2. To make your estimate more realistic, use productivity drivers (Estimate ⇒ Set Calibration Type ⇒ Use Productivity Drivers). It allows you to describe your product, your project, and your team in details (Estimate ⇒ Edit Calibration).
3. To improve results use module-by-module estimate (Estimate ⇒ Set Project Scope Type ⇒ Use Module-By-Module Estimate), and define your modules separately (Estimate ⇒ Edit Project Scope). You can use different coarseness of information on your modules.
4. Check out a brochure, which details your estimate (View ⇒ Outputs). It makes it easier to convince clients that your estimate is sound. You can print it and add to formal documentation. I print it to PDF.

Epilogue

Of course there are some projects, which are hard to estimate using simple methods, or smart programs. If your project involves a lot of experiments before making design decisions, or requires some deep theoretical thinking (typical for math- and science-heavy programs), you are out of luck. I hope your clients/bosses will realize that any estimate has a certain margin of errors. The only precise “estimate” is available after the project is finished. Huge projects may require a custom approach as well. But 99% of projects can be estimated without major efforts.

Now we have our man-months estimated. How to convert hours in real work? Next time: productivity of programmers.