SS

Czech Republic C3-Artillery

Romania MIG-21, Puma

Croatia MIG-21

Korea Space Payloads

Turkey •F-4, F-5, Reconnaissance

Venezuela Naval Systems

Thailand Israel L-39, F-5 Airborne, Ground, Naval & C3 Systems

Brazil ALX, F-5

Australia Avionics for Helicopters

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 includes 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 program 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 typical 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

ESL, in a very competitive operating environment, puts pressure on the company's engineering resources that results in aggressive estimates. As Guy Brill, ESL's chief operating officer, describes, "Customers demand shorter and shorter cycle times."

To try to satisfy everyone's demands for people, the company's resources were experiencing significant multitasking (splitting their time between projects). Multitasking, in turn, sometimes created confusion and fights over priorities. As Mr. Brill describes, "This created the effect 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 resource 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 implementation 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 meeting in September of 1997 for 400 people. The CEO was there to present the company's strategy 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 support 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 programs 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 obstacles 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, concerned 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, during 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 integration 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 this policy in place, the integration engineers and other departmental resources work together with much less conflict in priorities. This solution has now been in place for several years.

As reflected by Guy Brill, "There are three major issues for Critical Chain multi-project success":

• Preparation of viable work plans with a Critical Chain and a properly sized buffer (30 percent for ESL). Having such a buffer is a must for any ESL new project plan.

• Implementation of buffer management, as a way of prioritizing tasks during execution of the multiple projects. Tasks must be prioritized according to the percentage penetration of the various buffers

• Limiting the multitasking. At ESL, the "virtual drum" concept was successful in making this happen.

At ESL, with daily reporting of task starts and completions, and overnight updating, the "realtime" management of projects is in place. ESL implemented another type of buffer, called the milestone buffer, due to the types of contracts they undertake. Often, payments or penalties are associated with meeting certain critical milestones, especially in the longer-term projects. The milestone buffer is similar to a project completion buffer. Task priorities are decided based on penetration of the project completion buffers, the milestone buffers, and lastly the feeding buffers, in that order.

ESL limits the number of tasks in each Critical Chain plan to 200-300. More detailed plans are developed, tied to the individual tasks in the Critical Chain plan. Where it used to take greater than one hour for senior management to review each project, now the entire collection of thirty to forty projects can be reviewed effectively in two hours total time.

ESL claims that Critical Chain has eliminated the negative effects described earlier. There is excellent synchronization of program teams, based on a common language, on reporting that is visible to everyone, and on the drum approach to scheduling. Plans are better constructed, with a major improvement in meeting schedule dates. Problems are identified on a timely basis, with milestone problems visible far enough in advance to take appropriate action. Priorities are clear to everyone.

ESL has not yet educated all of its suppliers on Critical Chain. However, it is able to identify any suppliers that cause problems in the Critical Chain. With this information, ESL is able to selectively take special measures with specific suppliers to reduce risk and encourage early delivery.

ESL does show the Critical Chain work plan and buffers to its customers. However, this is done with a full explanation, developed by ESL, of the meaning of the buffers and how they are used to protect the project. In addition, ESL is able to use this explanation to reinforce the important role that the customer plays in meeting critical milestones.

For the future, ESL would like to use its increased reliability and shorter lead times to gain a stronger competitive edge. Internally, ESL believes it can use the Pareto principle in buffer penetration to identify and remove the most frequent causes of buffer penetration, and subsequently reduce both cycle time and buffer sizes.

Critical Chain is now being implemented across other ESL subsidiaries worldwide.

Project Management Made Easy

Project Management Made Easy

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.

Get My Free Ebook


Post a comment