Assumptions

Vertex42 The Excel Nexus

Professional Excel Templates

Get Instant Access

Assumptions underlie every project plan. No matter how much detail you put into the project specifications, there are always lower-level assumptions underlying that detail. There are always influences that could affect the course of your project about which you have made some (often-unstated) assumptions. Project plans should identify the key assumptions necessary to provide reasonable estimates of the project-task parameters: the resources required and task duration. For example, an assumption for a construction schedule may relate to the weather (e.g., no more than six days of outside work lost due to inclement weather). An assumption might address actions outside the direct control of the project (e.g., permit review time by regulatory agency not to exceed 30 days). You should identify these assumptions while developing the work packages.

Work package WBS number:__Work packa9e deliverables:

Work package title:_

Work package assumptions:

Work package assumptions:

Figure 5.4 The work-package logic provides essential input to create the project plan.

You should try to counter two frequent tendencies in writing assumptions. One is to attempt to assume everything as a substitute for doing the necessary planning work. This may lead to long lists of assumptions, which you can summarize as, we're not responsible for anything. Limit your assumptions to those necessary to create an effective plan. The second frequent tendency is to write assumptions in the negative (i.e., to specify what the project will not do or what is not in the scope of the project, rather than specify specific project deliverables). Cover this instead with a positive general statement that says, "Project deliverables include only the specified items."

5.7.2 Project Network

The most important part of the work-package documentation is the network input. Note that the network input does not carry dates. It provides activity duration and logic and specifies resource requirements for the activities. One reason you should not input dates to the network is that the dates cannot be developed until the network is put together and the critical chain developed. Date constraints can prevent your schedule software from calculating the critical chain (or path), or they can distort the calculation. Also, dates assigned to individual tasks have a zero probability because all tasks are variable, and it is impossible to predict the output of one trial of a statistical variable. Your software will calculate early and late start and finish dates for each task. Then, you should completely ignore those dates. I never display the individual task-date columns.

I have seen several companies put the project-input format into the hands of budget personnel who create forms that are budget-request spreadsheets. Planners have to develop the schedule separately and figure out how to make them match. Use the work package as designed, and let the computer determine the schedule and spread the budgets for you. Task dates and budget spreadsheets are outputs from the integrated cost-schedule system, not inputs. Of course, in critical chain we are not interested in most of the task dates anyway; we are only interested in the start date of chains of tasks and the completion date of the project.

5.7.2.1 Project Logic

The project logic defines the necessary sequence of tasks to achieve the project result. Work packages are simply small projects: each requires its own logic. You must link tasks so that the output of one task comprises the input of the next task. You can think of each project task as a little work process, with inputs and outputs. Project tasks conform to the TQM supplier^input^process^output^customer (SIPOC) model. The supplier is the task manager of the predecessor task. The customer is the task manager of the successor tasks. You then link work packages using milestones and other task links.

The most common task logic links the finish of one task to the start of the next (output to input). The most common relationships, or links, available in most schedule software are

• Finish-to-start: Often called the predecessor-successor relationship, this clearly illustrates how the output of one task is required as the input to start the next task in the sequence. Most of your network tasks should use finish-to-start relationships.

• Start-to-start (with a lag): Use this relationship when two tasks can be carried out simultaneously, once the first task has created some amount of output for the second task to work on. For example, you may have to create many copies of something that requires three steps. Rather than schedule all three steps for every copy, you put in one task for each of the steps, titled something like "Step 1 for 100 copies of x," "Step 2 for 100 copies...," and so forth, with each step lagging by the amount of time necessary to complete the first item.

• Finish-to-finish: Use this relationship when things must finish at the same time but may have different start times. For example, you need a number of chapters for a book to have all of their cross-references match.

Computer schedule software frequently offers a host of other possible constraints, including fixed-date constraints. The software also allows you to specify leads or lags on the relationships connecting tasks. You should apply these other constraints as little as possible, as people often lose track of them, and they can cause unexpected results when calculating a project network.

