PMP Exam Cram: Examine Project Planning
Date: Nov 24, 2014
In Chapter 1, “Project Management Framework Fundamentals,” we introduced the PMI concepts of processes, process groups, and knowledge areas. Recall that PMI defines a total of 47 project processes that describe activities throughout a project’s life cycle. These processes are organized into 10 knowledge areas and represent 5 process groups. One of the most prominent of the process groups is project planning. Over half of the processes occur in this group; 24 of the 47 processes are in this group. You might think that planning processes are localized to a particular area of your project, but note that processes in the planning group span all 10 knowledge areas. Let’s look at project planning in more detail.
Understanding PMI’s Planning Process Group
- Planning Process—3.4
After you have completed the initiating processes, you are ready to start planning your project. Remember what that means? It means that you possess formal authorization to conduct the work of the project. But you don’t know what to do without a plan. Planning answers a few very important questions, such as What work will you do? and What exactly are you trying to accomplish?
To answer these questions, start from what you know. There are two outputs from the initiating process group processes. Always start with the information necessary to proceed. Recall that PMI refers to this initial information for each process as the process’s inputs. There are two outputs from the initiating processes:
- The project charter
- The stakeholder register
Armed with these initiating documents, you can start the planning processes. In a nutshell, you follow each of the planning processes to refine the project documents from these outputs. As you develop the planning documents, always remember how the various processes are related.
Think of the initiating process group as the processes that answer the “what” and “why” questions. The planning processes answer the “how” questions. The planning processes result in outputs that explain how the project will progress toward reaching its goals.
Figure 4.1 shows how the processes in the planning group are related in the PMBOK Guide, Fifth Edition.
FIGURE 4.1 The planning process group process interactions.
PMI is explicit in stressing the importance of planning. Far too many projects suffer from the poor practice of starting work before anyone really knows what needs to be done. This almost always results in wasted effort and lost time. Proper planning requires good communication among the team and sound leadership from the project manager. The result of solid planning is a project team that is more informed and prepared to carry out the work required to meet the project’s goals. You should expect to see several questions on the exam that require you to understand the importance of fully planning before starting work.
Because planning is such a large process group, the material is divided into two separate chapters. This chapter covers the general concepts of planning and the processes that relate to the development of project baselines, including the following topics:
- Integration
- Scope
- Time
- Cost
Chapter 5, “Explore More Elements of Project Planning,” covers the remaining project planning processes that support project planning by applying more details to the baselines. Topics covered in Chapter 5 include these:
- Communications
- Risk
- Quality
- Procurement
- Human resources
- Stakeholders
The main purpose of planning is to provide a framework to gather information to produce a project management plan. In fact, the plan itself is really a collection of other plans. The majority of activities in the planning group center around developing the supporting documents that comprise the final project management plan. As more detailed information is learned about the project, the overall plan becomes more complete, and the stakeholders’ confidence in the project increases.
Planning is an iterative group of processes. As a project progresses, it often becomes necessary to modify the plan for a number of reasons. Unexpected results, delays, outside factors, and internal factors can all require additional planning. Any scope changes are likely to require one or more planning processes to be revisited. Don’t assume that planning is accomplished only once. The exam requires that you understand how planning is iterative throughout a project.
The following are some fundamental planning process items you need to understand for the exam:
- Project management plan—One process in the planning group addresses the project management plan. The develop project management plan process is the high-level process that provides direction for developing subsidiary plans and compiling their information into the final project plan.
- Scope—Four processes address scope planning. These direct the refinement of the preliminary scope statement and break down the high-level goals of the project into smaller, more manageable chunks.
- Activity—Six processes deal with activity planning. After the work of the project is expressed in small, manageable chunks, the activity-related processes focus on defining the activity details, integrating with project resources, and sequencing the project activities.
- Cost—Three processes address cost planning. These processes collect estimates and organize them into a project budget.
We examine each of these processes in the next section.
Integration Management
- Develop Project Management Plan—4.2
The project management plan process covers all activities that identify and direct the actions of many other processes in the planning process group. Developing the project management plan includes coordinating the development of the subsidiary plans and incorporating them into the complete project plan. The main purpose of the project management plan is to define how the project is to progress from its beginning to completion.
In short, the project management plan provides the high-level game plan for how the project moves through its life cycle. PMI defines many potential subsidiary plans that make up the overall project management plan. These subsidiary plans provide the specific details for managing each aspect of the project from initiation through closure. The subsidiary project management plans could include
- Project scope management plan
- Requirements management plan
- Schedule management plan
- Cost management plan
- Quality management plan
- Process improvement plan
- Human resource plan
- Communication management plan
- Risk management plan
- Procurement management plan
One of the most common mistakes inexperienced project managers make is to confuse a project plan with a project schedule. The output from many common project management software packages does not qualify as a project plan. This output is a good start, but a true project plan is made up of much more information than just scheduling information. This process requires a focused effort to create a plan that incorporates all known information about a project. Table 4.1 shows the inputs, tools and techniques, and outputs for the develop project management plan process.
TABLE 4.1 Develop Project Management Plan Inputs, Tools and Techniques, and Outputs
Inputs |
Tools and Techniques |
Outputs |
Project charter |
Expert judgment |
Project management plan |
Outputs from planning processes |
Facilitation techniques |
|
Enterprise environmental factors |
||
Organizational process assets |
Scope Management
- Plan Scope Management—5.1
- Collect Requirements—5.2
- Define Scope—5.3
- Create WBS—5.4
Scope management is the set of processes which ensures that the requirements of the customer are captured in a specification of work that ensures the delivery of the project’s deliverables, that all the project work is done, and that only the work required to complete the project is done. In other words, scope management makes sure that the project is completed without expending any unnecessary effort.
Plan Scope Management
The first process in scope management is a new process, plan scope management. The PMBOK Guide, Fifth Edition, adds several processes to separate the initial planning activities from other activities. While all the processes you will learn about in this chapter relate to planning, the new initial processes in scope management and three other process groups bring attention to the importance PMI places on proper planning. The plan scope management process creates the scope management plan. The scope management plan describes the project scope and documents how it will be further defined, validated, and controlled. This process results in a plan that gives the project team guidance on how to manage the scope throughout the project life cycle. Table 4.2 shows the inputs, tools and techniques, and outputs for the plan scope management process.
TABLE 4.2 Plan Scope Management Inputs, Tools and Techniques, and Outputs
Inputs |
Tools and Techniques |
Outputs |
Project management plan |
Expert judgment |
Scope management plan |
Project charter |
Meetings |
Requirements management plan |
Enterprise environmental factors |
||
Organizational process assets |
Collect Requirements
The second process in the scope management process group is the collect requirements process. This process seeks to use multiple tools and techniques to collect all the project requirements from all the stakeholders. This process attempts to leave no stone unturned and results in a complete list of project requirements. When properly performed, the collect requirements process dramatically reduces surprises as the project moves toward completion. Table 4.3 shows the inputs, tools and techniques, and outputs for the collect requirements process. Pay particular attention to the various creative methods you can employ to develop a list of project requirements.
TABLE 4.3 Collect Requirements Inputs, Tools and Techniques, and Outputs
Inputs |
Tools and Techniques |
Outputs |
Scope management plan |
Interviews |
Requirements documentation |
Requirements management plan |
Focus groups |
Requirements traceability matrix |
Stakeholder management plan |
Facilitated workshops |
|
Project charter |
Group creativity techniques |
|
Stakeholder register |
Group decision-making techniques |
|
Questionnaires and surveys |
||
Observations |
||
Prototypes |
||
Benchmarking |
||
Context diagrams |
||
Document analysis |
Define Scope
The next process, define scope, is a process that clearly states what the project will and will not accomplish. The supporting documents are reviewed to ensure that the project will satisfy the stated goals, and the resulting scope should state the stakeholders’ needs and clearly communicate the expectations for the performance of the project. Table 4.4 shows the inputs, tools and techniques, and outputs for the define scope process.
TABLE 4.4 Define Scope Inputs, Tools and Techniques, and Outputs
Inputs |
Tools and Techniques |
Outputs |
Scope management plan |
Expert judgment |
Project scope statement |
Project charter |
Product analysis |
Project document updates |
Requirements documentation |
Alternatives identification |
|
Organizational process assets |
Facilitated workshops |
Work Breakdown Structure: A Common and Dangerous Omission
Many inexperienced project managers move too quickly from the scope statement to the activity sequencing processes. This practice is a mistake and often leads to activity omissions and inaccurate plans. PMI stresses the importance of creating a work breakdown structure (WBS) before moving to activity management processes.
A WBS provides the project manager and project team with the opportunity to decompose the high-level scope statement into much smaller, more manageable units of work, called work packages. The resulting WBS should provide a complete list of all work packages required to complete the project (and nothing more). Table 4.5 shows the inputs, tools and techniques, and outputs for the create WBS process.
TABLE 4.5 Create WBS Inputs, Tools and Techniques, and Outputs
Inputs |
Tools and Techniques |
Outputs |
Scope management plan |
Decomposition |
Scope baseline (project scope statement, WBS, and WBS dictionary) |
Project scope statement |
Expert judgment |
Project document updates |
Requirements documentation |
||
Enterprise environmental factors |
||
Organizational process assets |
In creating the WBS, the project team repeatedly decomposes the work of the project into smaller and smaller units of work, and the result is a collection of small work packages. The process continues until the resulting work packages are simple enough to reliably estimate duration and required resources. Don’t go overboard, though. When you have work packages that are manageable and each represent a single work effort, stop the process. Each project is different, so this process results in different levels of detail for each project.
The last main feature of the WBS is that it is organized in a hierarchical fashion. The highest level is the project. The children that represent project phases, divisions, or main deliverables are listed under the project. Each child process or task is divided into further levels of detail until the lowest level, the work package, is reached. Figure 4.2 depicts a sample WBS with multiple levels.
FIGURE 4.2 Sample work breakdown structure.
In addition to the WBS itself, another output of the create WBS process is the WBS dictionary. The WBS dictionary is a document that supports the WBS by providing detailed information for each work package. The WBS dictionary can contain many types of information, including
- Work package name or identifier
- Accounting code identifier
- Description of work
- Technical specifications
- Quality requirements
- Owner or responsible party assignment
- Required resources
- List of schedule milestones
- Associated schedule activities
- Cost estimates
- Acceptance criteria
- Contract information
Activity Planning—From WBS to Project Schedule
- Plan Schedule Management—6.1
- Define Activities—6.2
- Sequence Activities—6.3
- Estimate Activity Resources—6.4
- Estimate Activity Durations—6.5
- Develop Schedule—6.6
The next section of the planning processes address the 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 nearly always results in doing more work than is necessary. A good WBS reduces task redundancy and helps ensure that all work performed is in the scope of the project.
Plan Schedule Management
The first process in the time management knowledge area is plan schedule management. This process defines the policies and procedures for planning, managing, and controlling the project schedule. This process provides guidance on how the schedule will be managed throughout the project. All the subsequent processes in the time management knowledge area depend on the plan developed in this process. Table 4.6 shows the inputs, tools and techniques, and outputs for the plan schedule management process.
TABLE 4.6 Plan Schedule Management Inputs, Tools and Techniques, and Outputs
Inputs |
Tools and Techniques |
Outputs |
Project management plan |
Expert judgment |
Schedule management plan |
Project charter |
Analytical techniques |
|
Enterprise environmental factors |
Meetings |
|
Organizational process assets |
Define Activities
The first process in the activity planning section is define activities. 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?” Next, the resulting information from this process is used to organize the activities into a specific sequence. Table 4.7 shows the inputs, tools and techniques, and outputs for the define activities process.
TABLE 4.7 Define Activities Inputs, Tools and Techniques, and Outputs
Inputs |
Tools and Techniques |
Outputs |
Schedule management plan |
Decomposition |
Activity list |
Scope baseline |
Rolling wave planning |
Activity attributes |
Enterprise environmental factors |
Expert judgment |
Milestone list |
Organizational process assets |
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 affects the planning process. If you don’t know everything about a project, you can’t plan the whole project to the necessary level of detail.
For a large project, 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.
Sequence Activities
The next process is 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 example of how activities can be dependent on one another. The sequence activities process is one that can benefit from the use of computer software to assist in noting and keeping track of inter-activity dependencies. Table 4.8 shows the inputs, tools and techniques, and outputs for the sequence activities process.
TABLE 4.8 Sequence Activities Inputs, Tools and Techniques, and Outputs
Inputs |
Tools and Techniques |
Outputs |
Schedule management plan |
Precedence diagramming method (PDM) |
Project schedule |
Activity list |
Dependency determination |
Project documents updates |
Activity attributes |
Leads and lags |
|
Milestone list |
||
Project scope statement |
||
Enterprise environmental factors |
||
Organizational process assets |
Network Diagrams
One of the most important topics to understand when planning project activities is how to create network diagrams. A network diagram provides a graphical view of activities and how they are related to one another. The PMP exam tests your ability to recognize and understand the most common type of network diagramming method: the precedence diagramming method (PDM). Make sure you can read a PDM diagram and use the information it presents.
Figure 4.3 shows an example of a PDM diagram.
FIGURE 4.3 The precedence diagramming method.
Precedence Diagramming Method
A PDM diagram 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. (We don’t have enough information to complete all the information presented here yet. We’ll fill in the duration information during activity duration estimating.) In fact, nodes generally contain several pieces of information, including
- Early start—The earliest date the activity can start
- Duration—The duration of the activity
- Early finish—The earliest date the activity can finish
- Late start—The latest date the activity can start
- Late finish—The latest date the activity can finish
- Slack—Difference between the early start and the late start dates
Figure 4.4 shows an example of a PDM node template.
FIGURE 4.4 The sample PDM node template.
The PDM diagram in Figure 4.3 shows eight activities, labeled A through H, with 13 dependencies. 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, we 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:
- Finish-to-start (the most common dependency type)—The successor activity’s start depends on the completion of the predecessor activity.
- Finish-to-finish—The completion of the successor activity depends on the completion of the predecessor activity.
- Start-to-start—The start of the successor activity depends on the start of the predecessor activity.
- Start-to-finish—The completion of the successor activity depends on the start of the predecessor activity.
Project Task Information
When 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 4.9 lists the tasks for a project, along with the predecessors, duration, and earliest start date.
TABLE 4.9 Project Task Information
Activity |
Predecessor |
Duration |
Earliest Start Date |
A |
None |
5 |
9/5/14 |
B |
A |
2 |
9/10/14 |
C |
A |
3 |
9/10/14 |
D |
B |
7 |
9/12/14 |
E |
C |
4 |
9/13/14 |
F |
D |
1 |
9/19/14 |
G |
E, F |
2 |
9/20/14 |
Now use the sample PDM node template shown in Figure 4.4 to create a PDM diagram for the project.
Your completed network diagram should look like the one shown in Figure 4.5.
FIGURE 4.5 A completed sample PDM diagram.
Estimate Activity Resources
Now you have a list of activities and their relative dependencies. The next process is to associate activities with the resources required to accomplish the work. This process involves listing each type and amount, or quantity, of each required resource. Every activity requires resources of some sort. Activity resources can include
- People
- Equipment
- Materials and supplies
- Money
Table 4.10 shows the inputs, tools and techniques, and outputs for the estimate activity resources process.
TABLE 4.10 Estimate Activity Resources Inputs, Tools and Techniques, and Outputs
Inputs |
Tools and Techniques |
Outputs |
Schedule management plan |
Expert judgment |
Activity resource requirements |
Activity list |
Alternative analysis |
Resource breakdown structure |
Activity attributes |
Published estimating data |
Project documents updates |
Resource calendars |
Bottom-up estimating |
|
Risk register |
Project management software |
|
Activity cost estimates |
||
Enterprise environmental factors |
||
Organizational process assets |
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. Top-down 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.
Estimate Activity Durations
After the resource estimates are established for each of the activities, it’s time to assign duration estimates. The estimate activity durations process approximates the number of work periods that are needed to complete scheduled activities. Each estimate assumes that the necessary resources are available to be applied to the work package when needed. Table 4.11 shows the inputs, tools and techniques, and outputs for the activity duration estimating process.
TABLE 4.11 Estimate Activity Duration Inputs, Tools and Techniques, and Outputs
Inputs |
Tools and Techniques |
Outputs |
Schedule management plan |
Expert judgment |
Activity duration estimates |
Activity list |
Analogous estimating |
Project documents updates |
Activity attributes |
Parametric estimating |
|
Activity resource requirements |
Three-point estimating |
|
Resource calendars |
Group decision-making techniques |
|
Project scope statement |
Reserve analysis |
|
Risk register |
||
Resource breakdown structure |
||
Enterprise environmental factors |
||
Organizational process assets |
In addition to expert judgment and reserve analysis, four main techniques are used for project activity duration estimation. In many cases, using multiple techniques provides more accurate estimates. The four estimation techniques are
- Analogous estimating—This uses actual duration figures from similar activities. These activities can be from the same project or another project but share similarities in budget, size, weight, complexity, or other parameters.
- Parametric estimating—This calculates duration estimates by multiplying the quantity of work by the productivity rate. This type of estimate works best for standardized, and often repetitive, activities.
Three-point estimates—This uses three estimate values for each activity:
- Most likely (t M)—The duration most likely to occur.
- Optimistic (t O)—The duration of the activity based on the best-case scenario.
- Pessimistic (t P)—The duration of the activity based on the worst-case scenario.
This approach originated with the Program Evaluation and Review Technique (PERT). PERT analysis calculates the expected (tE) activity from the three-point estimates by using the following formula:
tE = (tO + 4 * tM + tP) / 6
Triangular distribution—This simple estimating method takes an average of the most likely, optimistic, and pessimistic values. Unlike a three-point estimate, each value receives the same weight. This estimating method assumes that risks are just as likely to be realized as the most likely estimate. You can calculate a triangular distribution by using the following formula:
Average = (tO + tM + tP) / 3
Develop Schedule
The next step is to develop the actual project schedule. The develop schedule process pulls all 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 are likely to occur. The schedule is a dynamic document and requires constant attention on the part of the project manager to ensure that the project stays on track. Table 4.12 shows the inputs, tools and techniques, and outputs for the develop schedule process.
TABLE 4.12 Develop Schedule Inputs, Tools and Techniques, and Outputs
Inputs |
Tools and Techniques |
Outputs |
Schedule management plan |
Schedule network analysis |
Schedule baseline |
Activity list |
Critical path method |
Project schedule |
Activity attributes |
Critical chain method |
Schedule data |
Project schedule network diagrams |
Resource optimization techniques |
Project calendars |
Activity resource requirements |
Modeling techniques |
Project management plan updates |
Resource calendars |
Leads and lags |
Project documents updates |
Activity duration estimates |
Schedule compression |
|
Project scope statement |
Scheduling tool |
|
Risk register |
||
Project staff assignments |
||
Resource breakdown structure |
||
Enterprise environmental factors |
||
Organizational process assets |
An important topic to understand with respect to project schedules is the critical path. In the AON diagram in Figure 4.3, the critical path is the longest path from start to finish. It is calculated by adding all 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.
Critical Path
Using the network diagram in Figure 4.5, you can calculate the project critical path. The critical path is the route with the longest total duration. The critical path method performs a forward and backward pass through the schedule network, calculating the early start and finish dates and the late start and finish dates for all activities, based on durations and relationships. The critical path method does not take into account resource limitations. The critical chain method does consider resource limitations. In short, the critical chain method uses the critical path method output and modifies the schedule network to account for limited resources. In this example, there are two routes from Task A to Task G:
- Path A–B–D–F–G will take 17 days to complete. (Just add up all the durations: 5 + 2 + 7 + 1 + 2 = 17)
- Path A–C–E–G will take 14 days to complete.
From this diagram, you can see that the longest path is A–B–D–F–G, and that is the critical path. Any delays in any of these tasks delay the project.
Float
The PDM diagram in Figure 4.5 has several pieces of information filled in for each node that we have not discussed. The task name and duration are self-explanatory. What about the rest of the information? The main task of developing the project schedule is to relate each of the tasks and combine duration, resource requirements, and dependencies. You need to make several passes through the network diagram to calculate the values necessary to create a project schedule.
In general, you make two main passes through each path in your network diagram. The first pass starts with the initial project task (the project start task). A task’s early start date is the earliest you can start working on that task. The late start date is the latest you can start working on the task. The difference between the early and late start dates is called float. The float is the schedule flexibility of a task. In Figure 4.5, the early start date for Task A is 9/5/14. To get the early finish date, just add the duration to the early start date. The duration for Task A is 5 days, so the earliest Task A can finish is 9/10/14. 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 is 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 4.5, the late ending date for Task G is 9/22/14, and the late start date is 9/20/14. Next, move backward to each task on which your current task depends (that is 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/14 (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 of the early start times (EST), early finish times (EFT), late start times (LST), and late finish times (LFT) 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 is the amount of time each task can be delayed without delaying the project.
Finally, add the durations for each path from the start task to the finish task. The largest 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.
Allocating Resources
In addition to calculating the critical path and critical chain, it might be necessary to address resource limitations. The process of reallocating resources that have been overallocated is called resource leveling. This technique seeks to avoid work stoppage due to limited resources being required by multiple activities. Remember that resource leveling can often change the critical path. Because resource allocation can change the critical path it is often useful to implement another technique: what-if scenarios. A what-if scenario allows the project planners to explore the effect to the critical path of resource availability changes. For example, if you depend on a particular person to complete work on the critical path, what happens if that person becomes ill? Such a question would be part of a what-if scenario.
Project Cost Estimating Factors
- Plan Cost Management—7.1
- Estimate Costs—7.2
- Determine Budget—7.3
Plan Cost Management
The first process in the cost management knowledge area is plan cost management. This process defines the policies and procedures for planning, managing, and controlling project costs. This process provides guidance on how costs will be managed throughout the project, taking into account stakeholder requirements for managing costs. All of the subsequent processes in the cost management knowledge area depend on the plan developed in this process. Table 4.13 shows the inputs, tools and techniques, and outputs for the plan cost management process.
TABLE 4.13 Plan Cost Management Inputs, Tools and Techniques, and Outputs
Inputs |
Tools and Techniques |
Outputs |
Project management plan |
Expert judgment |
Cost management plan |
Project charter |
Analytical techniques |
|
Enterprise environmental factors |
Meetings |
|
Organizational process assets |
Estimate Costs
The estimate cost process associates an expected cost of performing work to each activity. Cost estimates can include labor, materials, equipment, and any other direct costs for project activities. Based on the activity resource and duration estimates, the cost estimates express the cost, normally in monetary amounts, of completing the work of the project. As with all other project documents, the cost estimates can change through the project as conditions change. Different events can cause the cost for any activity to go up or down and may require the cost estimates for the project to change. Table 4.14 shows the inputs, tools and techniques, and outputs for the estimate cost process.
TABLE 4.14 Estimate Cost Inputs, Tools and Techniques, and Outputs
Inputs |
Tools and Techniques |
Outputs |
Cost management plan |
Expert judgment |
Activity cost estimates |
Human resource management plan |
Analogous estimating |
Basis of estimates |
Scope baseline |
Parametric estimating |
Project documents updates |
Project schedule |
Bottom-up estimating |
|
Risk register |
Three-point estimating |
|
Enterprise environmental factors |
Reserve analysis |
|
Organizational process assets |
Cost of quality |
|
Project management software |
||
Vendor bid analysis |
||
Group decision-making |
Cost estimates are compiled into the project budget. You probably recognize several estimating techniques from other processes. Three of the techniques used in the estimate costs process are the same basic techniques used in the estimate activity durations process. The other technique, bottom-up estimating, is also used in the estimate activity resources process. Although they are the same techniques, they are applied to different criteria and bear revisiting.
- Analogous estimating—This uses actual cost values from similar activities. These activities can be from the same project or another project.
- Parametric estimating—This calculates cost estimates by multiplying the quantity of work or result of work, such as square feet or hours, by a known rate, such as $30 per square foot or $45 per hour. This type of estimate works best for standardized, and often repeated, activities.
Three-point estimating—This uses three estimate values for each activity:
- Most likely—The cost most likely to occur
- Optimistic—The cost of the activity if everything goes as planned, or better
- Pessimistic—The cost of the activity in a worst-case scenario
- Bottom-up estimating—This technique calculates cost estimates by adding the costs of each individual work package. The technique starts at the most detailed level and rolls up the costs until a total cost for the project is obtained.
Determine Budget
After you know the costs to accomplish the work of the project, you can create the project budget. The determine budget process aggregates the activity cost estimates into a single document for the project. The resulting project budget expands on the preliminary budget from the project charter and provides far more detail. Table 4.15 shows the inputs, tools and techniques, and outputs for the determine budget process.
TABLE 4.15 Determine Budget Inputs, Tools and Techniques, and Outputs
Inputs |
Tools and Techniques |
Outputs |
Cost management plan |
Cost aggregation |
Cost baseline |
Scope baseline |
Reserve analysis |
Project funding requirements |
Activity cost estimates |
Expert judgment |
Project documents updates |
Basis of estimates |
Historical relationships |
|
Project schedule |
Funding limit reconciliation |
|
Resource calendars |
||
Risk register |
||
Agreements |
||
Organizational process assets |
What Next?
If you want more practice on this chapter’s exam topics before you move on, remember that you can access all of the Cram Quiz questions on the CD. You can also create a custom exam by topic with the practice exam software. Note any topic you struggle with and go to that topic’s material in this chapter.