Program management using TOC and CCM
Four plus years ago Reflectone (now CAE USA) made a dramatic change in the way the organization as a whole managed its operations. The company needed a fresh approach toward multiproject Program Management so to position it for continuous growth. Realizing that there were several emerging Management techniques at the time, Reflectone took a broad look at what was available. After a comprehensive evaluation the decision was made to institutionalize an emerging technique called Theory of Constraints (TOC). This paper will share insights into the implementation and daily operation of an organization using TOC and Critical Chain Management (CCM).
In 1998 Reflectone, a medium-size commercial and military training products and training services provider felt that they had reached a plateau in growth. The company had a solid workload and was looking to grow; however, it had reached its production limit. Senior management, understanding the corporate importance of being able to break out of this stagnation, needed a new approach.
Reflectone produces low volume, high value, and high fidelity flight training devices. These devices incorporate complex hardware and software products within a multiproject strong matrix organizational environment. Program Management was a specialized art that rarely duplicated itself between projects or between Program Managers themselves. The solution was to replace this ad-hoc approach to project management with a disciplined consistent management philosophy.
A Little About TOC
Theory Of Constraints (TOC) was pioneered by Dr. Eliyahu M. Goldratt in the 1980s and was first applied to production and distribution applications. TOC seeks to bring the organization to substantial performance improvement through a process of ongoing improvement based on Five Focusing Steps as discussed in “Theory of Constraints,” Goldratt, North River Press, 1990:
Step 1: Identify the system's constraint(s).
Step 2: Exploit the system's constraint(s).
Step 3: Subordinate everything else to the above decision.
Step 4: Elevate the system's constraint(s).
Step 5: Ifin a previous step, a constraint has been broken, go back to Step 1. But do not allow INERTIA to become the system's constraint.
TOC builds upon the resolution of constraints based on these 5 steps. Every organization has constraints inhibiting it from maximizing the economic measure of success—throughput. The goal of implementing a process of identifying, exploiting, subordinating, and elevating these constraints through continuous improvement in an organization is to maximize throughput
Changing the Management Culture
TOC was implemented at Reflectone with the help of the Avraham Y. Goldratt Institute (AGI) and the five focusing steps. The first discovery was the company's lack of six main components within a multiproject environment that are necessary to achieve success.
1. Synchronization Mechanism—Allowing projects to be started later, but finished sooner and clarifies resource assignment priorities.
2. Planning Processes—Account for the needed dependencies and completion criteria.
3. Scheduling & Budgeting Processes—Concentrate safety where it will provide the most protection.
4. Changes In Behavior—Support a world-class relay team culture.
5. Mechanisms—Create “Project Control & Visibility” to assist in global decision-making.
6. Information to Enable 1–5.
The throughput of the organization was constrained by the organization's inability to manage the available resources across multiple projects. Objectives to solve these constraints were identified and the necessary changes were implemented using Critical Chain Management (CCM). Infrastructure changes would become the key to enabling the use of TOC and CCM.
Building the Infrastructure
The changes to the infrastructure to support TOC and CCM were based upon commonly available software applications. Networks would be built using Visio, which provides a graphical modeling tool set and includes both an accessible database and analysis tools. Once the network is developed, it is then transferred to MS Project. The MS Project files acts as the primary statusing and reporting tool. The project files are then interfaced with an access database and becomes the central data repository. Once loaded and updated the database is used to generate the reports and graphics used by Program, Functional, and Senior Management during the life cycle of the program. Task status updates are gathered daily using a multiuser intranet front end that directly feeds task progress information from the individual resources to the schedule and data repository itself.
In the implementation of TOC, the rate in which work is accomplished for the entire organization is based upon the one constraining resource. This happens to be the key to multiproject integrated scheduling and what was lacking at Reflectone. Following the principles of TOC and CCM it was apparent that each of the schedules would have to be driven by this constraint or drum resource. Therefore by de-conflicting the drum resource across each of the programs this would in essence de-conflict the organization and thus properly pace the workflow.
A semi-dynamic, two-way link between individual projects and the drum was established. A new project is derived using just the drum resource tasks from each of the individual project's schedule. Then using ProChain (another commonly available tool) resource contentions between the projects are resolved on this new conglomerated project based upon a finite resource pool for the drum resource. This is the first way a link is made, the second link of the two way link between projects is when the results of the ProChain de-conflicted drum resource tasks are feed back into the individual schedules. What happens in one project may then, as would be expected, impact other projects through schedule movement of the drum resource. This then establishes a multiproject integrated scheduling infrastructure.
Managing the Projects
Reflectone had been relying on traditional milestone tracking and were experiencing the typical scheduling problems. Accurate visibility into the program's progress was clouded by the inherent variability of work estimates, thereby blinding management to the true progress of the program. There are two manifestations of this phenomenon. First, is bad multitasking and the second is ingrained schedule “safety.”
There are two inherent root causes in organizations that lead to bad multitasking of resources that have devastating effects on program schedules. The first is in order to successfully manage projects; organizations have to take two conflicting actions. They need to hold off on acting on new work and at the same time they must take action to begin new projects as soon as possible. This leads to conflicting priorities between projects. The second inherent cause has two components, one is in task estimation, and the other is in resource behavior. First, the committed times for projects are significantly lower than the organization will achieve, because the plans used to meet project time commitments are often missing key integration's that negatively affect the estimation. This leads to safety being added to the task estimation. Secondly, even though task estimates have a high probability of being completed well within the time estimate several well-known organizational principles of human behavior, such as Student Syndrome leads to wasted schedule safety.
The result was an environment where expediting and prioritizing is high and the likelihood of achieving milestones “on schedule” is low. Few projects were being delivered on time at Reflectone. Consequently Program Management and Engineering were finding it very difficult to accurately predict ongoing progress and completion dates making accurate resource planning impossible.
Acknowledging the presence of safety was a key step toward managing variability in a project. Aggregating the safety into buffers and placing them at strategic locations in the schedule enables feasible plans to be created that are immune to this type of variability in tasks.
Buffers can be considered schedule shock absorbers that serve as a mechanism to guard against external and/or internal variability. By inserting and sizing buffers based upon “best result” times and 95% probable times for task completion, three very important things happen. First, key schedule dates become predictable, schedule variability is recognized and planned for, and third, consumption of the buffers becomes a key indicator of the program's progress. Management of the program schedule becomes simply the management of buffers.
There are six basic characteristics of the application of Critical Chain Management and the use of buffers:
1. Best Result Task Times: the estimate of the amount of effort it takes to complete a task if everything goes right and the task is worked according to schedule and plan.
2. Resource Conflicts Removed: Variability, interdependence, and contingencies are removed from the required resources. Resource de-contention is done for the program at the resource pool level based upon the capacity of available personnel in a work center.
3. Critical Chain: The Critical Chain is the longest series of interdependent activities through a network that are connected by task or resource dependencies. The Critical Chain is the program constraint for delivery of the contractual commitments.
4. Feeding Buffer: Feeding Buffers are positioned between the critical chain and the feeding chains. The Feeding Buffers protect the critical chain from variability in the noncritical Chain tasks.
5. Start Only As Early As Necessary: Tasks are scheduled to start as soon as they are needed in order to avoid delaying the CC task they are feeding. This is a critical component of companywide resource loading.
6. Project Buffer: The schedule is not complete until the project buffer is added to the critical chain. It protects the critical chain completion date from variability in the critical chain tasks themselves.
Monitoring and Managing Progress
Improving the ability to measure and report progress on programs was a major driver in choosing CCM for scheduling. As discussed earlier, CCM implements the identification and management of a critical chain of task events through the use of feeding and project buffers. The buffers are used to actively manage the variability of the work. Management of the programs and ultimately the company became simple the management of buffers.
One of the first indicators of schedule performance is to measure task completion against specific key dates in a program. The Key Dates chart gives the Program Manager a snap shot look at five key typical events on the program (see Exhibit 1). Manufacturing Turn-Over (MTO), Testing, Tear-Down Pack and Ship (TPSI), Ready For Training (RFT) and Project Complete are tracked. For each of the key events four dates are presented.
When a schedule is initially calculated there are two dates generated—the Baseline date which is the planned date based on the Best Result times and the Fully Buffered date which is the completion date based on the 95% probable times. The fully buffered date should be calculated to occur before or near the Contractual dates for the program. These two dates do not change except when a schedule re-baseline is performed, due to scope change or significant impacts due to external constraints. A program is re-baselined by rescheduling from the current date forward. Completed work is not included in the recalculation. This causes buffers to be reduced and a new critical chain to be identified.
As the program schedule age's, buffers will be consumed and the schedule completion date moves from the Baseline date. This new date is captured in the Current Expected date. The Current Expected date will be different from the Baseline date and the Fully Buffered date as the program is being managed. The forth date tracked is the Contractual Date.
If the program is on or near plan the current expected dates will be later than the baseline date and earlier than the fully buffered date. This graph is an early warning indicator of potential schedule problems.
The second indicator of schedule performance is in the rate of buffer consumption relative to work completed. This indicator is the top-level view of the program performance and is referred to as the Program Performance Index graph (see Exhibit 2). This graphic plots the critical chain and noncritical chain performance indices over time. The program performance index is a simple calculation of the percent complete of the critical chain task effort minus the percent consumption of the project buffers (the red line). The noncritical chain index is calculated the same way but uses the percent of noncritical chain effort completed minus the percent of feeding buffers consumed (the blue line). A nominal-performing program would be at zero (program is on plan), which would indicate task effort completion as a percentage is about equal to buffer consumption. Performance below zero (program behind plan) indicates buffer consumption is out pacing the completion of task effort and above zero (program ahead of plan) indicates task effort completion is out pacing buffer consumption.
Using the Tools
The process of Program Management as discussed earlier becomes simply the management of buffers. The tools available to the PM leverage the new infrastructure and the company's new use of drum resource pacing. On a typical day the PM would start by reviewing the Database Comparison Report or –d. The –d gives a daily snap shot of the changes in work duration and the changes in buffers. This report does two things for the PM; first it identifies what is being worked, and second it identifies which buffers are being consumed and at what rate.
Noting the buffers being impacted, the PM would next evaluate the project and feeder buffers using the Open Buffer Report (OBR). The OBR can quickly identify buffer penetration and its cause. Also available within the OBR is the Consolidated Buffer Report (CBR). The CBR shows the specific task(s) with the highest frequency of effecting buffers. Knowing which buffers are being affected and which task(s) are causing the penetration is a very import indicator—it identifies where the problem is and where the best place to apply effort.
Knowing the point of buffer penetration and the root task(s) causing the consumption the PM can then respond to problems as they arise on a daily bases. There is also several accumulated performance indicators such as the Program Performance Index discussed earlier that are available to the PM. When combined with the Key Dates Chart trend analysis can be done. This evaluation is made less frequently than daily buffer management using the –d and the OBR/CBR. Trends will typically indicate more serious problems and are treaded differently. As performance falls and key dates slide the PM may look for more systemic problems such as; requirements creep, gold platting, or unanticipated constraints.
Moving to CCM and TOC at Reflectone has profoundly effect the way Program Management does their job. As opposed to responding to simple project milestone schedules, PMs are now tracking buffer consumption while working in a multiproject integrated environment. PMs are using the new tools to monitor progress, identify problems early, and then apply effort where it is needed to best improve program performance.
Managing the Company
The magnitude of data available to the PM at the project level is also available to Senior Management. By rolling this data up, new views of the company's performance is then available. At Reflectone there are nine company level indicators being used. The Performance Index, when combined together from each of the projects, gives a single view of the corporate performance trend. Another available indicator is the Resource Response chart that identifies the amount of work available by resource group in comparison to the available resources labor. This is being used by Human Resources and Functional Management to identify staffing needs.
One of the newer company level indicators is the CCM Task Reporting Report. This report tracks the availability of tasks to report on and the frequency of reporting being made. In the next section you will see an on-going problem being tackled today is the need for timely updates to the tasks—key to any good scheduling or planning tool. This report was in response to a performance oscillation effect. A trend was seen in relations to the rate of task updates. At an almost program phase cyclic period performance would drop and then recover. It turned out to coincide with a projects completion of a phase boundary. Between phases updates fell off causing a pronounced down turn in performance and then just before a phase completed it would recover. With this new chart it became obvious which resources where neglecting intermediate updates and only updating when the task was completed. There were other problems and issues in implementing TOC and CCM that will be discussed next.
Problems and Issues
Network Complexity and Working to a Plan
Finding a level of detail that is representative of the program and yet manageable is a continuous issue with all of the programs. Comparing three of the first networks build it was found that there were substantially differences in task counts. One found the detailed planning during the design phase was beneficial however that same detail during Hardware Software Integration and Test did not allow for the natural problem solving, which occurs during test and acceptance. From a network standpoint it was found that around 750 tasks was an ideal task count. More detail is generally provided in the up-front tasks and less detail later in the program. This has shown to be a very good mix, providing visibility early to critical interdependencies that could seriously affect the overall program but yet allowing downstream flexibility during problem resolution. All while providing the PM visibility to the work being done and the progress being made.
Exhaustion of buffers on many of the projects was a recurring problem. In buffer management, the loss of buffers removes the ability to manage the variability of the program. Projects were running into situations where tasks could not be completed. Work was continuing but the task(s) where being skipped and neglected. By leaving these tasks open it inhibited the natural progression of the schedule distorting the remaining work.
Tasks are opened for work based upon two criteria; (1) the planned start date has been reached and (2) its predecessor (if there is one) has less than 80 hours of remaining work. These rules are used to keep workflow moving to plan. Not completing tasks and continuing to work without reporting progress causes buffers to be consumed. This situation can happen relatively quickly and it was on the projects.
A more basic problem also affects buffers. A policy guideline for reporting work progress specified that updates shall be once a week for work greater that 40 hours remaining and daily for work less than or equal to 40 hours. During the course of a program, task updates were being made less than once a week and sometimes only when completed. This caused intermittent performance issues and an accordion effect on the expected dates. Depending on when you looked—things could be good or getting bad.
The solution to both of these problems was again simply the timely update of work remaining. New information was captured and reported to help manage this problem.
Impact of TOC and CCM
TOC strives for continuous improvement through the identification and resolution of constraints. Insufficient information to manage resources in a multiproject environment was constraining management's ability to meet contractual obligations and improve performance. The implementation of Critical Chain Management was the vehicle to resolve this constraint.
The Theory Of Constraints has had a substantial impact on Reflectone's programs. The work was the same, what changed is what was being managed. Using new software tools for planning, scheduling and reporting, consistent with CCM methodology, Program Management's approach shifted from milestone tracking to critical chain and buffer management. The inherent variability of the work performed is now being actively managed.
Proceedings of the Project Management Institute Annual Seminars & Symposium
October 3–10, 2002 • San Antonio, Texas, USA