Estimating The Project

Estimating The Project

When you are preparing an estimate, understand this: The estimate is not the budget. The estimate tells management, including you, how much effort will be needed to complete the project. The budget tells you how much the project will cost. Estimates deal with effort, expressed in periods such as workdays. Budgets deal in dollars.

Do an estimate bottom-up. That is, estimate effort at the lowest level of the WBS, making sure you include both work and distributed activities. You do not need to estimate effort for higher-level activities; their effort is simply the sum of the efforts of their lower level activities.

A complete estimate, therefore, will tell management how much time the project needs from each type of resource.

Estimating is not concerned with the allocation or availability of staff. These are handled as part of resource leveling.

Resource Classifications

Activities are carried out by individuals, but planning usually starts with classifications, such as technology architect, systems analyst, or programmer analyst. To complete an estimate, you need to know what types of skills each activity needs and what staff classifications have those skills. You will ultimately have to put names to each activity, but for now, you are concerned with letting your management know how many of which type of staff you need.

Distributed activities may involve one person (project management) or a number of peopleup to and including the entire project team (reviews).

Percent Commitment

Some people will be required full time on an activity, while others will be needed less. Usually, more junior staff are full time on activities such as program coding, while senior staff are split among several different activities, part time on each.

Percent commitment is not the same as percent availability. The former refers to the requirements of the activity; the latter refers to the availability of the person to your project. An example of an activity that does not need 100 percent commitment is network support. This activity may require only 10 percent of a network analyst's time.

Sticker Shock

The first time you complete an estimate for your project, you may feel as if you have been multiplying durations rather than adding them; the total effort will seem ridiculously high. In an attempt to get the estimates down to a reasonable level, many estimators return to the WBS and begin to estimate activities at higher levels. For example, if the activities to complete a software evaluation add up to two work-months, there is a temptation to look at the entire set of evaluation activities, say, "This can't take any more than one month," and discard the original estimate. That way lies trouble.

If your estimates are greater than you expected, you can use higher-level activities as a kind of sanity check, but any estimates you change must be at the lowest level, and the changes for each activity must be reasonable. If, after you review your low-level estimates, the total does not change much, then your higher-level gut feeling is probably wrong. While the sum of lower-level estimates is generally greater than an estimate taken at a higher level, lowerlevel estimates also tend to be more accurate.

Contingency

A contingency is an allowance for problems. It is better to state it overtly as an activity on the WBS, rather than to covertly bury it in each work activity. If it is overt, you can make explicit decisions to use some of it and to direct it to problem areas. If it is hidden, not tend to regard it as potential profit rather than as a legitimate project cost and become annoyed when project managers try to use it. Project managers who have been burned when they try to apply contingency will bury it and attempt to track it covertlywhich never works.

It is commonplace to estimate contingency as a percent of the project estimate: ''Let's add 10 percent of the workdays as a contingency." But the contingency varies with different project activities and should be estimated at the topmost level of the WBS. For example, the contingency for management and support might be 5 percent, whereas that for integration may be 20 percent. The project contingency is the total for all sections of the WBS. (However, contingency may be applied anywhere on the project. It is not reserved for activities in the same proportions as it was calculated.)

Danger Areas in Estimating

It is a clichè, supported by endless project overruns, that information systems people are poor estimators. Yet the reality is not so simple. In fact, most people are fairly accurate at estimating activities they have done before. Estimates for coding, documentation, training, and even analysis tend to be close to actual numbers. Where estimates fall apart is on activities that are new or those that vary substantially from project to project.

There are several danger areas in estimating:

1. Integration. Integration of code can be as simple as assembling tested pieces that fit together nicely, or as complex as completely redeveloping code that appears to have been written in isolation from the rest of the project. Unfortunately, most estimates assume that integration will be closer to assembly than to redevelopment.

The keys to a smooth integration are adequate, detailed work during the definition and design phases and a mechanism to ensure that whenever anyone decides, for example, to add just one more element to the data dictionary, details of the change are distributed to the project team. If the project does not have these features, either add them or quadruple the integration estimate.

2. New technology. If the project uses a new technology, such as a language, operating system, database, or tool kit, ensure that the estimate includes ample time for familiarization. A new technology is one that no member of the project team has ever used, either by itself or in combination with other project technologies.

A technology is new even if it is only a different brand name. It is tempting, for example, to assume that since Fred has worked with a relational database and the project uses one, no new technology is involved, even though the project's database is different from the one Fred used. Wrong. While Fred may adapt to the new database faster than someone who has no experience, he will still need time to learn the subtle differences.

