Use All Three Parts of Project Estimation (2024)

Project work estimation has three components: the initial first cut, commonly known as a SWAG (scientific wild-ass guess), tracking the estimate against the actual numbers, 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 make 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 and 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: "Five people for about nine months or 10 people for about six 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 Aug. 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 total.

The problem with estimates is that they are guesses. They're the best guesses we can make, but they're still guesses. As the project unfolds, you 'll be able to acquire feedback on how well you estimated using the second part of estimation, the EQF, or 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 five 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, focus on. Second, by asking your project staff, you can discover the various confidences they have in the release date. When you look at the EQF chart, you can see if people are concerned that the project won't meet its release date, or if they're feeling confident about meeting or beating the release date. Then you can deal with their concerns or your own.

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 make queries 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 also 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.

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

The better everyone understands 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.

Previous columns by Johanna Rothman:

• Steering vs. Repeatable

  Instead of focusing on being repeatable (as in repetitious), let's think first, and steer our projects.

• What's Wrong With Wednesdays?

  Down with Fridays and Mondays. Let's end and begin project segments on Wednesdays.

• What's Your Fault Feedback Ratio?

  You should start tracking how many of your bug fixes are successful and how many fixes are bad -- either introducing a new defect or not completely fixing the original defect.

The Web Services Tsumani

Stories in this report:

• The Web Services Tsunami
• The Story So Far: Web Services
• Web Services: Waves of Change
• Opinion: Web Services' Sharp Edge
• Web Services in Action
• A Plain-English Explanation of XML and Web Services
• Testing: Key to Web Services Success
• The Almanac: Software Development and Web Services
• XACML
• Preparing for a Career in Web Services
• The Next Chapter: Web Services
• Testing in an Organic World
• Use All Three Parts of Project Estimation
• Treat IT Applications Like Employees — As Ongoing Investments

Related:

• Software Development

It’s time to break the ChatGPT habit