Some critical-chain software only allows finish-to-start relationships and/or one or two other types (e.g., start no earlier than). They may not allow leads and lags. If special situations demand it, you usually can model a situation that meets your needs with only regular tasks and finish-to-start relationships, although it may require some dummy tasks to do so. Be sure to understand the capabilities of your software.

Except for fixed-date requirements (e.g., a project with a specific date, such as an Olympic stadium) and nonnegotiable input dates (e.g., available funding), dates should be an output of your network calculation, not an input to it. You should not date-constrain the individual tasks in your network. You should link them and let the software do the calculation. Remember: the dates assigned to individual project tasks by the software all have a probability of zero. Individual task dates are meaningless.

You should check your project logic, considering the following points:

• Does each task have a clearly defined output?

• Are the predecessors to each task necessary to start the task?

• Are the predecessors to each task sufficient to perform the task?

• Do the tasks (collectively) provide for all of the project deliverables as outputs (compared to the WBS)?

• Do the tasks specify the necessary resources?

• Do the tasks have unnecessary date constraints?

• Are all of the milestones on the milestone-sequence chart included?

• Are the resources that determine task duration working at 100% utilization?

• Do all of the project-network paths tie in to the end of the project? (If not, tie them in at least to a milestone for "Project Complete.")

Do not link summary tasks in a project plan. Link the subtasks underneath the summary tasks. The next chapter describes how to create the critical-chain plan from this resource-loaded project network.

5.7.2.2 Resource-Loading Your Network

Once you have determined the tasks required to produce your project deliverables (the network), you must specify the resources required to make each task output. Although conventional project management has always allowed for, and in many cases encouraged, integrating the resource requirements with the schedule network, critical chain absolutely requires it. Critical chain is going to adjust the duration of the project-task network to match the demanded resources to those you tell it are available.

You have to make several decisions when assigning resources within your schedule software. First, you have to decide what resources you are going to identify. You usually have to identify the human resources needed for the tasks, but most of the scheduling software does not require that a resource be a person: it can be a machine (e.g., a crane), or it can be any other constraint (e.g., the hatch on a submarine or a space limitations on how many people can work in a certain area). You should only include those that are likely to be limiting to your schedule.

For human resources, you have to decide if you are going to identify individuals by name or by skill type. If you have a small group working on your project, you can identify the specific individuals that will do the work. Larger organizations and projects may have many individuals who can do certain kinds of work. In those cases, you increase flexibility (and may accelerate the project) by assigning resources by skill type and specifying how many resources of that skill the task can reasonably use. For reasons that will be clarified later, you should generally put down the maximum number of people who can efficiently work on a task and reduce the estimated task duration accordingly.

The critical-chain relay-racer task approach encourages you to fully dedicate the resource(s) that determine the overall duration of a task to that task. You may assign other resources at a fractional level, but be aware that this may cause unexpected results when you resource-level your network. Your digital computer will resource-level to an algorithm with specific rules. Some of these rules may be user adjustable, but once set, the software applies them ruthlessly. Thus, if you load a secondary resource at 49% to two tasks and have 100% of the resource available, the scheduling software may schedule them in parallel. If you assign the resource at 51%, it may delay one of the tasks completely until the other is done. (Some of the scheduling-software algorithms enable leveling over user-selectable "buckets" of time, for instance, days, weeks, or months. Thus, whether the surface moves a task to it level resources can depend on the task length and location in the schedule, as well as the resource loading.) Figure 5.5 illustrates a potential unintended consequence of resource leveling. Something like this actually happened on a critical-chain project, and the technical people claimed, "The logic is wrong!" The logic is correct, and the computer did exactly as instructed. In this case, they probably should not have resource-loaded the review task unless it was a full-time task assignment for the resources. In most software, you can include task notes to specify who should review a deliverable. Usually it takes some experimentation and experience to determine how best to model resources in your particular project plans.

ID

Task Name

May 23, '04

May 30, '04

Jun 6, '04

S M T W T 1

FS

S M T |W T F S

