Estimating Software Projects

Discuss the feature articles on the LDS Tech Home Page.
User avatar
Posts: 490
Joined: Wed Jul 18, 2007 3:38 pm
Location: Salt Lake City, Utah

Estimating Software Projects

Postby McDanielCA » Wed Jun 16, 2010 2:53 pm

Estimating Software Projects was originally posted on the main page of LDSTech. It was written by Nathan Lockard.


For many software development professionals, estimation is at best a necessary evil and at worst a hiss and a byword. Here’s a sample conversation in which time is estimated for a software project:

Bob approaches Joe in the hallway just outside the break room.
Bob (Project Manager): “Hey, Joe! How’s it going? Say did you have a look at those requirements I sent you? How long is that going to take, do you think?”
Joe (Developer): “Hi Bob. Well, it’s hard to say. There wasn’t a lot of detail in your email.”
Bob: “Yeah, we’re still fleshing things out. Management just wants an idea of how big this thing is before we commit resources to it. What do you think? Three, four months?”
Joe: “Umm, maybe. I’d have to figure out some of those integration points and . . .”
Bob: “Great! Don’t worry, I won’t quote you. I’ll just let management know it’s doable.”

You know what happens next. The three-month “estimate” gets etched in stone, and Joe’s feet are raked over the coals when the project runs “over” by an additional three months. Poor, poor Joe. If you’ve ever been in Joe’s shoes, know that you aren’t alone and all is not lost. Here are some best practices that you might use to create accurate estimates and communicate them properly to your stakeholders.

  1. Don’t provide off-the-cuff estimates: An off-the-cuff estimate is any estimate created without any research or rigor of any sort, a la Bob and Joe’s three-month estimate. Also known as a “guesstimate” or a hallway estimate, this kind of estimate is both dangerous and professionally irresponsible. The first estimate you provide will be the one that is most remembered and the one to which all other estimates will be compared, so you’d better make it a good one!

    Rather than going with your gut, tell the requester that you don’t have an estimate right now, but you will have something for them in about 15 minutes. Then get to work making a real estimate that’s based on something tangible.
  2. Don’t provide a single-point value: Provide a range—such as best, most likely, and worst case—to express the variability and level of confidence you have in your estimate. Early in the project, when requirements are still written on the back of a napkin, you simply don’t have enough information to provide a highly accurate estimate. So rather than providing an estimate of exactly six months (six is a single-point value), give an estimate of four to twelve months, with four being the best-case scenario and twelve being the worst. Not only does this communicate the effort and size of the project, but the range also expresses how confident you feel about it. This will naturally lead to productive discussions including what you need to increase the accuracy of your estimate.
  3. Make the precision of your estimate match its accuracy: In How to Lie With Statistics, Darrell Huff says, "[T]he ever-impressive decimal . . . can lend an aura of precision to the inexact” (p. 109). If you feel that your estimate is exact, then by all means, say that it will take you “3.25 days.” But if you aren’t confident that the task will be completed at 10:00 a.m. on the fourth day, then provide a more inexact estimate, such as “three or four days.”
  4. Don’t deliberately underestimate: As a project lead, you may be tempted to think the estimates your engineers have provided contain some unnecessary padding. Unless you have data that support this theory, you will almost certainly regret intentionally shrinking their estimates. For one thing, the estimates you have are probably already too low because as an industry, we almost invariably underestimate our projects. And secondly, in both cost and schedule, the penalties of underestimation are far greater than the penalties for overestimation.
  5. Count, compute, and use judgment: Finally, use this process to create your estimates: Count something, compute an estimate, and use judgment as a last resort. For example, let’s say you are in a large hall filled with people. Everyone is seated at one of many tables that are arranged in rows. A man near the front of the hall stands up and issues a challenge to the group. “Please estimate the total number of children who belong to the individuals in this room,” he says. “You have five minutes.” At first glance this may seem like a daunting task, but if we use our estimation technique of Count → Compute → Use Judgment, then it becomes fairly easy to make our estimate.

    First, we count something. In this example it makes sense to count the number of individuals in the room. Not only does this value have a strong correlation to what we’re really after (a number of children), but it’s relatively easy to count and it’s readily available.

    Next, we use our count of individuals to compute an estimate for the number of children they have. We need only a bit of data to make such an estimate. Assuming that everyone in the room is an adult, all we need is a metric such as the national average of children per adult. Obviously, if we have demographic information about the group inside the room (age, race, sex, social status, affluence, etc.) we could select a better metric to use in our computation. But the principle is that we combine our count with our metric to arrive at an estimate that is plausible, fact-based, and defensible. We use our own judgment as a last resort if all else fails.
