The unique features of CCPM do not make up a sufficient system to satisfy the project system requirements identified at the beginning of this chap- ter. The PMBOKGuide seems to provide all the necessary additional features to meet the complete system requirements. Following Juran, I have prepared a feature and requirement correlation matrix to examine how the CCPM features and selected features and processes from the PMBOKGuide combine to provide the complete set of identified project system requirements. (The table is too large for publication in book format; see [5].) It helped to identify the following set of PMBOKGuide features as the primary ones necessary to deliver to the requirements given in Table 4.1. The correlation table also leads to clarification of the requirements that pertain to each feature and therefore supports developing the feature.
Time 0
1/3 2/3 1
x x x
x xx
x x
x x
Plan
Act
Project buffer
Figure 4.9 Plotting trends of buffer penetration may aid analysis.
The following features, which are (mostly) contained in and explained in the PMBOKGuide are necessary to satisfy these requirements:
4.4.1 Project charter
The project charter authorizes the initial project team to prepare the project work plan. It identifies the overall project deliverable, project stakeholders, overall project responsibilities, and other parameters neces- sary to create an effective project work plan.
4.4.2 Project work plan
The project work plan identifies the scope, budget, schedule, responsibili- ties, and resource requirements for the project. It may also specify other project requirements and plans to achieve them, such as quality, safety, and regulatory plans. It must contain or reference the operational proce- dures for the project. Key elements of the project work plan include the WBS, responsibility assignment, milestone sequencing, work packages, and the project network.
4.4.2.1 Work breakdown structure
The WBS is the framework to define project scope. It defines project scope hierarchically, from the complete project level to the work package level.
Work packages complete the hierarchy by specifying the project tasks necessary to deliver the scope.
4.4.2.2 Responsibility assignment
Responsibility assignment designates the individuals responsible to accomplish deliverables on the WBS. Responsibility assignment must occur at the work package level and may be assigned at higher levels.
Responsibility assignment normally confers the authority to perform the work and accountability for delivering the scope to the budget and sched- ule for the project deliverable. The person responsible for a work package does not have to be a task performer, that is, a resource on a task.
4.4.2.3 Milestone sequencing
Milestone sequencing is a tool to go from the hierarchically formatted WBS to a logical project plan. It provides the major sequence of project
tasks for use by work package managers to link the inputs and outputs of their work packages. (This element is not described in the PMBOK
Guide, but it is covered in Chapter 5.) 4.4.2.4 Work packages
Work packages define the plan to produce project deliverables at the low- est level. Work packages contain the scope definition for the deliverable of the work package and the plan to produce the deliverable. This plan includes defining the project tasks, the logic for the tasks, and the linkage of the work package tasks to other elements of the work plan; usually to milestones on the milestone sequence chart. Work packages may link to tasks in other work packages as well, but this linkage usually cannot occur on the first draft because all work packages are planned simulta- neously. Work packages also identify the estimated task duration and resource requirements and the assumptions necessary to support those estimates.
4.4.2.5 Project network
The project network logically connects all the tasks necessary to complete the project. The project tasks must identify the resources necessary to per- form the task within the estimated task duration. The network includes all the tasks from all the work packages, and identifies the critical chain, the project buffer, and the CCFBs. It provides start dates for each chain of tasks and the completion date for the entire project. It is the basis for subsequent performance measurement and control.
4.4.3 Project measurement and control process
CCPM defines an improved schedule measurement and control process.
Most projects also require a technical quality control process, and many projects also require a cost control process.
The correlation matrix [5] also identified a need for processes to ensure project result quality and provide mechanisms for continuous improvement. The scope of this text does not address the process to ensure project quality results. Ireland [6] provides an overview of a satisfactory process to meet those requirements.
4.4.4 Project change control
The project measurement and control process will, from time to time, trigger the need for action to complete the project successfully. In addi- tion, unfulfilled assumptions made at the start of the project, as-found conditions that differ from initial assumptions, or changes in the client’s demands may require changes in the remainder of the project. Project change control defines a process to incorporate and communicate those changes to all members of the project team.
4.4.5 Project risk management
Project risk management handles potential causes of special cause varia- tion. Because the PMBOKGuide does not differentiate between com- mon cause variation and special cause variation, it addresses both under the realm of project risk management. CCPM addresses common cause variation directly in the project system and thus confines project risk management to special cause variation. (See Chapter 11.)