The project work plan is the next step following the project charter and includes
1. Detailed specification of the project scope;
2. WBS to organize the project scope;
3. Assignment of responsibility to the WBS;
Table 9.1(c) Project Managers' Behavior Changes
Use 50% task-duration estimates
Develop relay-racer task performance
Control feedback on task-duration overruns
Determine project status
Allow project changes
Respond to management demands for shorter schedule
Assign resources dynamically according to critical-chain priority and buffer reports
Present Behavior Project managers send a message that they expect due dates to be met Provide start and finish dates for each task and monitor progress to finish dates Management provides negative feedback when tasks overrun due dates Varies: often use earned value as the schedule measure Varies: often submit changes to minimize minor variances Arbitrary task-duration cuts
Start tasks as early as possible
Start project as soon as funding is available
Get resources as soon as project funding is available and hold resources until they can't possibly be used any more on the project
Project managers first derive low-risk task duration and then get average duration, using task uncertainty to size buffers Provide start dates only for chains of tasks and completion date only for the project buffer
Management provides positive feedback and help if resources perform to relay-racer paradigm
Use buffer report (including a cost buffer)
Add resources or make process changes to get a feasible schedule immune from common-caused variation Start task chains as late as possible, buffered by feeding buffers Schedule project start using drum schedule
Get resources only when needed and release them as soon as task is complete
Table 9.1(d) Subcontractors' Behavior Changes
Change Present Behavior Future Behavior
Deliver to lead-times Deliver to due dates Deliver to lead-times
Shorten lead-times Deliver to due dates Shorten lead-times
Table 9.1(e) Customers' Behavior Changes
Minimize project-scope changes
Support using project buffer Eliminate arbitrary milestone dates
Present Behavior Spend little time initially establishing requirements and then introduce late changes
Interpret contingency as "fat" Demand arbitrary milestone dates
Establish requirements as part of the project work plan and change as little as possible with formal change control
Understand the need for buffers to reduce project lead-time and ensure project success Use plan to set milestones Procede all dates with a buffer
4. Resource-loaded (critical-chain) project schedule;
5. Project budget;
6. Definition of the project team;
7. Procedures for operation of the project team;
8. Plans for project close out.
Figure 9.2 illustrates the WBS for the project to implement CCPM. The WBS reflects the changes necessary for CCPM and includes the overall approach
recommended by Kotter  (See Section 9.2). Kotter's sixth point for effective change programs is to create short-term wins for those who participate early in the change. Be sure to make this part of your change plan.
The necessary actions to create a CCPM organization consider both resource behavior and the technical requirements of critical chain, including the following:
1. Project plans follow the CCPM paradigm (i.e., 50% task times, critical chain, and properly sized buffers).
2. The drum manager creates the drum schedule to accommodate management's project priority.
3. Project managers schedule projects to the drum schedule.
4. Resources work to the relay-racer paradigm.
5. Resources provide accurate input on the RDU of their tasks.
6. Resources and resource managers use the prioritized task lists to avoid bad multitasking and to determine which task to work on next.
7. Project managers plan buffer recovery when the project buffer enters the yellow zone and implement the plans when buffer penetration enters the red zone.
The work-plan tasks developed following the WBS must create these results.
You should consider the Seven Ss and the actual behavior in your (see Section 9.2.1) organization in order to complete your plan. Try to separate fact from fiction. For example, many people initially believe that all tasks in their organization are underestimated. This is often the case in an organization with extensive multitasking and interruptions. Sometimes, they have data on actual, reported task completion for previous projects. It usually only requires a quick check to find that they are similar to most organizations, showing extensive date-driven behavior.
Note that I have focused the WBS on the required behavior change and not on changes in the underlying beliefs or culture. This accomplishes the most direct change. It may not lead to lasting change. While some of the feedback from CCPM is self-reinforcing, it is legitimate, in many organizations, to fear that management's exploitation of this method will extend to exploitation in a negative sense, such as overloading the drum resource. If your organization is misaligned with the principles underlying the TOC, you should take this opportunity to begin the cultural and belief changes needed for ongoing improvement. Otherwise, improvement will stop as soon as the implementation project ends.
The responsibility matrix identifies each of the work packages shown in the WBS and the person responsible and accountable for the work package. You may assign responsibility at multiple levels in the WBS, but you must assign it to the lowest, or work-package, level. Note that the person responsible for the work package is not necessarily the same as the resources required to perform the work contained in the work package. The responsible and accountable work-package manager may be one of the resources that works on the project and may show up in his or her own work package and in other work packages. Work-package managers plan and estimate the work package and then are accountable to manage its performance.
The WBS and project schedule include Kotter's final two points of effective change programs: consolidate improvements while producing still more change and institutionalize the new approaches. The final step requires assuring that the CCPM approach permeates all policies, procedures, and measures of the organization and is formalized into training programs to ensure that new people are properly indoctrinated into the organizational process. In the end, CCPM should not be an additional thing. It should just be "how we do business around here."
Figure 9.3 illustrates a schedule for implementing CCPM. It is in the critical-chain format, as illustrated by the CCPM+ software-modified Microsoft Project Gantt chart. This format illustrates all of the tasks on the project but identifies the critical-chain tasks by color (difficult to see in a gray-scale publication.) It also shows the tasks that may be performed early without causing an adverse resource conflict for the project. Do not start these tasks early in a multiproject environment because you may cause unnecessary schedule conflicts during project performance.
This schedule only shows the end dates of the milestone and project buffer. The plan, starting on January 2, 2005, predicts completion (end of the project buffer) on October 12, 2005. The project and feeding buffers are 50% of the preceding chain. Note that the WBS elements include from four to eight tasks. Eight tasks are by no means the limit for a work package; work packages often have up to 25 tasks.
The pilot project dominates the critical chain. This schedule includes a 60-working-day duration for the pilot project (i.e., about three months). The pilot project usually need not complete to serve its functions, such as identifying the organizational obstacles and serving as a test for the procedures established for full-scale implementation. You should formally declare success on the pilot project when you have accumulated sufficient information that the organization is ready to move on to the next step.
Your plan will differ from this one. If you have a large organization, the number of projects to be planned may be much larger. Training durations will usually be longer due to the need to schedule multiple sessions to allow for people's availability and sometimes to accommodate different locations. Sometimes acquiring the software can take much longer, but you should work to keep that process off the critical chain, including doing the pilot project with your existing critical-path software.
Was this article helpful?
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.