(c)2007, Dave W. Smith

As software developers, and managers of software developers, we have a reputation for making pretty lousy estimates. Part of that rap is unfair; many times the requirements that we’re asked to provide estimates for are vague, and change as the work progresses.

But a large part of that reputation is true. We make lousy estimates, and we don’t seem to get much better as we go. One problem is that the feedback loop between the estimate and the achievement is often long. When you don’t begin working on a task until weeks or months after you estimate that work, the original mental context has been lost, making it difficult to use feedback to learn.

Here’s a simple way you can begin to shorten that feedback loop and put yourself on the track to becoming a better estimator. All you need is a stack of 3×5 cards, a pen, and a watch or clock.

It works like this: Keep a few 3×5 index cards in your pocket or within reach. Before you begin a task, which could be a task for a project at work or a task at home, pull out a card and jot down a short description of the task on the front of the card. Short is good?you only need enough to recognize the task, which helps if you interleave work on several tasks and thus will have multiple active index cards.

Next, take a moment to think through what “done” means for the task, and what you need to do to get there. Now estimate how many hours it will take you to complete the task, and jot that down on the card. If you’re uncertain, write down a time range (e.g., “Est: 1/2″, “Est: 5-6″).

This process should take less than a minute. It it takes longer, or you can’t first the task description on the card, or if your estimate is larger than 8 hours, take it as a hint that you need to consider breaking the task into smaller pieces. Rip up the card, and start over. One of the secrets to better estimating is admitting when you’ve bitten off more than you can chew, and then backing off to take smaller bites.

As you start the task, turn the card over and note the date and start time on the back. If you break off from the task, or get interrupted, note the time, or at least make a check mark for each interruption. Seeing how often you get interrupted may surprise you, and the data can be useful when you look at it later for patterns.

The back of one of my recent task cards (for a writing project) looks like this:

   5/30/07    6/1/07
    ------   -------
      9:00      9:15
     11:30     10:05 phone

               10:10
               10:45

When you finish the task, total up the time and write an “Actual:” number below the estimate on the front of the card. And, while memory is still fresh, take a moment to reflect on what happened. If your estimate and actual match, congratulations. More likely, you’ve earned an opportunity to improve. (Even if your estimate was spot-on, you still have an opportunity.) Ask yourself: “What happened? What parts did I forget to estimate? What went harder or easier than I first thought? What could I remember to consider the next time I’m estimating a task like this one? What about my environment interfered, and how can I either change that or account for it in future estimates?”

File the card away. If you keep a journal, jot down your thoughts.

After doing tracking task time for a few weeks, you may notice patterns and recurring themes. Are you getting interrupted more at some times of day than at others? Are you better at estimating certain sizes or types of tasks? Are your actuals closer to estimates when you’re juggling fewer tasks? Noticing patterns in your own work will give you practice in noticing patterns in team projects, which improves your ability to help with team estimates.

Tracking estimates and actuals has shown me that I have several distinct patterns of consistent underestimation. When estimating a writing task, I often underestimate how long a rough draft will take to revise. Now I break out separate tasks for drafting, revising, and final edits, and double my gut estimate for revising.

Tracking your time can be a simple practice, and can be remarkably revealing. Give it a try.

convert this post to pdf.

©2003 Johanna Rothman www.jrothman.com

Jim, a new project manager, struggled to define the project?s parameters: schedule estimate, people estimate, requirements outline, and necessary capital equipment. Jim proudly walked into his manager?s office, and proceeded to walk through his project plan discussing these numbers:

64.1 calendar weeks

12.125 people

ROI (return on investment) of 7.5 months

