Estimating

Estimation is the one area where most project teams have trouble. For one thing, there is no consistency. One person might be optimistic, another pessimistic, and you won't know which unless you have had prior substantiating evidence of one or the other. Having the professional who will be responsible for the work also estimate the duration or labor involved is a good idea, but it isn't the answer either. Will this person be pessimistic just so the work is sure to meet the estimated deadline? The approach that I use is to have more than one person provide each estimate, as explained in this section.

Estimating Duration

Before you can estimate duration, you need to make sure everyone is working from a common definition. The duration of a project is the elapsed time in business working days, not including weekends, holidays, or other non-work days. Work effort is labor required to complete a task. That labor can be consecutive or nonconsecutive hours.

Duration and work effort are not the same thing. For example, I had a client pose the following situation: The client had a task that required him to send a document to his attorney, where it would be reviewed, marked up, and then returned. He had done this on several previous occasions, and it normally took about 10 business days before the document was back in his office. He knew the attorney took only about 30 minutes to review and mark up the document. His question was, “What's the duration?” The answer is 10 days. The work effort on the part of the attorney is 30 minutes.

It is important to understand the difference between labor time and duration time. They are not the same. Suppose an estimate has been provided that a certain task requires 10 hours of focused and uninterrupted labor to complete. Under normal working conditions, how many hours do you think it will really take? Something more than 10 for sure. To see why this is so, consider the data shown in Figure 5-8.

Figure 5-8: Elapsed time versus work time

If a person could be focused 100 percent of the time on a task, he or she could accomplish 10 hours of work in 10 hours. Such a person would indeed be unique, for it is more likely that his or her work will be interrupted by e-mail, cell phones or text messages, meetings, coffee breaks, and socializing. Several estimates have been made regarding the percentage of a person's day that he or she can devote to project work. Past data that I have collected from information technology (IT) professionals indicates a range of 66 to 75 percent. More recently, among the same client base, I have seen a downward trend in this estimate to a range of 50 to 65 percent. If you use the 75 percent estimate, a 10-hour task should require about 13 hours and 20 minutes to complete. That is without interruptions, which, of course, always happen.

For some professionals (those who provide technical support, for example), interruptions are frequent; for others (such as testing staff), interruptions are infrequent. I polled the 17-person technical support unit of a midsize IT department and found that about one-third of their time was spent on unplanned interruptions. Unplanned interruptions might include a phone call with a question to be answered, a systems crash, power interrupts, random events of nature, the boss stopping in to discuss an unrelated matter, or a personal call from your golfing buddies. Using a 75 percent estimate for focused work and a 33 percent estimate for unplanned interruptions, a 10-hour task will take approximately 20 hours to complete.

It is this elapsed time that you are interested in when estimating for each task in the project. It is the true duration of the task. For costing purposes, you are interested in the labor time (work) actually spent on a task.

Resource Loading versus Task Duration

The duration of a task is influenced by the amount of resources scheduled to work on it. I say “influenced” because there is not necessarily a direct linear relationship between the amount of resources assigned to a task and its duration.

Adding more resources to hold a task's duration within the planning limits can be effective. This is called “crashing the task.” For example, suppose you are in a room where an ordinary-size, four-legged chair is in the way. The door to the room is closed. You are asked to pick up the chair and take it out of the room into the hallway. You might try to do it without any help, in which case you would perform the following steps:

1. 1. Pick up the chair.
2. Carry it to the door.
3. Set the chair down.
4. Open the door.
5. Hold the door open with your foot as you pick up the chair.
6. Carry the chair through the door.
7. Set the chair down in the hallway.

Suppose you double the resources. You'll get someone to help you by opening the door and holding it open while you pick up the chair and carry it out to the hallway. With two people working on the task, you'd probably be willing to say it would reduce the time needed to move the chair out of the room and into the hallway.

Doubling the resources sounds like a technology breakthrough in shortening duration. Now double them again and see what happens. Now you've got four resources assigned to the task. It would go something like this: First, you hold a committee meeting to decide roles and responsibilities. Who's in charge? Who holds the door open? Who takes what part of the chair? The duration actually increases!

