Assuming that you've joined me on the first part of our estimating adventure, I can only assume that you're now sitting patiently with spreadsheet at the ready prepared for the down and dirty details of delivering a killer estimate for your next killer app. So tell the truth, how many of you actually called your bookie? Don't gamble, you say? Ah, but you do, every time management asks how long a project will take and you give them anything but a devastatingly detailed set of numbers.
Let's start with the design that you produced in whatever window of time you were given to architect your new project. If you have lots of detail and a well organized stack of diagrams, you'll certainly appreciate it as the system starts taking shape. However, if the best you could come up with in the time allotted was a few cocktail napkins you're still in good shape, as our first task is partitioning. Besides, cocktail napkins show that you're a seasoned veteran and look great on your resume.
Software partitioning in and of itself is actually a part of system design. However, where the rubber meets the road is the point at which a real, live programmer is given tasks to accomplish, and this work is typically distributed along those partition lines. Assuming that you have more than one programmer on the team, the first step in getting the project rolling is to divide up the coding to be done amongst the masses. If you're heading up this development effort, your first step is to turn your developers loose on the estimating process and let them get their numbers together. You'll have more work to do later, but for now let's take the process of conjuring up numbers from the perspective of an individual programmer who is now responsible for a part of the system and accordingly has a photocopy of the upper left hand portion of the cocktail napkin.
Your first task will be to do a little partitioning of your own. Start with the highest level subsystems that make sense for your assignment. You may or may not already have a fair amount of this from the design process but even if you do, your next step is to break those components down into progressively smaller and smaller pieces until your entire assignment is now represented as a collection of tasks that will each require only a handful of methods to implement. I don't have a magic number for what the maximum amount of methods should be for each chunk of work. There isn't one. The next step will quickly give you a feel for this, however. By the way, while I realize that many live in an object oriented world these days, not all do. For this reason I speak of methods rather than classes as it all comes down to methods of one sort or another in the end anyway.
Now that you've thought your way through to this level, you should be in a position to start assigning time estimates to each of these small, individual chunks of work. There are a few rules to which you must strictly adhere in this process, however, and it may require a small adjustment in your way of thinking. First, all individual time estimates are given as the actual hours that it will take to get the task coded. Calendar time does not matter at this stage, only raw hours. Timelines come later, and are the responsibility of the project leader.
This is a good time to fire up that spreadsheet you brought along. What we're going to do next is list the amount of time that it will take for you to implement each individual chunk of work. At this level the absolute maximum amount of time that any bit of work should take is 4 hours, and that is an extreme to avoid rather than an average unit of effort. You should have your work broken down to the point where each piece you review will range from half an hour to a couple of hours. 4 hours is the ceiling. If you exceed it, break your chunk down into yet smaller parts until it falls within this range.
Don't factor in any arbitrary slack whatsoever here, try to be as realistic as you can. We're shooting for total accuracy, and you'll get better at it as you go along. The whole point of breaking it down to this level is to have a task so small that the effort involved will be readily apparent. Think about it for a moment. You've been coding long enough to know how long it takes to lay out a dialog box. You understand the amount of effort involved in declaring the variables and access routines, how to get data into and out of the controls, how to do the necessary validations, etc. When someone asks you how long it will take to do any one of these simple tasks, you'll almost always be correct to within ten percent. Here you're comfortable and accurate. Consequently, here you stay.
The problem with estimating a software project, or any major portion of it, is that the numbers are usually calculated from a high level perspective. As any battle scarred programmer knows, the devil is in the details. Everything looks straightforward in an overview. Where the sparks fly and things start getting complicated is in the low level implementation. This is where the unforeseen problems suddenly appear and simple tasks become complex. This is also the level that is almost never fully considered in software estimating, typically because management thinks there's just no time for this much detail. While that may seem true in the beginning of a project when everyone's in a hurry for you to start coding, I can assure you that the extra time spent estimating at this granularity is only a tiny fraction of the time your project will miss the deadline by without it. Pay now, or pay later. Later is worse.
This is a lot of work and is about as tedious as it gets, but it is exactly this level of detail that will ultimately drive your success. The numbers at this stage are critical as all else is built upon them, so give each individual estimate very careful consideration. Inevitably, there will be some things that you've never done before and as such you just won't know how long they will take. Break these down into the smallest chunks that you can manage, take a little extra time looking over the API documentation along with any other resources you can scare up, and take your best shot at it. It's okay to be a bit conservative, but remember, you're shooting for accuracy.
When you're done with this phase take your individual tasks, gather them together into logical groups and set up subtotals for each group. Here again, granularity is important for what follows next. Make sure that none of these subtotals are greater than 40 hours. If they are, reorganize your groups by breaking them down further.
Up to this point, we've been striving for a legitimate representation of how long each task will take. Unfortunately, in programming things don't always go as planned and it's sheer folly to ignore this. Consequently, we now enter a line beneath each of our subtotals titled, "The Unexpected - 10%" and calculate this number accordingly as 10 percent of the subtotal. Next add a line for the total of each group showing the subtotal plus the amount for the unexpected. Finally, set up a cell to hold the grand total for all these totals, which will be the bottom line number of hours that it will take you to do your assigned portion of the entire project.
Here's how it works. By keeping your individual estimates in the range of half an hour to 2 hours, your exposure should you encounter a problem is small in terms of time. Because the amount of each individual estimate is small, the amount you get behind will also be small and thus easily recoverable should you make a mistake or have some bad luck. The vast majority of the time, if you were realistic with your individual estimates, you'll be pretty close or even right on the money. Some you'll be a little under, some a bit over. Sometimes you'll even get lucky and finish a particular task significantly ahead of your estimate. You'll find that the 10% contingency, coupled with those tasks you completed earlier than planned, will in all but the most extreme cases be sufficient to keep you on track when you hit a snag. You'll also find that as you start training yourself to think in this amount of detail your individual task estimates will get more and more accurate. As in many other areas of life, practice makes perfect.
Having completed your estimate, you now turn it over to the leader of the project, who must bring it all together and give management a delivery date. This would be a good time to duck out the back door and grab some lunch. Project managers don't like this stuff any more than we do, and they're also the ones who have to face management.
The programmers have been estimating in actual hours. Management wants a calendar date. Before you can calculate the number of days your project will take, you need a constant to represent the number of coding hours each programmer will get in per day, and believe me, it ain't 8. This will be between 5 and 6. If you work in a heavy bureaucracy with lots of meetings, paperwork and similar distractions, go with 5 hours per day. However, even if you work in utopia where you code all day and management shows up only occasionally and just to throw raw meat over the cubicle walls, don't count on more than 6 hours of coding per day. The time gets chewed up one way or another and any number greater than this is just asking for trouble.
Now that you're able to calculate the total number of development days, whip out a calendar and check for holidays. Also make sure you get the vacation schedules of all the members of the team and factor that in as well. Will you put the project through a QA pass after you're code complete? Do documentation and training tasks come after the coding's done or during the process? Be sure to factor all these in as well. If you're responsible for the tech writers, make sure they give you the same kind of detailed estimate the programmers did and apply the same number of writing hours per 8 hour day as you did for the programmers with their coding.
When you've added it all up, build a spreadsheet that has the group totals from your programmers and tech writers, and build a summary of hours for management. In the final estimate that you provide, include this summary and show how you calculated the days based on your 5 or 6 hours of coding per day constant.
Be prepared to take some flak and have an argument about less than 8 hours of coding per day but stick to your guns, or you're headed for heartbreak. Management typically has a rather naïve view of how much coding gets done during a day, and if you tell them that only 6 hours a day is spent on this they'll immediately ask what the heck they're paying for in the other two hours. You'll have to patiently explain the cumulative effect of meetings, administrative overhead, etc. and they'll be skeptical. However, once you start demonstrating that you can hit your deadlines with regularity, you'll find that in the future when you're introducing an unfamiliar management concept they'll be sitting on the edges of their seats listening intently to your every word. Everyone loves a winner.
Top 