Critical Chain assumes a good critical path network that has been effectively resource lev- eled. Starting from that point, Critical Chain enhances the ability to optimize the schedule and sets the stage for improved project monitoring and control. It should be noted that some of the actions needed to implement Critical Chain successfully might be significant changes for an organization. Following are specific ways that the Critical Chain approach works and adds value.
1. Using the Critical Chain approach, team members are asked to dedicate them- selves to a project task, to complete it as quickly as possible, and to periodically report how many days are remaining. When planning a project, task times should be estimated much closer to how long the task will take with dedicated resources, rather than elapsed times assuming the organization’s current practice of assign-
ing resources to work on several tasks at once. This also significantly reduces be- haviors called “Student Syndrome” and “Parkinson’s Law.”
2. Bad multitasking is significantly reduced, permanently. This goes hand in hand with reducing task estimates to dedicated elapsed times and having people com- plete tasks before starting new ones.
3. In executing a project, people are not measured and are not held accountable for completing their tasks on time. People are asked to pass on their outputs to the next resource as quickly as possible. Use of intermediate due dates is limited. This is sometimes called the “relay runner ethic.”
4. By taking resource dependency and logical task dependency into account, the longest sequence of dependent tasks can be seen more clearly. This longest se- quence, the Critical Chain, may cross logical paths in the network.
5. Buffers are a key part of the schedule and how it is managed. The ability to in- crease the certainty of project completion dates is closely related to the use of buffers. The use of buffers, strategically placed in the plan, allows the planner to clearly accommodate all common cause variations (variations in duration that predictably occur because they are part of the system within which projects are performed). Buffer types include project buffers, feeding buffers, resource buffers, drum buffers, and strategic resource buffers.
6. Critical Path uses a concept of slack time or float to determine how much flexi- bility there is in noncritical path tasks. Critical Chain approach assumes that slack times often do not provide real flexibility due to behaviors such as “Student Syndrome.” Critical Chain approach groups tasks on each noncritical (or feeding) path entering into the Critical Chain and “protects” the Critical Chain with a feed- ing buffer. The feeding buffer is equivalent to a schedule contingency reserve that is local to a part of the project. The Critical Chain approach is explicit and sys- tematic about the use of feeding buffers throughout the task network.
7. This buffering allows for noncritical tasks to be scheduled at their latest possible start times to discourage costly early investment of work in process. This also sig- nificantly reduces behaviors called “Student Syndrome” and “Parkinson’s Law.”
Early starts are discouraged unless there is a major strategic reason for doing so.
8. Often, the Critical Path changes during execution because there is no buffer to ab- sorb the variation in task times. If implemented correctly, the Critical Chain plan and the Critical Chain itself do not change throughout the life of the project be- cause the buffers absorb the uncertainties in task duration.
9. Critical Chain recognizes that there are multiproject environments in which projects have resource-based interdependencies. In other words, projects share a common resource pool for at least some tasks.
10. The Critical Chain approach identifies the critical resource (called a drum re- source) across a collection of projects. When overloaded or not available, this re- source is the one most likely to impact the project cycle time of all projects.
11. The staggered introduction of projects into the system is used to improve the flow of projects, to increase the predictability in each project outcome, and to increase the effectiveness of critical resources by minimizing the effect of bad multitasking.
How Critical Chain Extends Critical Path 853
A shorter project cycle time and an increase of the number of projects that can be pushed through the system without increasing resources result from staggering the release of new projects.
12. Similar to vertical traceability in Critical Path, the Critical Chain plan and de- tailed schedules are linked entities. Any logic at the detailed levels must be re- flected in the summary level(s).
PROBLEMS
22-1 Describe the five types of buffers used by the Critical Chain methodology, and the unique purpose of each one.
22-2 How should a resource manager decide which task a resource should work on, when there is a conflict?
22-3 In what ways does a Critical Chain plan address Deming’s concerns about common cause variation?
22-4 Is a Critical Chain schedule more useful to people planning and managing tasks, or to people actually performing the tasks? Explain.
22-5 Describe the primary role of the “drum” manager.
22-6 Describe four ways that Critical Chain is different from (extends) the Critical Path ap- proach (as Critical Path is traditionally applied)?
22-7 How could a buffer report alert a manager to a schedule problem?
22-8 The following are different measurements used by organizations for project managers and team members. Which two represent a Critical Chain philosophy?
a. Accuracy of task time estimates
b. Do your work as fast as possible and pass it on to the next resource as early as possi- ble.
c. Finish your task by the due date d. Finish the project on time or early
22-9 From an executive perspective, which of the following are the major benefits of a Critical Chain approach?
a. Improved cash flow
b. Less time to review major projects, with better reporting c. More projects completed each year using the same resources d. Better performance to milestones
22-10 Two project managers are looking for the same resource to perform work on their pro- jects. In one project, the work is on a task on a feeding path, in which the feeding buffer is 95 percent consumed. In the other project, the work is on the Critical Chain, in which the Critical Chain is 50 percent complete and the project buffer is 0 percent consumed. Which task should the resource be assigned to first? Why?
22-11 Critical Chain is a methodology to help managers plan projects and manage their exe- cution to deliver the projects on time, on budget, and within scope. In each case below, given the two choices, identify which choice best fits with a Critical Chain approach.
a. Plan has 10,000 tasks or plan has 300 tasks.
b. Resources are identified by individual name or resources are identified by pool name.
c. In a multiproject environment, there is one master scheduler or each project manager determines when his project will start.
d. Team members know the estimated effort for a task or team members do not know the estimated effort for a task.
22-12 Why must executives buy into the multiproject Critical Chain approach?
22-13 There are three major software products that support Critical Chain. One product is an
“add-on” to Microsoft Project. Describe one major advantage of being linked to Microsoft Project and one major disadvantage.
22-14 One of the software products that supports Critical Chain is based on the Oracle data- base. Describe one major advantage of having a project management product use the Oracle database and one major disadvantage.
22-15 One of the software products that supports Critical Chain has its own proprietary data- base. Describe one major advantage of having a project management product use its own data- base and one major disadvantage.
22-16 Why does the Critical Chain methodology claim that individual tasks cannot be pro- tected by inflated estimates or due dates? How does buffering a project and feeding paths pro- vide greater predictability in a project outcome?
22-17 If you were a project manager in your first Critical Chain project, how would you con- vince team members to pass their work on early to the next resource?
22-18 As a resource manager, what information do you need from your resources daily or weekly in order to keep the Critical Chain database up to date?
22-19 In the multiproject environment, the drum becomes the anchor according to which new projects are released into the system. From the case studies, is the drum typically a resource used close to the beginning of a project or closer to the end of a project? Why?
22-20 For each buffer category below, indicate how many buffers you would expect to find in any single project?
a. Project buffer b. Feeding buffer c. Resource buffer d. Strategic resource buffer e. Drum buffer
LUCENT TECHNOLOGIES
Lucent Technologies, Inc., is a $33 billion manufacturer and service provider in the communi- cations industry, headquartered in New Jersey. With about 100,000 employees in more than 65
Case Studies 855
CASE STUDIES
countries, Lucent’s focus is in the mobile Internet and high-speed broadband markets for all types of communications networks. This includes Internet, e-business, wireless, optical, data, and voice communications products and services.
In this highly innovative and competitive industry, the speed to market is very important.
To ensure rapid development, Lucent uses the services of its Bell Labs R&D community, which operates in thirty different countries. Lucent invests about 12 percent of revenues in R&D each year, making these labs the birthplace of innovative products in use by many millions of peo- ple around the globe.
One of the first divisions of Lucent to employ Critical Chain methodology was the Optical Fiber Solutions group. This group is headquartered out of Norcross, GA. It is a pioneer in the development and manufacture of optical fiber and fiber components. Optical fiber is rapidly growing in communications applications, due to its combination of high speed and reliability.
The Optical Fiber Solutions unit consists of several thousand employees, including several hundred scientists and engineers. A Bell Laboratories director of this group, Dr. William J. Baron, describes the project environment before Critical Chain implementation as constantly changing.
Within this division, there are some large projects with dedicated resources. However, many projects use resources that are shared between projects, characteristic of the multiproject environment. Before Critical Chain implementation, project priorities were constantly chang- ing. About 40 percent of the projects finished on schedule. Project cycle times, according to benchmarks, appeared to be on par or shorter, compared to similar companies.
To make a Critical Chain implementation successful, Mr. Baron describes the change process as “99 percent culture change and 1 percent theory.” He indicates that getting the busi- ness unit president and senior executives to understand the buffers, and buffer management is critical to success. At Lucent, Dr. Richard Franks, CEO of Oak Hill Consulting, accomplished this with an executive training program using simulations of three projects to reinforce the un- derstanding. According to Dr. Franks, “Simulations are critical to holding the attention of se- nior executives and gaining their buy-in to the changes.”
During the transition, one of the big questions was how to handle projects that were al- ready started. Dr. Baron decided that if projects were “well-enough along,” the implementation team would allow them to complete without converting their schedules to Critical Chain. The team began the process taking two very high priority projects, deciding on their drum resource, and scheduling them using Critical Chain.
Initially, their drum revolved around an incoming material used in development projects.
After six months, they found that projects were still experiencing logjams. As a result, the drum was changed to later in their development process and has continued to prove effective as a staggering mechanism over several years.
This division of Lucent uses software called ProChain (a Microsoft Project add-on) to fig- ure out their Critical Chain schedules. Projects are tracked using weekly buffer updates and tracking meetings.
In the initial two years of implementation, the following results were achieved:
● In the Premise Cable Products group (inside-building cables), 100 percent of the six- teen projects scheduled using Critical Chain were completed on time. Cycle times were reduced by 50 percent in the first year.
● In the Outside Plant Cable Products group, development capacity tripled, with no increase in staffing. Cycle times in this division were also reduced by 50 percent the first year.
● Over the two-year period, over 95 percent of all projects were delivered on time.
Mr. Baron credits Critical Chain methodology with having a major impact on new product introduction. Multitasking is no longer a way of life. Morale is also higher, with the feeling that
when a commitment is given, the Critical Chain plan helps make it a reality. As noted by David and Suzan Bergland, the consulting team from TOC Solutions, LLC, who worked with Dr.
Franks in a follow-on implementation at Lucent, “Bill Baron and his team have reaped huge gains by cutting away the old rules that bound them. Now their project commitments are pre- dictable and with predictability comes the information they need to manage expectations as well as their work.”
The increase in capacity to complete more projects has allowed the division to shift its mix of projects. As Dr. Baron describes, “The work has shifted to much more forward looking projects. Less work is of a trivial nature.”
Critical Chain implementations within Lucent have spread to other divisions, where the competitive pressures are also driving the demand for both faster R&D and a higher volume of project completions.
ELBIT SYSTEMS LTD.
Elbit Systems Ltd. (ESL) is a public company, headquartered in Haifa, Israel, with subsidiaries worldwide, employing about 4400 people. ESL develops, manufactures, and integrates ad- vanced, high-performance defense electronic and electro-optic systems for customers through- out the world including the United States, Europe, Israel, Latin America, and the Far East. Elbit Systems focuses on upgrade programs for airborne, ground, and naval defense platforms, often as a prime contractor. The company also focuses on designing, developing, manufacturing, and integrating command, control, and communication (C3) systems, as well as electronic and electro-optic systems and products. See Exhibit 22–1.
Case Studies 857
EXHIBIT 22–1 Programs competing for common resources
Netherlands C3-Artillery Austria
C3-Artillery & Ground Systems Italy Guided Weapons
United States Airborne & Ground Systems
Venezuela
Naval Systems Brazil ALX, F-5
Thailand L-39, F-5 Korea Space Payloads
Turkey F-4, F-5, Reconnaissance
Croatia MIG-21 Romania MIG-21, Puma Czech Republic
C3-Artillery Germany
F-4 Switzerland
Avionics for Helicopters
Australia Avionics for Helicopters
Israel Airborne, Ground, Naval & C3 Systems
ESL tailors and adapts its technologies, integration skills, market knowledge, and battle- proven systems to each customer’s individual requirements in both existing and new platforms.
ESL’s projects are diverse, covering innovations in systems deployed in the air, on the sea, on land, and in space.
This case study refers to the implementation of the Critical Chain methodology in one of ESL’s sites (Haifa) that comprises business units organized in a matrix organization that in- cludes business centers and the engineering department. The main areas of business that were involved are:
● Fixed-wing and helicopter upgrades and systems
● Pilot helmet-mounted systems
● Combat vehicle upgrades and systems
● C3 and battlefield information upgrades and systems and unmanned air vehicle (UAV) platforms
The projects in each business unit can last up to five years. Each project is assigned a pro- gram manager from a business center and engineering teams from the various departments and staff members. Operating in a multiproject environment, engineers can be involved in more than one project. As a rapidly growing company, ESL’s internal competition for personnel also increased over time.
Prior to implementing the Critical Chain methodology, ESL experienced some of the typ- ical problems encountered by project-oriented industries:
● Slipping due dates
● Too many changes
● Resources and information not available when needed
● Conflicts on priorities between projects
● Budget overruns
● Rework
ESL, in a very competitive operating environment, puts pressure on the company’s engi- neering resources that results in aggressive estimates. As Guy Brill, ESL’s chief operating offi- cer, describes, “Customers demand shorter and shorter cycle times.”
To try to satisfy everyone’s demands for people, the company’s resources were experienc- ing significant multitasking (splitting their time between projects). Multitasking, in turn, some- times created confusion and fights over priorities. As Mr. Brill describes, “This created the ef- fect of making all program managers equally unhappy.”
To resolve these issues, ESL began a Critical Chain implementation in April of 1997. After an initial two-day workshop, the effort began with two pilot projects. However, ESL quickly discovered that in a matrix organization, this approach was deficient. The key issue was in re- source management—being able to get resources when you need them, without major conflicts between projects. These efforts early in the history of Critical Chain multiproject implementa- tion became the foundation of the multiproject approach.
By July of 1997, ESL was able to hold a workshop for top management. With their buy- in and support of the new project management methodology, the company held a kick-off meet- ing in September of 1997 for 400 people. The CEO was there to present the company’s strat- egy and to endorse the need for a new way of managing project resources. By November, the infrastructure and software were in place and transitions to Critical Chain were well underway.
Multiproject Critical Chain software did not exist prior to this effort. Software required to sup- port the multiproject approach, called Concerto, was developed as part of this effort at ESL. The
key was to provide a synchronized view of the entire company’s project resources. Avionic pro- grams were converted to Critical Chain in 1997, and other programs were converted in 1998.
The approach that the company took in implementing was to train project and resource managers on the Critical Chain basics in a two-day workshop. Following the workshop, these managers took three days to build their Critical Chain plans and resolve conflicts. Any obsta- cles were brought to a steering committee.
One of the significant issues that emerged during implementation was how to measure and reward people on projects. Previously, team members had been rewarded based on meeting or beating their task due dates. Since this measurement is counterproductive to Critical Chain, the steering committee decided to reward people based on overall company and project performance.
However, a critical motivation issue remained. Critical Chain requires the “relay runner”
work ethic. ESL is a project company, which means that much of its revenue comes directly from project work. Therefore, it was considered very negative for any person to not have a real project (job number) on which to charge their time. The implementation of the “relay runner”
work ethic meant that from time to time, team members might have “idle” time—time that would not be spent on a specific active project, and that was acceptable to ESL’s management.
However, there would still be the problem of the perception and worry of team members, con- cerned about how they would be viewed by management.
To solve this problem, ESL went through several iterations of approaches. Their first thought was to have an “idling” job number, but the terminology of “idling” was negative.
Using another terminology, “R&D job numbers” was also turned down, due to the concern that people will still avoid reporting the end of their current task before they can start reporting on a new one. The final decision was to use a separate reporting system for job numbers and use Concerto for reporting the start and end dates of each task.
One of the biggest challenges in implementing the multiproject changes was in deciding how to stagger and prioritize the projects. ESL first selected two of the software groups as their drum resource. Projects were scheduled so as to not overload this software group. This drum did not provide enough staggering, since the size of the software teams was found to be too flexible. Engineers working at the integration stage were among the company’s best. They had to be familiar with the entire project specifications and customer requirements. They had to be knowledgeable enough to integrate and test the entire system thoroughly.
As a result, the company pioneered a solution in conjunction with Dr. Goldratt, called
“virtual drum.” This solution uses a policy, rather than the loading of a physical resource, as a means to stagger projects. As ESL found out, one of the major causes for multitasking was the need to call on short alert engineers, who were involved in the development of a product, dur- ing the integration of this product at the system level.
At integration, if a component of a system meets its specifications standalone, but fails during integration testing, arguments can easily occur between different engineers over who
“owns” the problem. At the system integration stage, the engineers sometimes believed that they were wasting their time by working on a problem that could belong to one of the other team members. Therefore, the attitude often was “Prove that this is my problem, not yours.”
To resolve these complex integration problems often required a collection of resources from different departments. These resources were not always readily available since system in- tegration often took place when the product teams were already engaged with new tasks. The result was that projects were often delayed in integration. Contention between projects delayed the ability of the projects to move through integration quickly enough to meet schedules or caused delays in the execution of the new tasks.
The “virtual drum” solution uses the policy that only one or two projects are allowed to move through integration at one time in each group of projects that use common resources. With
Case Studies 859