The point of this silly example is to demonstrate that there may be diminishing returns for adding more resources. You would probably agree that there is a maximum loading of resources on a task to minimize the task duration, and that by adding another resource, you will actually begin to increase the duration. You have reached the crashpoint of the task. The crashpoint is the point where adding more resources will increase task duration. The project manager will frequently have to consider the optimum loading of a resource on a task.

A second consideration for the project manager is the amount of reduction in duration that results from adding resources. The relationship is not linear. Consider the chair example again. Does doubling the resources cut the duration in half? Can two people dig a hole twice as fast as one? Probably not. The explanation is simple. By adding the nth person to a task, you create the need for n more communication links. Who is going to do what? How can the work of several people be coordinated? There may be other considerations that actually add work. To assume that the amount of work remains constant as you add resources is simply not correct. New kinds of work will emerge from the addition of a resource to a task. For example, adding another person adds the need to communicate with more people, which increases the duration of the task.

A third consideration for the project manager is the impact on risk that results from adding another resource. If you limit the resource to people, you must consider the possibility that two people will prefer to approach the task in different ways, with different work habits and different levels of commitment. The more people working on a task, the more likely one will be absent, the higher the likelihood of a mistake being made, and the more likely they will get in each other's way.

The fourth consideration has to do with partitioning the task so that more than one resource can work on it simultaneously. For some tasks, this will be easy; for others it may be impossible. For example, painting a house is a partitionable task. Rooms can be done by different painters, and even each wall can be done by a different painters. The point of diminishing returns is not an issue here. Conversely, the task of writing a computer program may not be partitionable at all. Adding a second programmer creates all kinds of work that wasn't present with a single programmer — for example, choosing a language and/or naming conventions to use, integration testing, and so on.

Variation in Task Duration

Task duration is a random variable. Because you cannot know what factors will be operative when work is underway on a task, you cannot know exactly how long it will take. There will, of course, be varying estimates with varying precision for each task. One of your goals in estimating task duration is to define the task to a level of granularity such that your estimates have a narrow variance — that is, the estimate is as good as you can get it at the planning stages of the project. As project work is completed, you will be able to improve the earlier estimates of activities scheduled later in the project.

The following factors can cause variation in the actual task duration:

Six Methods for Estimating Task Duration

Estimating task duration is challenging. You can be on familiar ground for some activities and on totally unfamiliar ground for others. Whatever the case, you must produce an estimate. It is important that senior management understand that the estimate can be little more than a WAG (wild a** guess). In many projects, the estimate will improve as you learn more about the deliverables after having completed some of the project work. Re-estimation and replanning are common. In my consulting practice, I have found the following six techniques to be quite suitable for initial planning estimates:

• Similarity to other activities
• Historical data
• Expert advice
• Delphi technique
• Three-point technique
• Wide-band Delphi technique

The following sections describe each of these techniques in more detail.

Extrapolating Based on Similarity to Other Activities

Some of the activities in your WBS may be similar to activities completed in other projects. Your or others' recollections of those activities and their durations can be used to estimate the present task's duration. In some cases, this process may require extrapolating from the other task to this one. In most cases, using the estimates from those activities provides estimates that are good enough.

Studying Historical Data

Every good project management methodology includes a project notebook that records the estimated and actual task durations. This historical record can be used on other projects. The recorded data becomes your knowledge base for estimating task duration. This technique differs from the previous technique in that it uses a record, rather than depending on memory. To estimate the duration of a task, you extract similar tasks from the database and compute an average. That is a simple application of the database.

The historical data can be used in a more sophisticated way, too. One of my clients built an extensive database of task duration history. They use this database to record not only estimated and actual duration, but also the characteristics of the task, the skill set of the people working on it, and other variables that they found useful. When a task duration estimate is needed, they go to their database with a complete definition of the task and, with some rather sophisticated regression models, estimate the task duration. This particular client builds product for market, so it is very important to them to be able to estimate as accurately as possible. Again, my advice is that if there is value added for a particular tool or technique, use it.

Seeking Expert Advice

When the project involves a breakthrough technology or a technology that is being used for the first time in the organization, there may not be any organizational experience with that technology within the organization. In these cases, you will have to appeal to outside authorities. Vendors may be a good source, as are non-competitors who use that technology.

Applying the Delphi Technique

