TechRepublic columnist Tom Mochal receives dozens of e-mails each week from members with questions about project management problems. Mochal shares member questions and the answers he provides in a column each month. So often, IT pros tell TechRepublic that they receive the most insight when they learn about real-life situations that other IT pros are facing.

Question: Is there a process to determine if a project is worthwhile?
When estimating a program (collection of projects) or project at an idea or concept stage, is there a technique or process that would help determine if the idea or concept is worth pursuing? When estimating an idea or concept, we tend to spend too much time getting into details before we even know if the idea is a worthwhile one to pursue. We use traditional estimating techniques. Basically we want to know, with some level of confidence, if the idea is a large gold nugget, medium gold nugget, small gold nugget, fool’s gold, or a rock. Have you recommended, seen, or used a good approach?
—M.B.

Answer: Top-down techniques generate confident estimates
Your question is one that all companies face as they plan projects.

To make that determination, management needs some sense of the overall cost of the project, as well as the expected benefit. And, by the way, as we struggle trying to estimate the project cost, the business people are also struggling trying to understand and quantify the project’s benefits.

The most accurate way to estimate is usually to build a work breakdown structure and to estimate all of the lowest level, individual work components. This bottom-up approach is, unfortunately, the most time consuming. It is also not appropriate for the initial estimating that you do early on in the funding and prioritization process.

Do you have a project management question for Tom?

We can’t guarantee that Tom will answer every letter, but he will read all of his mail and respond to the e-mails that will benefit the most TechRepublic members. Send us your questions, and we’ll forward them to Tom.

Instead, you will want to utilize a top-down approach to gain as much estimating confidence as possible, while also considering as short a timeframe as practical. The following are all top-down techniques that should be considered. Depending on the project, you may find that one or more techniques will work especially well. Although your question referred to estimating projects and programs, the assumption is that you are dealing with a project at this point. If you think the effort is large enough to be considered a program, then you need to take your best guess at breaking it up into a corresponding set of projects and then estimating the projects at a high level.

Top-down techniques include the following:

  • Previous history: This is by far the best way to estimate work. If your organization keeps track of actual effort hours from previous projects, you may have information that will help you estimate new work. The characteristics of the prior work, along with the actual effort hours, should be stored in a file/database. You then describe your project in the same terms to see if similar work was done in the past. If so, you will have a good idea of the effort required to do your work.
  • Partial work breakdown structure (WBS): In this approach, you start building a traditional WBS, but you only take it down one or two levels. At that point, you estimate the different work components, using your best guess or one of the other estimating techniques listed here.
  • Analogy: Even if you do not keep actual effort hours from previous projects, you may still be able to leverage previous work. Analogy means that you describe your work and ask your organization whether a similar project was done in the past. If you find a match, see how many effort hours that project took, and use the information for your estimate. (If the organization does not track actual effort hours, find out how many people worked on the project, and for how long, and then adjust the hours as needed.)
  • Ratio: Ratio is similar to analogy except that you have some basis for comparing work that has similar characteristics—but on a larger or smaller scale. For instance, you may find that the effort required to complete a software installation for the Miami office was 500 hours. There are twice as many people in the Chicago office, which leads you to believe it may take 1,000 hours there.
  • Expert opinion: In many cases, you may need to go to an internal or external expert to get help estimating the work. For instance, if this is the first time you have used a new technology, you may need the help of an outside research firm to provide information. Many times these estimates are based on what other companies in the industry are experiencing. You may also have an internal expert who can help. Although this may be the first time you have had to estimate a certain type of project, someone else in your organization may have done it many times.
  • Parametric modeling:To use this technique, a pattern must exist in the work, so that an estimate of one or more basic components can be used to drive the overall estimate. For instance, if you have to implement a package in 40 branch offices, you could estimate the time and effort required for a typical large, medium, and small office. Then group your 40 offices into buckets of large, medium, and small. Finally, do the math to estimate the entire project.
  • Estimate in phases: One of the most difficult aspects of estimating projects is not knowing exactly what work will be needed in the distant future. To reduce the level of uncertainty, you can break the work into a series of smaller projects and only give an estimate of the most current project, with a very vague estimate for the remaining work. For instance, many times you can provide a high-level estimate for an analysis phase, where you will gather business requirements. After you have the requirements, then you will be in a position to estimate the rest of the project (or at least the next major phase). At that point, management can again do a cost-benefit calculation to determine if it makes sense to proceed with the rest of the project.

As you said in your question, for these approaches, you are mostly interested in whether the overall cost is $10,000; $100,000; or $1,000,000. From an expectations standpoint, your management should expect a high-level, rough estimate to be minus 25 percent to plus 75 percent accurate. That is, if you tell them the cost of the project is $100,000, they should expect the actual cost to be in the range of $75,000 to $175,000. If your management would like more accuracy than that, they need to allow you more time to uncover more details, or they need to lay the work out at a lower level.

Project management veteran Tom Mochal is director of internal development at a software company in Atlanta. Most recently, he worked for the Coca-Cola Company, where he was responsible for deploying, training, and coaching the IS division on project management and life-cycle skills. He’s also worked for Eastman Kodak and Cap Gemini America and has developed a project management methodology called TenStep.