Chapter 5
Estimating Task Time
IN THIS CHAPTER
Determining task types
Effort-driven tasks
Estimating effort and duration
Using constraints
Entering the start date
Splitting tasks
One of the most challenging aspects of managing a project is estimating how long a task will take to complete. Your team members usually make a good guess on task duration and hope for the best. But the estimate is where the concept of “garbage in, garbage out” (or, scarier, “garbage in, gospel out”) truly applies. After all, the duration of individual tasks combined with network logic and the applied calendars determines the overall duration of the project — at least on paper.
An accurate estimate accommodates the nature of the task and employs the most applicable technique for estimating. Sometimes you estimate the effort involved, and sometimes you estimate the duration (the number of business days); it all depends on the nature of the task and the level of accuracy you need.
An accurate estimate isn’t the only aspect of making a schedule realistic. Project helps your schedule reflect reality by allowing you to enter constraints, pause tasks, and split tasks.
The schedule you build in Project is a model. It reflects what you think will happen — or what you plan for — given the information you enter. The more realistic the information you enter, the more realistic your schedule. However, ultimately, the schedule is a tool to help you and your team; it isn’t reality. Do the best you can to acquire accurate data, but don’t forget that you manage the schedule; it doesn’t manage you.
You’re in It for the Duration
In projects, as in life, timing is everything. Timing in your projects starts with the durations that you assign to tasks. Although Project helps you see the effect of the timing of your tasks on the overall length of your plan, it can’t tell you how much time each task will take. That’s up to you.
Estimating the duration of tasks isn’t always easy. Your estimate has to be based on your experience with similar tasks and your knowledge of the specifics of your project.
If your projects often share similar tasks, consider saving a copy of your schedule as a template that you can use in the future, thereby saving yourself the effort of re-estimating durations every time you start a similar project. Find out about saving templates in Chapter 19.
Tasks come in all flavors: Identifying task types
Before you begin to enter task durations, be aware of task types in Project; they have an effect on how Project schedules the work of a task using the automatic scheduling mode after you begin assigning resources.
Essentially, your choice of task type determines which element of the task remains constant when you make changes to the task:
- Fixed Units: When you assign resources (Project considers them fixed units) to a task, they continue to work on that task even if the duration changes. (This type is the default.) For example, if you assign someone full time to build a presentation for senior management and you set the duration for three days, and then you realize that five days is more realistic, the number of units stays the same. In other words, the same person is still working on the task full time, but for five days rather than three days.
- Fixed Duration: The task takes a set amount of time to complete, no matter how many resources you add to the mix. For example, a test on a substance that requires leaving the test running for 24 hours has a fixed duration, even if you add 20 scientists to oversee the test.
- Fixed Work: The number of resource hours assigned to the task determines its length. If you set the duration of a Fixed Work task at 40 hours, for example, and you assign two resources to work 20 hours each (simultaneously) at units of 100 percent, the task will be completed in 20 hours. If you remove one resource, the single resource must spend 40 hours at units of 100 percent to complete the task.
You can see how understanding the various task types (along with how each one causes the task timing or resource assignments to fluctuate) is an important part of creating an efficient project.
Follow these steps to set the task type:
Double-click a task.
The Task Information dialog box appears.
- Click the Advanced tab, as shown in Figure 5-1.
- Choose one of the three options from the Task Type list.
- Click the OK button.
FIGURE 5-1: Setting the task type.
You can also display the Type column on a Gantt Chart sheet and set the task type there. To do this, right-click the top of any column, and select Insert Column from the contextual menu. A whole list of columns is available. Simply scroll down and select Type, and a the column will be inserted.
Effort-driven tasks: 1 + 1 = ½
When you hear the word effort in Project, think work. For a task that’s automatically scheduled, you can also set it up to be effort driven: If you adjust resource assignments, the duration might change, but the number of hours of effort (work) resources needed to complete the task stays the same. (Effort-driven scheduling isn’t available for manually scheduled tasks.) When you add or delete a resource assignment on an effort-driven task, work is distributed equally among resources. (Refer to the description of fixed-work tasks in the preceding section.) In fact, all fixed-work tasks are effort driven. The more people you add, or the more hours they work, the shorter the duration, and vice versa.
Suppose that you need to set up a computer network in a new office in two days. You assign one resource who works 8 hours per day, so the work will take 16 hours to complete (two 8-hour days). If you then assign a second resource, this effort-driven task no longer takes two days, because the hours of effort required will be completed more quickly by the two people working simultaneously — in this case, in one 8-hour period.
Behind the scenes, effort-driven scheduling uses this formula to work this “magic”:
Duration = Work ÷ Units
After you make the first assignment, any time you add or remove more units (people), Project recalculates the duration accordingly.
Select the Effort Driven check box on the Advanced tab in the Task Information dialog box to enable or disable the Effort Driven setting; it isn’t selected by default (refer to Figure 5-1). When you clear this check box, the same task that you set to run two days takes two days, no matter how much effort your resources contribute.
Table 5-1 describes limiting behaviors in working with Project on effort-driven tasks.
TABLE 5-1 Limiting Behaviors
Behavior |
What Happens |
First Assignment |
When you first enter resources for an effort-driven task, the duration remains the same. If you add or delete resources after the task has been fully entered, the duration changes. |
Fixed Work |
Assigning additional resources reduces the task duration; reducing resources increases the duration. Fixed work is essentially effort-driven work, so you can’t deselect the Effort Driven check box in fixed-work tasks. |
Fixed Units |
Assigning additional resources reduces the task duration; reducing resources increases the duration. |
Fixed Duration |
Assigning additional resources decreases the unit value of each resource; reducing resources increases the unit value of each resource. |
Summary Tasks |
Summary tasks can’t be set to Effort Driven. |
Estimating Effort and Duration
Developing accurate estimates — whether for resources, durations, or costs — is one of the most challenging and contentious parts of managing a project. You should understand the nature of estimating and the difference between the effort needed to accomplish the work and the duration, which indicates the number of required work periods (task duration). Several techniques are available to help you develop estimates, depending on the nature of the work. You can start by looking at the difference between effort and duration and then at the skills you need to develop accurate estimates.
Effort is number of labor units required to complete a task. Effort is usually expressed as staff hours, staff days, or staff weeks.
Duration is the total number of work periods (not including holidays or other nonworking periods) required to complete a task. Duration is usually expressed as workdays or workweeks.
Estimating techniques
Sometimes, people seem to estimate durations by snatching them out of the air or consulting a Magic 8 Ball. Estimating is undoubtedly an art and a science. The art stems from the expert judgment that team members and estimators bring to the process. Their experience and wisdom from past projects are invaluable in developing estimates, determining the best estimating method, and evaluating estimates (or the assumptions behind them) to assess their validity. In addition to the artful contribution of experts, team members, and estimators, a number of methods comprise the science of estimating. I discuss three of the more common methods in this section.
Analogous estimating
Analogous estimating is the most common method of estimating. The aforementioned experts normally conduct this form of estimating. In its most basic form, this method compares past projects with the current project, determines their areas of similarity and areas of difference, and then develops an estimate accordingly.
A more robust application determines the duration drivers and analyzes the relationship between past similar projects with the current project. Duration drivers can include size, complexity, risk, number of resources, quality, or whatever other aspects of the project influence duration.
If you want to use analogous estimating effectively, your projects must be similar in fact, not simply similar in appearance. A software upgrade may sound similar to someone who is not familiar with software, but there are vast differences in what a software upgrade entails, so one software upgrade is not necessarily similar to others. The difference between moving from Windows 7 to Windows 10, for example, is much different from moving from Project 2016 to Project 2019; the magnitude of the work and, thus, the time is different!
Parametric estimating
Parametric estimating uses a mathematical model to determine project duration. Though not all work can be estimated using this method, it’s quick and simple: Multiply the quantity of work by the number of hours required to accomplish it. For example, if a painter can paint 100 square feet per hour and you have 6,000 square feet to paint, you can assume 60 hours of effort. If three people are painting (60 ÷ 3), the task should take 20 hours, or the equivalent of 2.5 days.
Three-point estimating
When a lot of uncertainty, risk, or unknown factors surround an activity or a work package, you can use three-point estimating to produce a range and an expected duration. In this method, you collect three estimates based on these types of scenarios:
- Best case: In this optimistic (represented by the letter O) scenario, all required resources are available, nothing goes wrong, and everything works correctly the first time. You might see this type represented instead as to (for time optimistic).
- Most likely: The realities of project life are factored into the estimate, such as the extended unavailability of a resource, a work interruption, or an error that causes a delay. The most-likely (or M) scenario can also be represented by tm (time most likely).
- Worst case: This pessimistic (P) estimate assumes unskilled resources, or insufficient resources, a great deal of rework, and delays. It’s represented by tp (for time pessimistic).
The simplest way to develop the expected duration, or te (time expected) is to sum the three estimates and divide by 3. However, this technique isn’t the most accurate one because it assumes — unrealistically — an equal probability that the best-case, most-likely, and worst-case scenarios would occur. In reality, the most-likely estimate has a greater chance of occurring than either the best-case or worst-case scenarios. Therefore, weight the most-likely scenario and determine the weighted average.
The most common way to calculate the weighted average is:
te = (to + 4tm + tp) ÷ 6
Setting the task duration
Most tasks in a project (except milestones) have a duration, whether it’s ten minutes or a year or another span of time. The needs of your project and the degree of control you require determine how finely you break down your tasks.
If your project is to launch a satellite, for example, tracking the task duration by minutes on launch day makes sense. In most other circumstances, tracking the duration by days (or weeks, sometimes) is sufficient.
As with all task information, you can enter the duration in a Gantt Chart sheet or in the Task Information dialog box. Follow these steps to enter the duration in the dialog box:
- Double-click a task to display the Task Information dialog box.
- If necessary, click the General tab to display it.
- In the Duration box, use the spinner arrows to increase or decrease the duration, as shown in Figure 5-2.
If the current duration units aren’t appropriate (for example, days when you want hours), type a new duration in the Duration box.
A new task is created with an estimated duration of one day unless you change the duration. You can use these abbreviations for various time units:
- m: Minute
- h: Hour
- d: Day
- w: Week
- mo: Month
Don’t assume that changing the start and finish dates of a task changes its duration; it doesn’t. You have to manually change the duration. If you don’t, your project plan won’t be what you intended.- Click the OK button to accept the duration setting.
FIGURE 5-2: Setting the duration.
If you’re unsure about the timing of a particular task, select the Estimated check box (on the General tab) when you enter the duration. This strategy alerts people to your lack of certainty. You can always go back and uncheck the box when you have better information.
Controlling Timing with Constraints
In Project, constraints are timing conditions that control an automatically scheduled task. You tell Project which (if any) constraints are required for each task. Because manually scheduled tasks must follow the start and finish dates you specify for them, they already have de facto constraints.
Understanding how constraints work
When you create a task and set it to be automatically scheduled, the As Soon As Possible constraint is selected by default. In other words, the task starts as soon as the project starts, assuming that no dependencies with other tasks exist that would delay it.
A task’s start and finish dates, task dependencies, task type, Effort Driven setting, and constraints all work together to set the timing of each task. However, when Project performs calculations to save you time in a project that’s running late, constraint settings are considered sacred (untouchable). For example, if you set a constraint that a task must finish on a certain date, Project shifts almost any other scheduled task to recalculate the timing before suggesting that the task might finish on another date.
The excessive use of constraints limits your scheduling flexibility. Use constraints only when you absolutely need to force a task’s timing.
Table 5-2 describes the effects of constraints on a task’s timing.
TABLE 5-2 Task Constraints
Constraint |
What Happens When You Apply It |
As Soon As Possible |
The task starts as early in the schedule as possible based on dependencies, calendars, and the project start date. (It’s the default setting.) |
As Late As Possible |
The task occurs as late as possible in the schedule, based on dependencies, calendars, and the project’s finish date. |
Finish No Earlier Than |
The end of the task can occur no earlier than the date you specify. |
Finish No Later Than |
The end of the task can occur no later than the date you specify. |
Must Start On |
The task must start on an absolute date. |
Must Finish On |
The task must finish on an absolute date. |
Start No Earlier Than |
The task can start no earlier than the date you specify. |
Start No Later Than |
The task can start no later than the date you specify. |
Establishing constraints
To set a constraint, you select the type of constraint you want in the Task Information dialog box. Though you can set only one constraint for a task, some constraints work together with a date you choose. For example, if you want a task to start no later than a certain date, you select a date by which the task must start. Other settings, such as As Soon As Possible, work from a different date — in this case, the start date you set for the whole project or any dependency relationships you set up with other tasks. (See Chapter 4 for more about dependency relationships.)
To set a task constraint, follow these steps:
Double-click a task.
The Task Information dialog box appears.
- Click the Advanced tab.
- Select a constraint from the Constraint Type list (see Figure 5-3).
- If the constraint requires a date, select one from the Constraint Date list.
- Click the OK button to save the settings.
FIGURE 5-3: Setting a constraint.
The default constraint, As Soon As Possible, is already set, so you usually don’t need to modify it.
Setting a deadline
Sometimes I think that deadlines were made to be overlooked. Project agrees because, strictly speaking, deadlines aren’t constraints (though the setting for the deadline is in the Constrain Task area of the Task Information dialog box, on the Advanced tab). Deadlines, which aren’t the same as constraints, don’t force the timing of task schedules. If you set a deadline and the task exceeds it, Project simply displays a symbol in the Indicator column to alert you so that you can panic — I mean, take action — appropriately.
To set a deadline, follow these steps:
Double-click a task.
The Task Information dialog box appears.
- Click the Advanced tab.
Click the drop-down arrow in the Deadline field (shown in Figure 5-4) to display a calendar and then select a date.
If necessary, click the forward- or backward-facing arrow to move to a different month.
- Click the OK button to save the deadline setting.
FIGURE 5-4: Setting a deadline.
Display a Deadline column in the Gantt Chart sheet pane to enter the deadline or to show yourself and others your targeted deadline date.
Starting and Pausing Tasks
When most people start using Project, they initially try to enter a start date for every task in the project. After all, you include dates when you create to-do lists, right? You’re jumping the gun, though, and missing out on one of the great strengths of project management software: the capability to schedule tasks according to sometimes-complex combinations of factors, such as dependencies between tasks and task constraints. By allowing Project to determine the start date of a task, you allow it to make adjustments automatically when changes occur.
If you enter a task duration but not a start date for an automatically scheduled task, that task starts by default as soon as possible after the project start date that you specified in the Project Information dialog box, based on any dependencies you set up between tasks. For manually scheduled tasks, you eventually have to specify a start date to set the beginning schedule for the task.
Certain tasks, however, must start on a specific date. Examples are holidays, annual meetings, and the first day of the fishing season.
Project sets the finish date of a task based on when the task starts, the task duration, the task type, the resources assigned, and any calendars that have been set up (more about calendars in Chapter 8). If a task must finish on a certain date, however, you can set a finish date and let Project determine the start date.
Entering the task’s start date
Setting a start date or a finish date for a task applies a kind of constraint on it that can override dependency relationships or other timing factors. A task constraint is the preferred way to force a task to start or end on a certain day. If you determine, however, that a particular task must begin or end on a set date no matter what, you can enter a specific start or finish date. Setting the start or finish date is simple.
To enter a start or finish date for a task, simply follow these steps:
Double-click a task.
The Task Information dialog box appears.
- Click the General tab, if it’s not already displayed.
Click the drop-down arrow at the end of the Start box or the Finish box.
A calendar appears as shown in Figure 5-5.
Click a date to select it, or click the forward- or backward-facing arrow to move to a different month and select a date.
If the current date is the date you want, take a shortcut and click the Today button on the drop-down calendar.
- Click the OK button.
FIGURE 5-5: Setting a start or end date.
When Project determines timing, a Must Start On constraint overrides the start date that is calculated based on start dates and durations.
Taking a break: Splitting tasks
Did you ever start a task — filing your taxes, for example — and find that you simply had to drop everything before you were done and go do something else? (In the case of filing my taxes, I usually need a break for a good cry.)
Projects work the same way. Sometimes, tasks start and then have to be placed on hold before they can start again later — for example, if you experience a work shutdown caused by labor negotiations. Or perhaps you can anticipate a delay in the course of a task and you want to structure it that way when you create it. In this case, you can use a Project feature to split a task so that a second or third portion starts at a later date, with no activity in the interim. You can place as many splits in a task as you like.
Follow these steps to split a task:
On the Task tab of the Ribbon, click the Split Task button in the Schedule group.
A readout appears and guides you as you set the start date for the continuation of the task.
- Move the mouse pointer over the taskbar on the Gantt chart, and adjust the pointer’s position until the box displays the date on which you want to start the task split; then drag to the right until the box contains the date on which you want the task to begin again.
Release the mouse button.
The split task shows up as a short task, a series of dots, and then the rest of the task, as shown in Figure 5-6.
FIGURE 5-6: Splitting a task.
To rejoin a split task, place the mouse cursor over the taskbar until the move cursor appears, and then drag the split taskbar backward to join with the other portion of the taskbar.
Don’t use the split-task approach to place an artificial hold on a task until another task is complete. Suppose that you start testing a product and then have to wait for approval before finalizing the test results. In this case, create a Testing task, a Final Approval milestone, and a Finalize Test Results task — and then create dependency relationships among them. This way, if a task runs late, your final task shifts along with it instead of being set in stone (as a split task can be).