The Delphi technique can produce good estimates in the absence of expert advice. This is a group technique that extracts and summarizes the knowledge of the group to arrive at an estimate. After the group is briefed on the project and the nature of the task, each individual in the group is asked to make his or her best guess of the task duration. The results are tabulated and presented to the group in a histogram labeled First Pass, as shown in Figure 5-9. Participants whose estimates fall in the outer quartiles are asked to share the reason for their guess. After listening to the arguments, each group member is asked to guess again. The results are presented as a histogram labeled Second Pass, and again the outer quartile estimates are defended. A third guess is made, and the histogram plotted is labeled Third Pass. Final adjustments are allowed. The average of the third guess is used as the group's estimate. Even though the technique seems rather simplistic, it has been shown to be effective in the absence of expert advice.

Figure 5-9: The Delphi technique

I attended an IBM business partners' meeting several years ago. One of the sessions dealt with estimating software development time, and the presenter demonstrated the use of the Delphi technique with a rather intriguing example. She asked if anyone in the group had ever worked in a carnival as a weight-guessing expert. None had, so she informed the group that they were going to use the Delphi technique to estimate the average weight of the 20 people who were in the room. She asked everyone to write his or her weight on a slip of paper. The weights were averaged by the facilitator and put aside. Each person took an initial guess as to the average weight of the people in the room, wrote it down, and passed it to the facilitator. She displayed the initial-pass histogram and asked the individuals with the five highest and five lowest guesses to share their thinking with the group; a second guess was taken and then a third. The average of the third guess became the group's estimate of the average body weight. Surprisingly, the estimate was just two pounds off the average of the individual's reported weights.

The approach the presenter used is actually a variation of the original Delphi technique. The original version used a small panel of experts (say, five or six) who were asked for their estimate independently of one another. The results were tabulated and shared with the panel members, who were then asked to submit their own second estimate. A third estimate was solicited in the same manner. The average of the third estimate was the one chosen. Note that the original approach does not involve any discussion or collaboration between the panel members. In fact, they weren't even aware of who the other members were.

Applying the Three-Point Technique

Task duration is a random variable. If it were possible to repeat the task several times under identical circumstances, duration times would vary. That variation may be tightly grouped around a central value, or it might be widely dispersed. In the first case, you would have a considerable amount of information on that task's duration as compared to the latter case, where you would have very little or no usable information on that task's duration. In any given instance of the task, you would not know at which extreme the duration would likely fall, but you could make probabilistic statements about their likelihood in any case. Figure 5-10 illustrates the point.

To use the three-point technique, you need the following three estimates of task duration:

Figure 5-10: The three-point technique

Then the estimated duration is given by the formula

(O + 4M + P) / 6

For this method, you are calling on the collective memory of professionals who have worked on similar activities but for which there is no recorded history.

Applying the Wide-Band Delphi Technique

Combining the Delphi and three-point methods results in the wide-band Delphi technique. It involves a panel, as in the Delphi method. In place of a single estimate, the panel members are asked, at each iteration, to give their optimistic, pessimistic, and most likely estimates for the duration of the chosen task. The results are compiled, and any extreme estimates are removed. Averages are computed for each of the three estimates, and the averages are used as the optimistic, pessimistic, and most likely estimates of task duration.

Estimation Life Cycles

A word of advice on estimating is in order here. Early estimates of task duration will not be as good as later estimates. It's a simple fact that you get smarter as the project work commences. Estimates will always be subject to the vagaries of nature and other unforeseen events. You can only hope that you gain some knowledge through the project to improve your estimates.

In the top-down project planning model, you start out with “roughly right” estimates, with the intention of improving the precision of these estimates later in the project. Both your upper management and the client must be aware of this approach. Most managers have the habit of assuming that a number, once written, is inviolate and absolutely correct regardless of the circumstances under which the number was determined. This is unrealistic in the contemporary world of project management. It may have once been appropriate for the engineer, but that is not the case with the businessperson. Figure 5-11 illustrates a typical estimation life cycle.

Figure 5-11: The estimation life cycle

During project planning, most task estimates are not much better than a dart throw. Of course, if the task is one that has been done several times before under similar situations, then the estimate will have a narrower variance than it would if the task had never been done before under any circumstances. As project work commences, the team will gain knowledge and understanding of the project and the work needed to deliver an acceptable solution. That includes improved estimates of future tasks in the project. After the task has begun, even more information will come to light, and the estimate (or a better estimate to completion) will be quite accurate.