There are two problems with a new technology: use and integration. Use is the ease with which the project team learns and masters the technology. It is measured by the time spent in rework and is mitigated by ample training at the start of the project.

Integration is the problem of making a new technology work with other technical components of the project. It is all too common to hear statements such as, "We've discovered that version 1.2 of the operating system, which we're using, does not support version 4.0 of the communications manager. It does support version 3.2, but that version does not have the asynch protocol support, which we can do without if we switch to version . . ." The problem increases exponentially with the number of new components.

When integrating new technologies, find or buy expertise. It is cheaper to fly an expert in from across the country for a week than to tie up an entire project team for a month or more trying to figure out how to get one component to talk to another.

3. External dependencies. Externally, the project will depend on the performance of the client and suppliers. The problem is that you have no direct control over either one. See "Managing Subcontractors" and "Managing Client Expectations" in Chapter 5 for some techniques for influencing external groups.

Of the external activities, the most critical are those that are repetitive, such as client review and approval of deliverables. If you underestimate delivery from a supplier by a week, the most the project will suffer is one week's delay. But if you underestimate the review and approval cycle by just one day, twenty deliverables will cost you a month.

It is therefore critical that you get estimates of repetitive activities right. Naturally, client input is important. But, if possible, find out from people who worked on other projects for the client what the bottlenecks and delays were. Then make sure the estimates reflect that history.

4. Methodologies. A new methodology is a danger, as is a decision to apply an existing one more stringently than before. The problem is that a methodology dictates a set of deliverables, and without experience it is difficult to estimate the work needed for each one.

If you are faced with a new methodology, make sure that you know what deliverables it demands and that you understand their scope. If possible, meet with someone who has worked with the methodology, get examples of deliverables, and ensure that you and the client expect the same level of detail.

Presenting the Estimate

The estimate is expressed as a workday (or work-week or workmonth) requirement by classification. For example, a project needs 150 project manager workdays, 300 systems analyst workdays, 750 programmer analyst workdays, 50 quality assurance workdays, and 50 clerical support workdays. This type of estimate allows management to recognize the extent of the project and the resource commitments that will be needed.

The estimate is also the first thorough check of the approximations that have accompanied the project thus far. An estimate of 1,000 workdays will come as a shock to managers that have been thinking in terms of 200. Therefore, before you present an estimate, be aware of what they expect and make your presentation accordingly (see "Bearing Bad News" in Chapter 6).

What If?

Your Estimators Present You With Estimates That You Think Are Too Low.

If your estimates are low, your project will overrun its schedule and budget and you and your team will become frustrated in trying to meet an impossible set of targets.

Actions

Clarify in your own mind why you think the estimates are low. This could be because of your experience on similar projects or because you know that this particular estimator is always optimistic.

Present your concerns to the estimator and ask for a commitment to complete the work within the estimated time.

If the estimator declines to change the estimates but fails to convince you that they are achievable, prepare your project plan using your higher estimates. However, if during the project you can assign the work to the estimator, use the lower estimates that you were given. If the team member meets the lower schedule, you will have come in under budget. If not, your schedule will accommodate the "slippage" and you will have some background to better judge future estimates.

Your Estimators Present You With Estimates That You Think Are Too High.

If your estimates are high, you run the risk that management will reject your project plan. In particular, if there is a fixed budget for the project, you will come under pressure to trim the estimates.

Actions

Clarify in your own mind why you think the estimates are high. One common reason is that some estimators opt for a conservative approach.

Explain to the estimator why you believe the estimates are too high and ask for a detailed review.

If the estimator is not willing to reduce the estimates but cannot convince you that they are reasonable, seek a second opinion and accept the results.

Your Management Reject Your Estimates as Too High.

If you believe that your estimates are valid (and if you don't you should not be presenting them), then, by asking you to reduce them, your managers are asking you to create an estimate that is not achievable. The problem is that you will then be expected to deliver according to that plan.

Actions

This is not an area for compromise. If your judgment, and that of your technical staff, says that the project will take 1,000 workdays, it is your responsibility to defend that estimate.

If your management insist that the project be done with less effort, you have just two choices: Refuse to adjust your plan, or accept the reduced effort with the caveat that the estimates are not yours and have been imposed on you.

Your Management Reject Your Estimates as Too Low.

In very few cases will management insist that you increase your estimates. However, those cases are critical. For example, if your company is bidding on a job, your low estimate may win it, but if your estimates are so low that your company loses money, the blame will be laid on you alone.

Actions

Review your estimates. Get a second opinion. Be as sure as you can that the estimates are valid.

If your management insist on increasing the estimates, do not resist strenuously. But if, at the end of the project, you come in under budget and ahead of schedule, you can point out the accuracy of your original estimates.