S |M T W T F

1

Resource 1 Task1

1 h Resource 1

+ Resource 1

2

Resource 1 Task 2

|T 1

3

Resource 2 Task 1

t Resource 2

4

Resource 2 Task 2

1 1

5

Draft Document

1 H

Resource 3

6

Review Document

r—I Resource 1[10%], Resource 2[10%], Resource 3

Task Name

Resource 1 Taskl

Resource 1 Task 2

Resource 2 Task 1

Resource 2 Task 2

Draft Document

Review Document

Resource 1

Resource 2

Resource 3

Resource 1

Resource 2

Figure 5.5 Example of resource leveling causing an unexpected result: (a) before leveling;(b) after leveling: the document review gets displaced to the right due to 10% loading of resource.

Many project plans contain thousands of individual tasks. Some contain tens of thousands. Guidance on how many tasks to include in a project network usually suggests breaking down tasks into minor durations to facilitate project reporting by task completion, rather than using estimates of percentage complete or time remaining. Consideration of the purpose of the project plan and the TOC leads to the recommendation that project plans be only as detailed as you need to run your project successfully and no more. Project tasks generally should represent a hand off of a specific artifact from one resource (or group of resources) to another.

Project plans are not a substitute for detailed design information. You can link such information to your schedule by a number of means, including using the WBS as a file structure for such information, task notes, and hyperlinks in your schedule software (depending on your software). Avoid the temptation to use your schedule software for other than schedule management. Your highest-level project plans should only rarely exceed a few hundred activities. Larger projects require a hierarchy of plans, where no individual plan contains more than a few hundred activities. In these cases, you should link from lower-level plans to the higher-level plan at the start of the lower-level-plan project buffer.

The primary reason to limit the number of tasks in a project plan is that overall uncertainty does not justify too much detail. Too much detail increases the work to create and maintain the plan, as well as the probability of errors in the plan. Very few people can understand a plan with more than a hundred activities, even with study. Since the number of potential links in a plan increase exponentially with the number of tasks, it is highly unlikely that a plan with even a hundred activities will be error free.

Consider the fact that the average size of a task (in terms of dollars, total path time, or total resource time) is the inverse of the number of tasks in the plan. Therefore, the average size of a task in a plan with one hundred activities is 1% of the total project. Since most of the tasks can be estimated with accuracy no better than ±50 to serveral hundred percent, it makes little sense to divide the project into smaller and smaller pieces.

People often suggest that an insufficiently detailed plan is a cause of project failure. When projects "fail," they usually do so in the range of several hundreds of percent, (i.e, cost two or three times the initial estimate) not fractions of one percent. It is not logical to conclude that plans with one hundred or more activities are not detailed enough to prevent project failure. You are not likely to find missing pieces that add up to hundreds of percentage points by subdividing chunks that average only 1% of the total. The problem is elsewhere, and so is the solution.

More tasks increases the amount of effort required to develop the project plan. A given planning effort spread over more tasks means less effort per task. This may lead to a less accurate plan, not a more accurate plan. If you have the ability to put in more planning effort, you should apply it to looking at the spaces between the tasks, ensuring that all of the inputs and outputs are correct and considering the resources and processes within the tasks, rather than adding tasks to the project plan.

For statistical reasons, there is value in ensuring that the critical chain of your plan contains at least ten activities. This increases the chances that statistical fluctuations will tend to offset each other. Also, no single activity duration should exceed 20% of your critical chain. If one task dominates the critical chain, you are more subject to variation in that individual task, and you are more vulnerable to inaccurate estimates of the time to complete. Consider defining intermediate deliverables to divide a dominant task.

On the other hand, if you have many tasks on a path, and several tasks in sequence use the same resource, consider combining those tasks and defining the final deliverable as the task output.

The above considerations (number and relative size of activities) apply to both feeding chains and the critical chain, but they are a little less important on feeding chains because the schedule protects feeding chains with both the feeding buffer and the project buffer.

Was this article helpful?

0 0
Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook


Post a comment