Jim?s manager, Dave, stopped him, smiling, and said, ?So, Jim, where?s this .125 person coming from? And what?s .1 of a week?? Jim was a little stumped, and said, ?Oh, I guess we?ll borrow someone else. I thought you?d want to see a project plan with the fewest number of people. One-tenth of a week is part of a day.? Jim?s manager said, ?Well, we only have whole people, so I need a plan with either 12 or 13 or whatever you think the right number of people is for this project. And, while you?re at it, although I would love to plan a release for a Monday at 9:37am, we both know that?s not going to happen. Please work up an estimate that?s more accurate, but not as precise. And, while you?re at it, show me our options?how many people for how many weeks, giving me ideas for how we would staff a shorter project with more people and a longer project with fewer people.?

Precision is the exactness of the measurement, the number of decimal places. Accuracy is how close you are to the estimate. When I worked with robots, precision meant how close to a specific place in space we could move the robot arm once. Accuracy meant how many times we could make the robot arm move to that precise place. Jim?s estimate was certainly precise, but estimates are more useful when they are accurate, close to the mark. Projects are composed of numerous predicted estimates, so we can?t expect accurate estimates, except to an order of magnitude. Over time, you can learn how to estimate so that your estimates (predictions) are close to your actual schedule.

When you talk about estimates, you?re in much better shape if you choose accuracy (how close you are to the prediction) over precision (exactness). As you move closer to accomplishing milestones, you can re-estimate with greater precision.

One way to discuss a schedule estimate is to deal with a range. Jim could have said, ?I?ll need 13 people for about 64 weeks. Or, I can do this project with more difficulty if I have 20 people for about 50 weeks. Or, if we take out this specific performance requirement, we?ll need 18 people for about 48 weeks.?

Each of the ?abouts? in the previous sentence exists for accuracy. Schedule estimates are just that, an estimate. In my experience, putting an ?about? in front of a schedule estimate is more helpful than a range (?62-65 weeks?). I?ve met too many senior managers who don?t hear the second number, just the first. When I use an about, I can choose a number that makes sense to me to use to senior management.

However, some of you work for managers who prefer a range of estimates, with a confidence for each point in the range. This is particularly helpful if you use a graph to explain your confidence. (see Figure 1.)

Figure 1: Estimates: Precision vs. Accuracy

The graph is a vehicle for starting the discussion about why you have how much confidence when. You can explain why you only have 50% confidence that you will meet the 3/1 requested release date, and you can explain why your confidence improves over time. With this graph, you?ll especially want to explain the difference in confidence between 6/1 and 7/1. The project manager who generated this graph was concerned about the amount of rework (problem finding and fixing) at the end of the project, and wasn?t absolutely sure the project team could finish the rework for 6/1. When he explained how the last three releases had used more than the planned four weeks, his management understood why his confidence level was less than 100% for the 6/1 date.

If you have a sponsor who says, ?Just give me a number, and give it to me now,? you have numerous choices about the date you provide. You can choose a date somewhere in your range, depending on how risk averse you are. Frequently, sponsors who need dates without a discussion of estimates really do want just a date you can promise, not the first possible date the project could be ready if Murphy?s Law didn?t come visit your project and all the planets were aligned. If your sponsor is not willing to use the date you provide, you?re dealing with the ?Bring me a Rock? game. If you have a sponsor who appears to not be willing to consider why you don?t have a date, you have several options: make an appointment to talk about project schedule estimates; discuss your sponsor?s concerns and what matters to your sponsor; or find a new sponsor or new organization.

Choose some technique, ?about? an amount of time, dates with confidence attached, or a date in the middle of your range, to help your project sponsor see that the schedule or the budget or the ROI, or whatever number you?re discussing is an estimate.

Be precise at the end of a project, when you file your project information, and manage the data that was part of the project?s outcome. In the meantime, be as accurate as you can, by using approximations, ranges, and ?about?. Jim now works for accuracy at the beginning of his projects, and precision at the end.

convert this post to pdf.

©2004 Johanna Rothman.

Project work estimation has three components: the initial first cut, commonly known as a SWAG (Scientific Wild Ass Guess), tracking the estimate against the actuals, and using the schedule to see what’s happening in your project.