Estimating Resource Requirements

By defining project activities according to the completion criteria, you should have reached a point of granularity with each task so that it is familiar. You may have done the task or something very similar to it in a past project. That recollection, or historical information, gives you the basis for estimating the resources you will need to complete the activities in the current project. In some cases, it is a straightforward recollection. In others, it is the result of keeping a historical file of similar activities. In still others, the resource estimate may be the advice of experts.

The importance of resources varies from project to project. You can use the six techniques discussed in the previous section to estimate the resource requirements for any project.

Types of resources include the following:

People as Resources

People are the most difficult type of resource to schedule because you plan the project by specifying the types of skills you need, when you need them, and in what amounts. You do not specify the resource by name (that is, the individual you need), which is where problems arise.

There are a few tools you can use to help you schedule people.

Skills Matrices

I find that an increasing number of my clients are developing skills-inventory matrices for staff, and skill-needs matrices for activities. The two matrices are used to assign staff to activities. The assignment could be based on task characteristics such as risk, business value, criticality, and/or skill development. Figure 5-12 illustrates how the process can work.

Figure 5-12: Assigning staff to activities

This process involves gathering data for the following two inventories:

• An inventory of the demand for skills needed to perform the tasks associated with specific activities. This is represented as a matrix whose rows are the activities and whose columns are the skills. These include both current and long-term needs.
• An inventory of the current skills among the professional staff. This is represented as a matrix whose rows identify the staff and whose columns represent the skills.

The columns of both matrices define the same set of skills. This gives you a way to link the two matrices and assign staff to activities. This approach can be used for on-the-job staff development. As an on-the-job development strategy, the manager would have previously met with the staff member, helped him or her define career goals, and translated those goals into skill development needs. That information can then be used in project planning to assign staff to activities so that the work they will do on the task enables them to meet those goals.

Skill Categories

This part of the skill matrix is developed by looking at each task that the unit must perform and describing the skills needed to perform the task. Because skills may appear in unrelated activities, the list of possible skills must be standardized across the enterprise.

Skill Levels

A binary assessment that simply determines whether a person has the necessary skill or doesn't is certainly easier to administer, but it isn't sufficient for project management. Skills must be qualified with a statement about how much of the skill the person possesses. Various methods are available, and companies often develop their own skill-level system.

Resource Breakdown Structure

Just as there is a Work Breakdown Structure (WBS), so also is there a Resource Breakdown Structure. Figure 5-13 gives a simple example.

The Resource Breakdown Structure is used to assist in not only resource estimation but also cost estimation. The Resource Breakdown Structure is determined by the job families, which are defined by the human resources department. That definition is simply put into this hierarchical framework and used as the basis for identifying the positions and levels that are needed to staff the project. This is then used to construct the staffing budget.

Figure 5-13: Example of a Resource Breakdown Structure

Determining Resource Requirements

The planning team includes resource managers or their representatives. At the time the planning team is defining the WBS and estimating task duration, they also estimate resource requirements.

I have found the following practice effective:

1. Create a list of all the resources required for the project. For human resources, list only the position title or skill level. Do not name specific people even if there is only one person with the requisite skills. Envision a person with the typical skill set and loading on the project task. Task duration estimates are based on using workers of average skill level, and that should be consistent with the needed resource requirements. You can worry about changing the assumption of using average skilled persons later in the planning session.
2. The project manager can provide resource requirements as part of the WBS.

You now have estimated the parameters needed to begin constructing the project schedule. The task duration estimates provide input to planning the order and sequence of completing the work defined by the activities. After the initial schedule is built, you can use the resource requirements and availability data to further modify the schedule.

Resource Planning

You need to consider several factors concerning the resources for your project. As you learned earlier in this chapter, adding resources doesn't necessarily mean that you will shorten the time needed for various activities. Adding too many people can actually add time to the project. Another factor to consider deals with the skill level of the resources.

Suppose that you are going to have a team of developers work on an application. When you are planning resources, you have to know the skill level of the potential resources. You may have to trade money for time. That means you may be able to get a lower cost by using a junior developer, but it's likely you will also find that the process takes longer. Knowing the skill sets of the available people and taking that into account when doing scheduling are critical to resource planning.

