|< Day Day Up >|
Activity Planning-From WBS to Project Schedule
The next section of the planning processes address those steps required to develop the project schedule. This is the part of the project plan that might be most familiar to new project managers. Many automated project management tools help create schedules by keeping track of activities, resources, durations, sequencing, and constraints. Although the schedule is an integral part of the project plan, it is only one part. Don't start working on the schedule until you have a proper WBS. Starting to work before completing the WBS usually results in doing more work than is necessary. A good WBS reduces task redundancy and helps ensure all work performed is in the scope of the project. In fact, the WBS is a required input to activity planning.
The first process in the activity planning section is activity definition. This process starts with the WBS and identifies the activities required to produce the various project deliverables. Activities are viewed from the perspective of the work packages. You ask the question, "What activities are required to satisfy this work package requirement?" The resulting information from this process is used next to organize the activities into a specific sequence. Table 3.5 shows the inputs, tools, techniques, and outputs for the activity definition process.
Sometimes it is difficult to know everything about a project during the planning stage. It is common to learn more about the project as you work through the project life cycle. This is called progressive elaboration and it affects the planning process. If you don't know everything about the project, you can't plan the whole project to the level of detail necessary. For large projects, it is common to plan the entire project at a high level. The project starts with detailed plans in place for the work packages that are near the beginning of the project. As the time draws near to begin additional work, the more detailed, low-level plans for those work packages are added to the project plan. The planning process is revisited multiple times to ensure that the detailed plans contain the latest information known about the project. This practice is called rolling wave planning because the planning wave always moves to stay ahead of the work execution wave.
The next process is that of arranging the activities list from activity definition into a discrete sequence. Some activities can be accomplished at any time throughout the project. Other activities depend on input from another activity or are constrained by time or resources. Any requirement that restricts the start or end time of an activity is a dependency. This process identifies all relationships between activities and notes restrictions imposed by these relationships.
For example, when building a car you cannot install the engine until the engine has been built and delivered to the main assembly line. This is just one simple example of how activities may be dependent on one another. This process is one that can benefit from the use of computer software to assist in noting and keeping track of inter-activity dependencies. Table 3.6 shows the inputs, tools, techniques, and outputs for the activity sequencing process.
One of the more important topics to understand when planning project activities is creating network diagrams. Network diagrams provide a graphical view of activities and how they relate to one another. The PMP exam tests your ability to recognize and understand two types of network diagrams: the precedence diagramming method (PDM) and the arrow diagramming method (ADM). Make sure you can read each type of diagram and use the information it presents.
Precedence Diagramming Method
The PDM shows nodes, representing activities, connected by arrows that represent dependencies. To represent that activity B is dependent on activity A (in other words, activity A must be complete before activity B starts), simply draw an arrow from A to B. PDM diagrams are also referred to as activity-on-node (AON) diagrams because the nodes contain the activity duration information. (You don't have enough information yet to complete all the information presented here. You'll fill in the duration information during activity duration estimating.) In fact, nodes generally contain several pieces of information, including
Figure 3.3 shows an example of a PDM diagram.
Figure 3.3. The precedence diagramming method.
The PDM diagram in Figure 3.3 shows eight activities, labeled A-H. The arrows show how some activities are dependent on other activities. For example, activity B cannot start until activities A and C are complete. To show this dual dependency, you draw an arrow from A to B and another arrow from C to B.
You can represent four types of dependencies with a PDM diagram:
Arrow Diagramming Method
The arrow diagramming method (ADM) is similar to the PDM, except that all dependencies are finish-to-start. Also, durations are generally depicted on the arrows. For this reason, the ADM diagram is also called the activity-on-arrow (AOA) diagram. Figure 3.4 shows an example of an ADM diagram.
Figure 3.4. The arrow diagramming method.
The ADM diagram in Figure 3.4 shows 11 activities, labeled A-K. Unlike the PDM diagram, activities are labeled on the arrow, not the nodes.
Dependencies are noted in a similar fashion to the PDM diagram, but there is another type of activity in ADM diagrams. Look at the dependency between node 3 and node 2. The arrow has a dotted line, which means the activity has no duration and is called a dummy activity. The purpose of dummy activities is simply to allow you to depict dependencies. In Figure 3.4 activity C cannot start until activity E has completed. Likewise, activity G cannot start until activity I has completed.
After you are comfortable with the main types of network diagrams, you need to understand how to use them. Let's talk about a few basic scheduling concepts and look at how network diagrams help you understand project schedules, starting with a few project tasks. Table 3.7 lists the tasks for a project along with the predecessors, duration, and earliest start date.
Now use the sample PDM node template to create a PDM diagram for the project. Figure 3.5 shows the sample PDM node template.
The completed network diagram should look like the diagram in Figure 3.6.
Figure 3.6. The completed sample PDM diagram.
Estimating Activity Resources
Now you have a list of activities and their relative dependencies. The next process associates activities with the resources required to accomplish the work. This process lists each type and amount, or quantity, of each required resource. Every activity requires resources of some sort. Activity resources can include
Table 3.8 shows the inputs, tools, techniques, and outputs for the activity resource estimating process.
Two of the tools and techniques warrant further discussion. One of the techniques you use when estimating activity resources is alternative analysis. Analyzing the various alternatives provides an opportunity to consider other sources or ways to achieve the desired result for an activity. Alternatives might be more desirable than the initial expected approach due to cost savings, higher quality, or earlier completion. Another important outcome of alternative analysis is that in case the primary source becomes unavailable, you might have already identified a replacement method to complete the work. Suppose your main supplier of industrial fittings suffers a catastrophic fire. If your alternative analysis identified another source, you might be able to continue the project with minimal disruption.
The second item is bottom-up estimating. Recall that one of the purposes of creating the WBS is to decompose project work into work packages that are small enough to reliably estimate for duration and resource requirements. Using the WBS, you can provide estimates for mid- and high-level work by aggregating the estimates for the work packages that make up the desired work. Because this process starts at the lowest level of work (the work package) to create the estimate, it is called bottom-up estimating. This type of estimating tends to be fairly accurate because the estimates come from the people doing the actual work. The alternative is top-down estimating. Topdown estimates generally come from management or a source that is higher up than the people actually doing the work. The estimates are really educated guesses on the amount of resources required for a collection of work packages and tend to be less reliable than bottom-up estimates.
Estimating Activity Durations
After the resource estimates are established for each of the activities, it's time to assign duration estimates. The activity duration estimating process assigns the number of work periods that are needed to complete schedule activities. Each estimate assumes that the necessary resources are available to be applied to the work package when needed. Table 3.9 shows the inputs, tools, techniques, and outputs for the activity duration estimating process.
In addition to expert judgment, three main techniques are used for project activity duration estimation. In many cases, using multiple techniques provides more accurate estimates. The three estimation techniques are
Developing the Project Schedule
The next step is to develop the actual project schedule. The schedule development process pulls all of the activity information together and results in the project's initial (baseline) schedule. As work is iteratively planned and accomplished and the project moves through its life cycle, changes to the schedule will likely occur. The schedule is a dynamic document and requires constant attention on the part of the project manager to ensure the project stays on track. Table 3.10 shows the inputs, tools, techniques, and outputs for the schedule development process.
An important topic to understand with respect to project schedules is the critical path. Look back at the AON diagram in Figure 3.3. The critical path is the longest path from start to finish. It is calculated by adding up all of the durations along each path from start to finish. The reason it is called the critical path is that any delay (or increase in duration) of any activity on the critical path causes a delay in the project. It is critical that all activities on this path be completed on schedule.
Using the network diagram in Figure 3.6, you can calculate the project critical path. The critical path is the route with the longest total duration. This example shows two routes from task A to task G:
From this diagram you can see that the longest path is A-B-D-F-G, and that is your critical path. Any delays in any of these tasks will delay the project.
Take another look at Figure 3.6. This PDM diagram has several pieces of information filled in for each node that we have not discussed yet. The task name and duration are self-explanatory. What about the rest of the information, though? The main task of developing the project schedule is to relate each of the tasks and combine duration, resource requirements, and dependencies. You will need to make several passes through the network diagram to calculate the values necessary to create a project schedule.
In general, you will make two main passes through each path in your network diagram. The first pass starts with the initial project task (the project start task). The starting date of the initial task is its early start date. A task's early start date is the earliest you can start working on that task. In Figure 3.6, the early start date for task A is 9/5/05. The duration for task A is 5 days, so the earliest task A can finish is 9/10/05. To get the early finish date, just add the duration to the early start date. Now, the early finish date for task A becomes the early start date for any tasks that are dependent on task A (namely, task B and task C). Then, continue to follow each path until you reach the final task, calculating the new early end dates by adding the duration to the early start dates.
Now it's time for the second pass through your project to calculate the late start and late ending dates. This pass starts at the end and moves backward through the same paths you just followed in the forward pass. The first step in the backward pass is to record the late ending date. It is the same as the early ending date for the last task in the project. Then, subtract the duration to get the late start date. In Figure 3.6, the late ending date for task G is 9/22/05 and the late start date is 9/20/05. Next, move backward to each task on which your current task depends (for example, each task that has an arrow pointing to your current task). The late ending date for this predecessor task is the same as the late start date of the dependent task. In other words, the late ending date for task F and task E would be 9/20/05 (the late start date for task G). Continue backward through the project, subtracting the duration to calculate a new late start date.
After completing both the forward and backward passes, you should have all the early start times (ESTs), early finish times (EFTs), late start times (LSTs), and late finish times (LFTs) filled in. To complete the network diagram entries, calculate the float for each task by subtracting the early start date from the late start date. The float represents the amount of time each task can be delayed without delaying the project.
Finally, add up the durations for each path from the start task to the finish task. The smallest total represents the critical path of your project-there could be more than one critical path. Remember that tasks on the critical path all have a float of 0 and any delay of a task on the critical path results in an overall project delay.
|< Day Day Up >|