I hope you can see how this technique can be applied to the process of creating an estimate for a software project. If, for example, you find that the number of requirements for your projects has a strong correlation to how much effort they require, then to produce a strong estimate you simply need to count the number of requirements, and then compute by multiplying that number by the average effort hours on past projects. Instead of requirements, you might use story points, use cases, Web pages, or some other unit of measurement.

The point is that with a little bit of data on the current project (your unit of measurement) and a dash of data collected from historical projects (average hours per unit of measurement), you can calculate accurate estimates.

Give one or more of these best practices a try. At best, you’ll revolutionize your organization’s estimation and planning processes and be recognized as a hero. At worst, you’ll never again be asked to explain why your team didn’t meet your initial estimate of “Umm, maybe.”

Additional Reading:

  • Software Estimation: Demystifying the Black Art by Steve McConnell
  • Estimating Software-Intensive Systems, by Richard D. Stutzke
  • Agile Estimating and Planning, by Mike Cohn
Nathan Lockard is a senior test engineer for the Church.

User avatar
Senior Member
Posts: 585
Joined: Sat Jan 19, 2008 3:13 am
Location: Vicenza. Italy

Postby marianomarini » Thu Jun 17, 2010 11:30 am

Agree 100%! But what to : "I said this but I meant that?".
In my experience this is the main chance to face: "Having a clear understand on what the PM has in mind".
So I suggest, at least, a sketch of forms data in and out.
La vita è una lezione interminabile di umiltà (Anonimo).
Life is a endless lesson of humility (Anonimous).

New Member
Posts: 1
Joined: Sat Jun 25, 2011 1:32 pm

PERT; A Booz, Allen, Hamiltion... and DoD Requied Contract Requirement.

Postby Jdienlin » Sat Jun 25, 2011 2:20 pm

In 1962, I was selected to be trained in PERT (Program Evaluation Review Technique), as developed for Convair/General Dynamics, Pomona, Calif. It was said to have brought the Polaris program in "under budget and ahead of schedule." PERT had become a mandatory tool for Navy contracts in establishing program plans and budgets (estimates and schedule tracking). I left General Dynamics after drafting a complete PERT model, in PERT, then following that missile system and its transition from a pneumatic/vacuum tube system into the Navy's SM-1 (Standard Missile-1) the first Ni-Cad battery powered electro-mechanical, all solid-state controlled missile. This required developing a stable Ni-Cad battery, designing the electrical/mechanical muscle to move the Control surfaces. I remember talking with the lead Thermal Dynamisist -one of the first female Engineers at GD, "they don't want a burn-rate, they want an explosion... We're going to have to redesign the ... structural...." And so it progressed.

When I left to go back into the Army to fly helicopters in Vietnam, I was redirected to White Sands Missile Range after my test scores were validated. I was assigned to AMTED (Army Material Test Evaluation Directorate) where I ran into so much obfuscation, confusion and down-right fraud that I brought up PERT and soon found myself briefing a room full of Colonels who hadn't heard of PERT and within a week was given four to five others to train and assist getting a handle on all the Army's program scheduling and costs at WSMR.

Within a month I was providing evidence of just where a given program was, how much it had over-run its budget, also actual theft, such as a PhD candidate who had used over a hundred hours of computer main-frame time, for his doctoral thesis, an item (computer MF time) that did not exist in any of his project contracts. Such misuse of assets went on until the application of PERT detected them.

I finally argued for and was transfered to flight school and left WSMR. I later on learned that PERT had been dropped as a result of bureaucratic back-lash. AMTED was dissolved and civilian oversight put in place, made up of civil-servants who had once headed up the various Directorates that had previously over looked those projects evaluated by PERT.

Return to “LDSTech Featured Article Discussions”

Who is online

Users browsing this forum: No registered users and 1 guest