Another factor to consider is that of using existing staff on a part-time basis. At first glance, using staff on a part-time basis might seem like a good idea because you can make good decisions concerning their schedules and you will get extremely efficient use of their time. However, this isn't reality, particularly if they are coders. Development is a mental task, and what you need are knowledge workers. You can't turn a mental process on and off at will.

Similarly, scheduling people to work on two projects on the same day won't be an efficient use of resources. It takes some time for a developer to get up to writing speed. That kind of schedule may look good on paper, but it doesn't work. Give your resources a chance to get into the flow of work, and you'll be much more successful.

Estimating Cost

After you have estimated task duration and resource requirements, you have the data you need to establish the cost of the project. This is your first look at the dollars involved in doing the project. You know the resources that will be required and the number of hours or volume of resources needed. You can now estimate the project cost by applying the unit cost data to the amount of resources required.

When doing an estimate, you need to consider a few concepts. No matter how well you estimate cost, it is always an estimate. One of the reasons that so many projects come in over budget is that people actually believe that they have done perfect estimating and that their baseline estimate is set in stone. Remember that it is still and always will be an estimate. Anytime you are forecasting the future, as you are when you plan a project, you are dealing with some amount of uncertainty. Projects are so often over budget because the budget itself is an estimate, not an exact mathematical calculation. Even experienced cost estimators miss the mark.

With those warnings in mind, you still need to do your best to come up with a working budget for the project. Estimating can be done several ways. One method is to find an analogous project — a completed project that looks a great deal like the project you're currently planning. By using this previous project as a guideline, you'll have a reference point for the costs. The caveat that you must keep in mind is that each project is unique, which means you will have a slightly different budget for your estimate than the one from the previous project. Don't just use the same figures when you estimate, or this will come back to haunt you sometime in the project.

Another good practice in estimating is to invite subject matter experts (SMEs) to help you prepare your estimate. Ideally, these SMEs will be able to discuss their areas of expertise and give you a better handle on the estimating for your current projects.

The team should have access to a standard costing table. This table will list all resources, units of measure, and cost per unit. It is then just a simple exercise in calculating the cost per resource based on the number of units required and the cost per unit. Many organizations have a spreadsheet template that will facilitate the exercise. These calculated figures can be transferred to the WBS and aggregated up the WBS hierarchy to provide a total cost for each task level in the WBS.

The following three types of estimates are common in project management. They are often done in the sequence listed.

Cost Budgeting

After you've done an estimate, you enter the cost budgeting phase. This is the phase when you assign costs to tasks on the WBS. Cost budgeting is actually very formulaic. You take the needed resources and multiply the costs by the number of hours they are to be used. In the case of a one-time cost (such as hardware), you simply state that cost.

Cost budgeting gives the sponsor a final check on the costs of the project. The underlying assumption is that you've got all the numbers right. Usually you'll have the cost of a resource right, but often it's tough to be exact on the total number of hours the resource is to be used. Remember that no matter what, you are still doing an estimate. Cost budgeting is different from estimating in that it is more detailed. However, the final output is still a best effort at expressing the cost of the project.

Cost Control

Cost control presents the following major issues for the project manager:

• How often do you need to get reports of the costs? Certainly, it would be good if you could account for everything occurring on the project in real time. However, that is generally way too expensive and time-intensive. More likely, you'll get figures once a week. Getting cost status figures once a week gives you a good snapshot of the costs that are occurring. If you wait longer than a week to get cost figures, you may find that the project has spun out of control.
• How will you look at the numbers you're receiving? If you've done a cost baseline, you'll have some figures against which you can measure your costs. What you're looking for is a variance from the original costs. The two costs you have at this point are your baseline and the actual costs that have occurred on the project. The baseline was the final estimate of the costs on the project. Your job is to look at the two and determine whether management action must be taken.

A word of advice: Keep in mind that for some projects, time is the most important constraint. Remember Y2K? In such cases, you must balance your need for cost control with the need for a definitive project ending time. There may be a trade-off in cost control for time constraints. As a project manager, you must be aware of these trade-offs and be ready to justify changes in costs to the sponsor based on other considerations such as time and quality.