If you’ve been assigned project estimates, or if your project estimates aren’t particularly close to reality, don’t fret. Try these techniques to estimate and learn about your estimates.

Part 1: Create an Initial Estimate

If you’re a project manager, you probably try to estimate the work at the beginning of the project, even if you’re assigned a project end date. Sometimes, senior managers have trouble hearing what you’ve said in your estimate. I use one of these three alternatives to creating estimates for the entire project:

1. Provide a date range for the estimate: “We’ll be able to release between May 1 – June 15.” Some senior managers can’t hear the second half of that statement; they only hear May 1. If you work for a manager like that, try either of these other two suggestions.

2. Use the word “about” to describe the precision of the estimate: “5 people for about 9 months or 10 people for about 6 months.” You haven’t described an end date, but you have explained the resources you’ll require.

3. Provide a confidence level to describe the range of dates: “I have 90% confidence in June 1 and 100% confidence in August 1.” In my experience, even the managers who can;t hear the “between” estimate can hear my confidence levels.

Once you have a gross estimate at the beginning of the project, you can drill down and create estimates for each of the project components. Whether you try to create precise estimates, or choose to use slack buffers to deal with incomplete estimates, you will have some project estimate.

The problem with estimates is that they are guesses. They’re the best guesses we can make, as good as we can make them, and they are still guesses. As the project unfolds, you will be able to acquire feedback on how well you estimated and to know how to update your estimates, with the second part of estimation, the EQF, Estimation Quality Factor.

Part 2: Track EQF to Understand the Project Estimate

As you continue to manage the project, track your initial completion date estimate. Each month, or in a short project, each week, take 5 minutes out of your project team meeting, and ask: “When do you think we will finish the project?” Track that estimate on a chart set up with the release dates on the Y-axis, and the date that you asked the question on the X-axis.

There are two good reasons for asking this question. First, you continue to focus your project staff on completing the project. People tend to work on what you, the project manager focuses on. Second, by asking your project staff, you can discover the various confidences the staff has in the release date. When you look at the EQF chart, you can see if people are concerned that the project will not meet its release date, or if they are feeling confident about meeting or beating the release date. Then you can deal with their concerns or your concerns.

When you track EQF with your project team, you’re learning more about the project, and using EQF to learn how good your initial estimate was.

Part 3: Use EQF to Manage Project Concerns

I use the slope of the EQF to ask questions like, “Tell me what’s happened in the project to make you think we will meet/beat/miss the date.” When people become more optimistic or pessimistic, I want to know why. The EQF not only gives me feedback on my initial estimate, it gives me another technique to discuss the project state with the project team.

And, once I understand the project team’s concerns, I can deal with them or elevate those concerns to my management.

Part 4: Update Your Estimate as You Know More

When you first created an estimate, you developed some date range, an “about” date, or a series of dates with a confidence level. Once the project is underway and you’re using EQF to understand what the rest of the project team thinks of the date and the risks to the project, you’re ready to update your project estimate.

If the team has missed interim milestones and all of you think there is no way to deliver the requested feature set in the estimated time with appropriate defect levels, then it’s time to slip the project. Remember, don’t slip a week every week; that’s an out of control project. Instead, make the slip as long as you need it. Manage the risks of further slippage by creating more interim deliverables.

If the team has met their milestones, and you’re on track, you can close in on a more specific date. For example, if you started with a completion date of “May 1 ? June 15,” about halfway through the project you might be able to say, “May 8 ? June 10.” About three quarters of the way through the project you can probably say, “May 20 – June 1.” As you reach May 1, you can say when in those ten days you can complete the project.

Summary

If you’re only using one of these techniques to estimate and manage your projects, consider adding the others. Every project worth completing has some project uncertainty. EQF is a great technique for displaying project uncertainty, and understanding why the project team is uncertain about the project.

The more everyone understands about the project, the better your project management will be, and the more likely you are to meet your SWAG. At least, you’ll know how far off your SWAG was, and why. And that knowledge can help you on your next project.

convert this post to pdf.