Embed Size (px)
Citation preview
Meeting Project Deadlines under Uncertainty: An Alternative to the Critical Chain Method
_______________
Christoph LOCH Fabian J. STING Dirk STEMPFHUBER Arnd HUCHZERMEIER 2011/08/TOM
Meeting Project Deadlines under Uncertainty: An Alternative to the Critical Chain Method
Christoph Loch*
Fabian J. Sting**
Dirk Stempfhuber***
Arnd Huchzermeier****
January 2011
* Professor of Technology and Operations Management at INSEAD Boulevard de Constance,77300 Fontainebleau, France. Ph: +33 (0)1 60 72 43 26 Email: [email protected]
** Assistant Professor of Operations Management, Rotterdam School of Management, Erasmus
University, Burgemeester Oudlaan 50, 3062 PA Rotterdam, The Netherlands, Ph: +31 (0)10-408 1869 Email: [email protected]
*** Research and Development manager at Roto Roof and Solar Technology GmbH, Wilhelm-
Frank Strasse 38-40 D 97980 Bad Mergentheim, Germany Ph: +49 (0)7931-5490-747 Email: [email protected]
**** Professor and Chair of Production Management at WHU Otto Beisheim School of
Management, Burgplatz 2, D 56179 Vallendar Ph: +49-(0)261-65 09-380 Email: [email protected] A Working Paper is the author’s intellectual property. It is intended as a means to promote research tointerested readers. Its content should not be copied or hosted on any server without written permissionfrom [email protected] Click here to access the INSEAD Working Paper collection
Abstract A fundamental problem in project planning and control (PPC) is the meeting of deadlines under conditions of schedule uncertainty and project workers with private information. The PPC process is complex, so an “optimal” method has yet to be found. The project management community is currently guided by heuristics; these include network planning and scheduling (including the critical path) as well as Critical Chain planning, which has become popular in the last decade. However, improved complex processes do not arise from analysis alone; they depend also on what amounts to an organizational search process. In striving for better PPC ethods, management scholars and practitioners should therefore search widely to explore a m
variety of approaches. This paper presents one case example of a company that has developed, through trial and error, an interesting alternative PPC system. In the general language of PPC methods, the system has four features that clearly differentiate it from other systems: (1) disciplined aggregate milestone planning combined with flexible weekly plans produced by the project teams themselves; (2) “visual” management that visibly shows the weekly status and promptly highlights problems; (3) fast problem resolution that offers project workers support and increases cross‐task collaboration while reducing the workers’ tendency to create individual time buffers; and (4) se of lower‐priority projects as a capacity buffer rather than a project time buffer. After this usystem was implemented, the company’s project management performance improved. One can never generalize from a single case study, but generalization is not the aim of this paper. Rather, we seek to provide PPC specialists (academics and practitioners) with one example of a successful alternative PPC system. As an effective “proof of existence” for such a system, the nsights from this case study broaden the debate and, we hope, will invigorate further search for nnovations in PPC methods. ii
1
1. Introduction A fundamental problem in project planning and control is meeting deadlines under schedule uncertainty when project workers have private information. The Critical Chain method (Goldratt 1997) was invented as an application of Goldratt’s (1984) theory of constraints (TOC) to project planning. This theory, which originally targeted the management of manufacturing systems, proposes to identify the capacity bottleneck (critical resource) in an “activity flow system” and then to protect the utilization of this resource with a buffer in order to maximize productivity of the entire system. Critical Chain (CC) applies TOC to project management through two guidelines (Wysocki 2009). First, incorporate resource conflicts across multiple projects by adding precedence constraints that extend the critical path of an individual project to a “critical chain”—a path that includes precedence constraints resulting from conflicts with other projects. Second, maximize a project’s productivity by combining all (individual task) safety uffers along the project’s critical chain into one project buffer that protects the project bfrom variations in task time. Critical Chain has had a significant impact on project planning and control, as evidenced by two trends. First, the project scheduling community has adopted the Critical Chain framework into its research program (Herroelen 2005). Numerous studies have sought to establish the right size for the project buffer (Newbold 1998, Herroelen and Leus 2000, 2001, Long and Ohsato 2008), and how the project buffer interacts with resource and feeding buffers (Herroelen et al. 2002, Van de Vonder et al. 2005). In addition, the CC framework as extended to how work packages should be prioritized across multiple concurrent projects that share common resources (Steyn 2002, Cohen et al. 2004) and to minimize risks (Bevilacqua et al. 2009). Overall, CC has been included as part of the stablished project management (PM) arsenal widely advocated in textbooks (Gray et al.
o e t l e2002, Gray and Lars n 2006, Mer di h and Mante 2008, Kerzner 2009, Wysocki 2009). The second trend is adoption of the Critical Chain method by companies across industries. Organizations such as Harris Semiconductor, Honeywell DAS, Lucent Technologies, Israeli Aircraft Industry, and U.S. Navy shipyards (among others) have een showcased for effective Critical Chain project management (Umble and Umble
, CC sb2000, Leach 2005). By and large eems to yield at least some positive results. That being said, it is not clear why CC tends to work or how reliable the benefits are. Much of the literature has focused on effects of the project buffer, and some has addressed the incorporation of cross‐project sequencing. Yet the question of how project management professionals can “optimize” a project planning and control system is so complicated—involving a combination of system management, decision making under uncertainty, and human psychology—that researchers and organizations de facto have to consider (variations of) solutions which have proven to work in management practice. A highly visible candidate for such solutions is the Critical Chain PM approach. It offers fairly predictable performance but is still only a heuristic, an approach that is acceptable rather than demonstrably the best. Of course, the same can be said of all other known planning and control approaches. Is the community of researchers and practitioners knowledgeable enough to arrive at better solutions to PPC through further analysis and optimization, or are other search methods needed to strike a path towards more effective PPC approaches?
2
In the case study presented here, a planning and control system was developed in the new product development (NPD) department of Roto, a German maker of roof windows and solar energy collection systems. Although a single case such as this is not necessarily generalizable, understanding the complex causality of project planning improvements requires that we study successful alternatives to critical path or Critical Chain planning. Roto’s planning system is one such alternative that is effective in its own environment. It thus provides a “proof of existence”: there are, indeed, rivals to CC that are different yet uccessful. Furthermore, our comparison of Roto’s system with Critical Chain affords an sopportunity to better understand the key building blocks of PPC approaches in general. Roto’s remarkable case illustrates how seemingly small changes in an existing project management approach can lead to a significant improvement in project performance. In this case, the PPC reconfiguration led to a substantial change of mind‐set in the NPD department, which in turn has affected the entire organization. In short, the new Roto system encourages project engineers to plan more tightly because it offers help to anyone who shows a “red card” at his or her workstation. There is evidence that this mechanism—through its aggressive timing and contingent pooling of task responsibility—definitely contributes to the effectiveness of Roto’s new product development. The system differs from CC planning in terms of flexibility. With its roots in a lean visual management philosophy, Roto’s PM approach keeps the overall, stage‐gate project plan at a relatively high level; the detailed tasks are planned weekly with the project team, and visual management quickly identifies and then solves problems. The new system also differs from CC in its management of resource interdependencies and buffers. At Roto, project interdependencies are addressed with a clear definition of priorities in the project portfolio (in effect, classifying projects as either “high priority” r “backup”). The new system does not use a project buffer; instead, it shifts resources oamong projects in the portfolio and uses the lower‐priority, backup projects as a buffer. Our study follows a single‐case design method (Yin 2009). Roto was by no means selected to be a “representative” or “typical” case of an organization that has to meet project deadlines under uncertainty. Rather, the case of Roto represents a unique example of an organization that has endogenously developed and implemented an alternative system to CC, which is significantly different from CC. We encountered this “speaking pig” (Siggelkow 2007) in the context of INSEAD’s Industrial Excellence Award (IEA) in February 2010. Explicitly after the conclusion of the IEA competition, we conducted a field study from September 2010 to January 2011. In total, we interviewed 10 key informants (including the CEO, the head of NPD, 2 project managers, the product portfolio manager, 3 project engineers as well as key persons outside Roto’s NPD department) in semi‐structured interviews lasting 1‐2 hours each. For this purpose, the (academic) authors visited Roto for two full days. Multiple sources that provide evidence for NPD performance were considered. The case write‐up and the final paper ere reviewed, commented, and whenever necessary corrected by multiple key w
informants to increase the reliability of our descriptions. In the remainder of the paper, we describe Roto’s system: how it works and how it differs from Critical Chain. We also examine how it was introduced—namely, in a way that overcame the fear and resistance typically associated with any method change in organizations. We conclude by suggesting lessons from this example for the discipline of PM and its further search for high‐performance planning and control systems.
2. Overview ory and Literature The classic critical path method emphasizes the longest path in a task sequence diagram while identifying the activities that constrain project duration. Goldratt (1997) proposed that task uncertainty leads project workers to add a margin of safety to their own estimates of task duration estimates, thereby protecting themselves from variation and resulting lateness (see Figure 1a). However, these (often tacit) buffers are badly placed in protecting the overall project from variation, and they are too conservative because hey do not account for averaging (it’s unusual for all or even most tasks to have “bad uck”).
of CC The
tl
1:
3
Figure Critical path planning and Critical Chain planning (based on Goldratt 1997) Goldratt therefore proposed that project workers should be encouraged to make average (or “realistic”) task‐time estimates—forgoing their individual margins of safety—with the promise of aggregate protection and no blaming in case of lateness. The individual safety margins are then combined into a “project buffer” that is shared by the whole team; by statistical averaging, the length of this buffer can be cut in half (Figure 1b). Goldratt believed that a safety margin often becomes a self‐fulfilling prophecy because of the “student’s syndrome”: the tendency to start any task at the latest possible moment. Thus, reducing these margins in the project buffer translates into a measurable
4
reduction of the project’s duration; in Figure 1b, this is reflected by a project acceleration of 10 time units. However, tasks are delayed not only by task variation but also by resource conflicts. In Figure 1c, planning acknowledges that the two tasks marked in bold use the same expert or equipment and so cannot be completed simultaneously. This information is indicated by an additional, precedence arrow—in response to which task times must be shifted to accommodate the sequencing. Hence the notion of criticality is likewise shifted from the critical path, which fails to acknowledge that there can be conflict in the use of esources, to the critical chain, which does acknowledge this fact. As Figure 1c shows,
crthe project is still protected with a project buffer and the ritical activities are protected with (in this case, two) feeding buffers. The Critical Chain planning that resolves contention over resources can now be generalized to resource contention across projects, thus incorporating activities that involve multiple projects. In summary: CC planning starts with the critical path; but then t (a) moves task safeties (or task buffers) into an aggregated project buffer, which (via istatistical averaging) reduces the total safety margin, and (b) resequencing tasks to prevent resource conflicts from delaying the overall project plan. Replacing task‐specific time buffers with a shared project buffer should have two additional effects. First, the project workers should no longer exhibit the student’s syndrome and so will not wait until the last minute to address a task. Second, project workers should have less incentive to inflate work (e.g., by adding extra functionality to a software module), which—in a phenomenon known as Parkinson’s law—involves workers filling up time buffers until the deadline and being disinclined to announce task completion in advance. Yet in the absence of individual buffers, everyone affects the completion of the project equally and so everyone can be supposed to have the same ncentive to ensure its timeliness. Therefore, the state of the project buffer (i.e., how
imuch of it has already been used) serves as an early warning sign of looming delays (Steyn 2001, Wysocki 2009). The project buffer should also protect project workers from the negative effects of uncertainty. That is, if the project leader does not penalize individual task “owners” for exceeding task deadlines—because the project as a whole is adequately protected from such variation by the project buffer—then the incentives for individual task bolstering should disappear (Lechler et al. 2005). In that case, project planners should then be able to obtain realistic, “median” task‐time estimates from workers instead of conservative stimates that each reflect individual time buffers. The overall project buffer can then be emade smaller than the sum of all task buffers, by virtue of statistical averaging, and so the project duration becomes shorter without increasing the risk of lateness. However, it is not entirely clear which of the Critical Chain components are crucial. Is it the project buffer (as the large amount of work in the scheduling community seems to suggest), the cross‐project sequencing of scarce resources, or the willingness of individual project workers to forgo their individual task safety buffers? Another question is whether individuals really are giving up their individual safeties: from a project member’s perspective, why should individuals advise less‐informed project leaders of completion times estimated without any safety? Finally, there is some
5
. Roto’s Projects and the Start of a New PM System
evidence (Raz et al. 2003) that the behavioral issues motivating CC methods—such as P the student’s syndrome and arkinson’s law—may be less prevalent than Goldratt
assumed. Project planning and control is complex (Herroelen and Leus 2005), and changing complex processes via innovation is inherently more of a search than an optimization (Rivkin 2000, Loch and Terwiesch 2007). It may not be appropriate to focus on a single “system design parameter” (e.g., the optimal project buffer size) before understanding the causal drivers of performance (e.g., how the existence of project buffers influences people’s motivation to strive for early task completion). The management community seems to lack a complete understanding of just how the building blocks of Critical Chain function and interact. Our understanding will be enhanced, then, only if we can document further improvements. Toward that end, management scholars and practitioners need to search broadly enough to examine a variety of approaches. omparing particular adoptions and their effectiveness may significantly add to our nderstanding of the holistic effects of planning and control systems, and this nderstanding should help us identify better system configurations in the future.
Cuu 3 Roto Roof and Solar Technologies In 1935, the Roto company was established in Germany when its founder, Wilhelm Frank, invented “turn and tilt” fittings for windows (nowadays fairly standard in Western European houses and so perhaps hard to imagine as an innovative product). Roto subsequently became the first company to produce this new kind of window hardware on an industrial scale. Today, Roto has 3,800 employees, and its two divisions—“roof and solar technology” and “window hardware technologies”—generated total net sales of €620 million in 2008. The roof and solar technology division, which developed the project management approach described in this paper, trails only the market leader (Velux) in Europe. But the division is significantly smaller than Velux, so its desired market positioning is, in the CEO’s words, to be “much faster in innovation than our major competitors. This is a trump card that we need to make the most of, although with a significantly smaller development team.” The division has started to emphasize industrial‐standard processes in the development, manufacturing, commercialization, and installation of window systems. Its product range includes roof indows, tailored roof windows for renovation projects, solar systems (solar thermal w
energy and solar power systems, either stand‐alone or integrated with roof windows), loft ladders, and spiral staircases. The division’s NPD department consists of 25 development engineers working on an average of 20 active development projects in the pipeline. The department has four experienced senior project managers and two junior project managers, and each of these six managers leads about three projects on a full‐time basis. (In addition, there are four enior engineers who lead small projects part‐time.) A typical NPD project is the evelopment of a complete roof window, a recent and representative example of which s the “Roto Designo R8 top‐hung pivot roof window” (see Figure 2).
sdi
Figure 2: Installed roof window (left) and its profile (right)
Integrated platform windows like the Designo R8 have up to 400 parts and require about six person‐years of development effort (including variants). Every window system offers two material variants (wood and plastic main profiles), and its main components consist of aluminum cover shrouds, multiple layers of glazing, metal fittings and hinges, handles, electronic window‐opening controls and drive units, devices for automatic ventilation, thermal and acoustic insulation, locking system, devices for solar thermal applications, interior sun screening, and integration into all possible roofings. On these components and the final window the division holds more than 350 patents. The complexity of such a project may be best compared to the development of “white goods”: major household appliances such as dishwashers or refrigerators. Yet in contrast to white goods, Roto’s window systems are completely designed for customized anufacturing and installation. Therefore, to develop the Designo R8 meant developing m
a modular window platform rather than a single window assembled in mass production. Deadlines have a natural importance for the NPD department. First and foremost, because annual trade fairs set the “pace of innovation”, new products simply must be presented at them in order to retain market share in the saturated and highly competitive construction markets in Western Europe. Customer expectations (sparked by Roto’s salespeople) of regularly launched innovations are high and cannot be disappointed. Development projects are typically kicked off with the next season’s trade fair as a deadline. Second, although at a lower clock speed than the annual trade fairs, tightened energy regulations impose additional deadlines for the NPD department. National energy‐saving regulations have a critical impact on what types of windows will be successful in the market, especially as customers become increasingly concerned with prospective subsidies for construction of low‐energy housing. In Germany, for instance, the energy law “EnEV” that regulates construction standards is tightened lmost every other year with respect to new requirements for windows. (It was ightened in 2002, 2004, 2007, and 2009; the next planned amendment is in 2012.) at
6
History of the System Since the turn of the century, Roto has explicitly worked on improving its project management competence. It has used a standard stage‐gate process since 2005 and formal portfolio prioritization since early 2009. Each major project is led by a senior
7
project manager, who—in addition to the major project—also handles one or two minor projects. (Some minor projects have junior project managers with less experience, e.g., project workers who are beginning to broaden their activities.) Portfolio manager Frank endel supports the project managers with methodological knowledge and also W
coordinates across projects. The stage‐gate process has five milestones at the projects level and another five for each major component. Thus, a major project can easily have 100–150 detailed milestones. A weekly schedule links the overall project plan to the many detailed activities; this schedule is derived from the stage‐gate plan and the current status every week, and it is detailed and tightly controlled. Until 2009, this control was summarized on a large chart n a meeting room directly adjacent to the engineering open space. The chart listed, for ieach project worker, a set of tasks marked as pending, done, or late. In the autumn of 2009, Dirk Stempfhuber (the head of product development and one of this paper’s authors) participated in a “visual management” initiative in manufacturing. Thus, as we describe here, Roto’s alternative to CC is rooted in lean principles. A lean system is characterized by simple processes that have been optimized over time to eliminate waste caused by defects, movement, setups, and/or waiting (Martin 2008, 40). A lean system consists of a number of operational components, among them 5S (standards), JIT, TPM, SMED, and the visual workplace (170). In a visual workplace, the tatus of the process workflow and the work tasks can be seen at a glance; this allows skey workflow metrics to be readily seen and controlled by local work teams (171). Stempfhuber was asked whether project management in his department was truly visual. His first reaction was: “Yes, of course, we have the chart in the meeting room that anyone can go to and see what’s going on, and we track the engineers’ hours by project.” But upon closer examination and reflection, he concluded that the weekly project control in the meeting room was not really used by the engineers.. The chart aimed at mapping the division’s overall project progress. However, engineers did not assume responsibility for the accuracy of single task progresses shown on the chart. It was too much effort to go there and constantly make changes, so the chart was often out‐dated. Hence project managers were forced to go directly to the engineers’ desks to find out what was really going on, which in turn further reduced the urgency to update the control chart. So even though project control formally included the large chart as isualization tool, it was far from the spirit of visual management— in fact the chart was vnot used to manage projects. Thus, Stempfhuber concluded that he could indeed improve transparency. He, Wendel, and the project managers decided to bring the control chart from the meeting room to each project desk: a chart, above the desk, that showed the engineer’s tasks for every day of the week. The chart’s purpose was to increase the visibility of important, project‐critical tasks assigned to this individual engineer. The engineers were responsible for their own charts, which were required to reflect the latest status. This requirement increased engineer involvement in the process of identifying problems as soon as possible. To more fully exemplify the principle of visual management, engineers were asked to put up a red flag—referred to as a red card and visible to anyone walking through the open space—immediately when a critical task was becoming late enough to affect other tasks. In contrast, a green card indicated that all tasks were on schedule.
8
But the red card naturally raised fears. Immediately flagging the red card in case of a delay made people feel vulnerable and exposed to criticism. Furthermore, in football soccer) a red card is the signal that banishes a player from the field—hardly a positive (symbol. It was clear that engineers could not be forced to issue themselves red cards. Thus, the management team decided that the engineers needed to be encouraged. Toward this end, Stempfhuber promised his staff that anyone who raised a red card (a) would not be criticized and (b) would get help, within 30 minutes, from either Stempfhuber, Wendel, or the project leader. One of these individuals will come to the engineer’s desk and help find a solution. If a solution cannot be found immediately, then a temporary “red card team” is formed as a task force. This team includes the task owner, the project leader, and selected experts working on various projects; it also includes either Stempfhuber or Wendel. As long as the issue has not been resolved and ence the red card has not been rescinded, it is the red‐card team’s (and not solely the
p ahtask owner’s) res onsibility to t ckle the issue. These were but promises for which proof could only be given over time, but the engineers trusted Stempfhuber enough to try. By January 2010, the weekly planning charts and red cards were in place. The first red card was raised in February, when a drawing was delayed that absolutely had to be sent because otherwise the mould‐making supplier would be put behind schedule. The project engineer could not get ufficient priority in the drafting department; however, the red‐card team helped him to
r n ssget it and so, in the end, the d awi g went out ju t in time. This was the beginning of the new system. The reader should note that nothing substantial had changed in project control at first glance: the weekly control chart had been decentralized by moving to the engineers’ desks, a red card had been added so that delays were prominently flagged, and a help routine had been put in place. In other words, there was no new information and there were no new activities—only a reorganization of what had already been there. Yet this was the nucleus of a mind‐set change and of an emerging alternative to the CC method. Not all change is revolutionary; his story is important because it shows how an initially small change produced large ffects. te 4. The New Planning d Control ystem The project portfolio (at the time of this study, 21 active and 7 waiting projects) is discussed monthly in the new product steering committee, which comprises the division CEO and the heads of development, purchasing, manufacturing, and product anagement. This body is authorized to cancel projects, to approve new projects, and to
an S
mprioritize all projects. Each project follows the established stage‐gate process, which begins with a rigorous customer needs document driven by product management. (There are some technology development projects, but they are the exception.) By the first milestone, there is a business plan and a detailed specification document, which is then executed. Frank Wendel, the portfolio manager, holds weekly meetings with all project managers, and each project manager formally meets with his team every week as well as daily for brief
9
updates. The Friday project meeting gives the engineers the information they need to produce a detailed plan for the next week, which is posted above their desks. The planning and control system does not use project buffers. Stempfhuber looked at the CC method in the fall of 2009 and concluded that project buffers were infeasible at Roto. The reason is that the company’s deadlines are set externally: by the annual trade fair, which imposes timely product presentations; and by the necessity to introduce new products in April, at the beginning of the active building construction season. Roto instead uses a lowerpriority project buffer: if one of the seven major projects needs extra capacity in order to solve a problem that threatens its deadline, this capacity is taken from the 14 minor projects. Although these are not massive capacity shifts (on the order of 5% of total capacity), the result can be delay of a minor project. In that case, the minor roject’s deadline is adjusted by the steering committee or it is given priority to get back pon track should that deadline’s viability be threatened. There is no significant capacity buffer for the department as a whole, and Wendel estimates that the engineering organization is 97% utilized. But this does not mean there is no flexibility. In the first place, some of the projects have a lower priority. Second, only about 70% of each week is planned for project work; the rest is for vacation, administrative tasks, and training. (When things get tight, administrative tasks and training can be delayed.) Third, engineers do work overtime when a deadline looms nd the project is behind; thus, the 100% capacity limit is flexible. All of these factors ahelp Roto to achieve deadlines in spite of task‐time variation. Roto also deviates from CC by not sequencing activities across projects to accommodate resource conflicts. This is because new product projects are much too variable and fluid to allow for the scheduling of resource conflicts. Such conflicts (e.g., two projects need the same expert, or equipment, at the same time) are dealt with, as they arise, either by informal mutual adjustment across projects in the weekly plan or by imposing project priority if the conflict is unavoidable. Serious resource conflicts are rare, and their perfect” avoidance would not justify the significant complications that a Critical Chain “planning system would entail. The red cards have become fully accepted by the project engineers (Figure 3). During the first 10 months of the system’s operations, 30 red cards were flagged. Stempfhuber’s characterization, that “red cards are not tools to evaluate people but a help to characterize the work”, has been internalized by the engineers. For example, an electrical designer proposed that a cable be integrated into a window frame (to drive a window‐closing motor). When manufacturing rejected the design because of anticipated quality issues, the designer posted a red card to indicate the problem; then a task force elped him to find a solution of similar functionality that also addressed the quality hproblem. The cards are viewed not as a threat but rather as a source of help. Mr. Brüggen, a mechanical part designer, describes it this way. “The red cards take a burden off me because [before] I was alone responsible for the solution decision that I made. Now I have support with the approach, which gives me confidence. More than that, if I fall, I fall less hard because we work together and help one another. We all do this because we know that the next problem could hit oneself.”
10
Figure 3: Weekly plans of project engineers with one red card
The red cards have the direct (and initially hoped‐for) effect of “visual management”: they have enabled the organization to react more rapidly to problems. In the past, problems took longer to detect—by which time some of them had already spiraled into larger issues. Product performance issues previously went undetected for as long as a month (when formal tests were conducted); now, however, even the suspicion of a roblem triggers a red card right away. Thus, emergency activity has become more pefficient and less of a burden. n addition, the red cards have had several effects that were not initially foreseen. Four ffects in particular are noteworthy. Ie 1. Reduction of individual task buffers. Roto has never used explicit buffers and has always followed the policy of planning as realistically as possible. This approach is also built into the overall project plans, whose tight timing stems from the management team’s experience with project execution times. Even so, the engineers’ know that, when a problem occurs, they will get help and time to work on the problem; this assurance has made task‐time planning more realistic. According to Wendel, “They all know the end date for the project, which is not a management invention but has market consequences if missed, and they also have other projects to work on.” Jörg Scheffel, a project manager, adds: “The fact that people are not threatened by a problem increases their willingness to give tight task‐time estimates.” One project engineer explains this result in terms of the help that the engineers receive: “Previously, I had to deal with problems myself, so I had to give myself a buffer, but now I know I get help and I won’t be left alone, so I’m willing to plan a bit tighter.” Of course, not everyone reacts the same, and some people ay that they plan their tasks exactly as they did before. But no one feels that task‐time sestimates have been stretched. This is the same effect alluded to in discussions of the CC method. But speculation that employees will give up their personal buffer for a collective project buffer has not been verified, and some doubt it. But here we have evidence of a specific motivation that engineers acknowledge: getting help (and thus sharing responsibility for decisions) makes them feel safer, so they are willing to plan tighter. Receiving help has a more visible and tangible psychological effect than that of a project buffer, whose effect the
11
worker will see only (if at all) at the project’s end. 2. From emergency problem solving to process improvement. Once the organization learned that problems could be raised and solved via the red‐card process (without engineers feeling personally threatened), they applied the same approach to problem solving in the absence of a pressing emergency. Stempfhuber is also responsible for technical services, a group that supports sales as well as carpenters who face product complaints. So the first nonemergency application of the new process was the idea of declaring a “product complaint of the week” based on all customer feedback received. Technical services chooses an important complaint, and the relevant specialist from NPD brings this complaint as a red card into the development process. An engineer with the appropriate subject matter expertise “owns” the problem and is assisted by the whole team, if necessary, when solving it. For example, a recent customer complaint was this: “The rain sensor on my window triggers the electric motor to close the window not only when it rains but also in the morning after heavy dew.” The red‐card problem‐olving process found a solution within a week: reinforce the heating unit of the sensor
esso that it would be strong enough to evaporat dew but not rain. The logical second step in this progression would be a “process improvement of the week”, an idea with which the NPD organization is just beginning to experiment. For now, management declares a topic of the week (e.g., improving the productivity of meetings to reduce the sensation of wasting time, streamlining the hourly billing of engineers’ time to projects, quickly processing the contents of one’s in‐box). The engineers then propose ideas, one of which is decreed to be a top‐priority improvement to be tackled. Of course, the procedure may be changed in response to experience, and Stempfhuber believes that it can also be successfully applied to other administrative departments (e.g., manufacturing has already adopted it). 3. Communication and collaboration between project workers. When a project’s task buffers are reduced or even absent, each task naturally depends more on completion of the previous task. Because tasks are no longer decoupled, lateness in one task immediately affects its successors. In CC, this notion is captured by the relay metaphor: once a Critical Chain task is completed, the successive task’s owner “takes the relay over and starts running” by working on the next task. Unbuffered changeovers equire close collaboration between two adjacent project workers; a smooth changeover rwithout delay requires some form of coordination. However, collaboration in Roto’s system goes further than in CC. Roto’s system fosters strong cohesion between project team members that is based on more than stricter time dependency. First, the raising of a red card makes it clear to all those involved in the project that there is an issue requiring attention. Project manager Scheffel describes how communication among process workers has intensified: “When we go for lunch, we of course observe when somebody has set the red card at his desk. Then our discussion starts: You must have raised the card this morning. What is your problem and why?” Second, a stronger cohesion is achieved in that the red‐card teams take on common responsibility for the troubled task; this typically includes some experts working on different tasks within the same project. Project engineer Brüggen concludes that this mechanism “has taken some off the blinkers off. The interest and the stakes that you have got in your colleague’s work have definitely increased. When you team up for a red
12
card of someone else’s task your efforts are then concentrated on the same task anyway.” Electrical system designer Grimm adds: “The red cards make interdependence visible, sometimes I cause a red card for you, and then you one for me. It forces us to ollaborate more and be closer together, and we also learn more about what the others cdo.” Thus, the red card has become a device of improving collaboration within the NPD process. It is interesting that the cohesive power of the red cards was not amplified by the preexisting monetary reward system. (Under that system, NPD employees are ollectively granted an annual bonus based on the overall departmental delivery erformance; this system remains unchanged.) cp 4. Communication and collaboration with other departments. Perhaps the most surprising effect of the red cards is that they have also improved the collaboration between engineering and other departments. The first important partner of engineering is purchasing. In 2008 this department changed its processes to focus on developing and evaluating strategic suppliers, leaving operational buying to manufacturing. The red‐card process is a welcome opportunity for purchasing to improve its own supplier evaluation: whenever some problem affects a supplier, a red card is transferred in duplicate to purchasing (who simplify it into their own format, known as a “Pareto sheet”). Examples of such problems include a supplier not delivering, or delivering incorrectly, or a necessary tool whose delivery has been delayed. Just as in engineering, the red card helps those involved to focus on and process the issue more quickly. Conversely, if it’s a strategic supplier with the problem—for example, information being ransferred too late or incorrectly to the supplier—then purchasing triggers a red card twithin engineering. Thus, the red cards have been a vehicle for improving cross‐department collaboration. In the words of Mr. Farrenkopf, the head of purchasing: “Our communication quality has ecome more targeted and therefore better, both sides react faster, and we have much bmore of a feeling of working as a team across the departments.” Improved collaboration with purchasing is not the only benefit; product management also sees a positive effect. “Our products, as well as the product documentations, must be simple because many carpenters of varying skill levels install them”; so states Mr. Meinikheim, a product manager for roof windows. This department has existed since 2002 but had difficulties being heard in the NPD process until introduction in 2005 of the structured stage‐gate gate process. That gave the department mandatory sign‐off ower, ensuring that simplicity and usability concerns were given greater weight in pdesign decisions. The relation between Product Management and NPD is not free of tension because opinions about prioritization within the project portfolio are always different. But Meinikheim appreciates the red‐card process: “We receive red cards from engineering when actions by the sales force or the product documentation are concerned. For example, our customers incorrectly ordered some windows because the differentiation between left‐hand and right‐hand use was missing in the order form. The red‐card process is useful because it structures and focuses the solution analysis. We do not yet give engineering red cards, but that will come, too.”
13
5. The Impact: What Has Changed? An intangible effect for the engineering department is that its “reputation” in the company has improved: engineering is now seen as a leader in process improvements among the administrative departments outside manufacturing. But the department also an already identify specific project benefits—even though the new system has been perating for lessco
than a year.
Late changes. A critical milestone for engineering changes is the “G3” milestone that authorizes (manufacturing) tool production: any change after this milestone is much more expensive because a tool might have to be changed. The effect of the red cards has been more changes before G3 and fewer changes after G3. In 2009 there were six changes after the G3 milestone; in 2010, only three. The red‐card process has thus achieved front‐loading (Fujimoto and Thomke 2000), an earlier approach to solving engineering prob el ms. That approach can reduce project costs (immediately) and schedules (over time).
Milestone delays. The number of project‐level milestone delays has decreased significantly. Two “old” projects that were first marketed in early 2010 missed, on average, 28 (out of about 100) project milestones. In contrast, a new project just being introduced encountered d elays in only 12 (of about 100) project milestones. This improvement directly translates into faster completion times.
Processing time per red card. In the first months, bringing a red‐card issue to conclusion took about 20 days. This has now been whittled down to an average of six or seven days. The goal for the near future is fewer than five days (i.e., within a work week).
Effects on employees. Has the new planning and control system caused more stress for the project employees? Indeed, two engineers mentioned that the more tightly planned task times, along with the public revelation of any problem, “increase pressure”. However, these engineers also state that the pressure is reduced because they are no longer left alone with the responsibility of making calls for the solution approach. Moreover, the faster solution of problems increases the level of project control—in other words, the employees live less “in chaos”, and this can reduce stress markedly. On ba
onlance, one may conclude that personal stress within the
organizati has probably decreased or, at least, not increased. Effects on other projects. It is true that some secondary projects have been delayed.
However, a well‐known principle of flow control and business process reengineering (Adler et al. 1995 and 1996, Loch 1998) is using “backup” work, which is less time sensitive, to ensure timely completion of high‐priority projects. So far, the resulting delays have been either minor and not damaging or were avoided altogether via reprioritization. The situation does bear watching, though, to ensure that indeed only nondamaging delays are allowed.
Implementation of the new project planning and control system is an ongoing process. For example, the initial red‐card procedure listed the issues and actions on a flip chart. But it quickly became clear that the flip chart was unwieldy and hard to use. Roto then designed forms on which the engineer entered the issue with reasons and actions; these forms were to be stuck into pockets on the weekly plan above the engineer’s desk. This had the advantage of information being reiterated. Similarly, both the extension from
14
problem reactions to process improvements and the integration of other departments emerged gradually. The department is currently seeking to sharpen the progress indicators. Also, portfolio management needs upgrading, since carrying high‐ and low‐priority projects in the same portfolio runs the risk of neglecting the projects of lower priority. This consideration is especially pertinent given that some of the low‐priority projects are technology development projects, such as green tech or new materials. They are “low priority” not because they are unimportant (indeed, they are critical) but rather because they do not have fixed market deadlines. They need to be protected in some way—erhaps cut into partial progress milestones that are given deadlines. In short, the ethod is dynamic and will never be “complete”.
pm 6. Discussion After an iterative implementation and improvement process, the Roto R&D department now has a project planning and control system that is a serious alternative to stablished systems such as CC. Table 1 summarizes the comparison between CC and eRoto’s system. Withcont
this comparison, we can identify several advantages that are relevant in certain exts.
The system requires no project buffer and instead uses the project portfolio (in the form of lower‐priority projects) as a capacity buffer. It would be unwise to make general statements about which buffer type is better, but Roto’s circumstances (of fixed, market‐imposed project deadlines, such as trade fairs, and tight plans) exemplify that in some cases a project schedule buffer is difficult to use and to accept. A working alternative to project buffers is therefore a useful asset.
At Roto, cross‐project capacity conflicts are managed dynamically, whereas the CC method would schedule such resource conflicts by adding sequencing constraints to the schedule. But many projects are too fluid for such conflicts to be scheduled much in advance. Not only that, the added sequencing constraints embody, in effect, the combined uncertainty of both projects involved, so tasks can be “pushed around” by events in either project. For this reason, the scheduling of capacity conflicts usually entails considerable rescheduling—unless it is done near the actual time of resource sharing. Yet the closer the event, the less a formal schedule is even needed. This is, in essence, what the Roto system does. It negotiates resource conflicts flexibly
e y n r nwithin th weekly detailed activit pla s, in acco da ce to which the engineers adjust to one another when working with shared experts or equipment.
Accounts of CC methods indicate that protection by the project buffer “should” motivate employees to give up their private task buffers. However, the incentive to make themselves vulnerable in this way is not clear. The Roto system tackles this issue head on: not only are the engineers protected (not blamed), they also receive help that relieves them of the burden of making decisions alone (and thus, not incidentally, from the burden of making mistakes). This is a clear mechanism for reducing engineers’ incentives to maintain private buffers, one that is borne out by their perceptions of how the system operates. Indeed, the fairness of the process seems to have greatly facilitated its implementation and the system’s current effectiveness. In a sense, management spent more effort explaining the meaning of
15
the red cards than it did pursuing and pushing for hard buffer reductions. This fact suggests that the implementation and the method both succeeded in being perceived by the employees as fair.
Table 1: Comparison of Roto’s System with CC
Key elements of PM approaches
Critical Chain approach Roto’s PM approach
Goals
‐ Meeting project’s due date while satisfying cost and quality constra
‐ Maximize project throughput in a ints
multiproject environment
‐ Meeting project’s due date while satisfying cost and quality constraints
‐ Maximize project throughput in a multiproject environment
Planning principles
‐ Set a project completion time for each project
esource ‐ Identify CC: critical path plus rconflict sequencing
‐ Plan CC with latest start dates ‐ Add a project buffer and feeding buffers, as a percentage of task safeties, to protect project from task uncertainty
‐ Tasks on the critical chain begin to follow the relay metaphor
‐ Set a project completion time for each project
‐ Establish project priorities s to ‐ Use average task completion time
identify critical path ‐ Plan critical path with latest start dates
‐ Red‐card process mobilizes fast‐rity response resources for high‐prio
projects when problems occur wer‐‐ Resources are taken from lo
priority projects
How uncertainty is anticipated in the planning process
‐ Pooled time buffer protects compledate of entire project
‐ Feeding and resource time buffers
tion
protect CC from delayed tasks leadinginto it
‐ Prioritize CC and subordinate every other task
‐ “Red‐card task force” shifts development resources to a troubled task
‐ Capacity buffer, in form of low‐priority projects, ensures resources for problem solving (uncertainty response) within high‐priority projects
How human behavior (e.g., student’s syndrome, Parkinson’s law) is influenced
‐ “Elimination” of individual task buffers
ning (cut existing times by half) to counteract individual safety plan
‐ Promise not to penalize for task lateness
‐ Encourage raising a red card when a alistic” problem occurs; emphasize “re
time estimates ‐ Task force: help and collective shouldering of responsibility for a troubled task
How the project’s progress is measured
‐ Consumption of project buffer relative to the project stage
‐ Visual management via traffic‐light system: red cards are set when task
o completion is delayed enough tendanger other tasks
Responsibility for monitoring
‐ Project leader monitors project’s buffeconsumption
‐ Team members monitor one another because one person eating into the buffer affects the others
r
‐ Shared monitoring, but project worker’s responsibility to raise red card
‐ Visible red card, plus collaboration in eameam
task force, informs entire project t‐ Weekly monitoring in the project t‐ Weekly monitoring with portfolio manager and project leaders
Responsibility for ntervention i
‐ Project leader intervenes when buffer consumption is critical
‐ Intervention by red‐card team (task owner plus experts); shifting collaboration creates
llainterdependence and co boration Roto’s project management approach inherently encourages increased
communication and extended, decentralized collaboration. The red cards have
16
proven to be a simple yet effective vehicle for communication and problem solving for single project tasks, entire projects, and even across departmental boundaries. In contrast to CC, the coordination task has been delegated from project management down to the project workers themselves. Of course, NPD management initially had to steer and substantially control the efforts, but it is withdrawing gradually and
the he a leaving red‐card processes to t project workers. In sum, Roto’s pl nning and control system is characterized by being more decentralized than CC.
Finally, the Roto PPC system has a dynamic, “process improvement” flavor that arises from working on issues rather than taking a relatively static, “scheduling” approach, as in CC and other such systems. The improvement mind‐set, which stems directly from the “visual management and continuous improvement” roots that grounded the original idea, has helped Roto’s engineering department integrate other departments and continue driving the system further. This built‐in improvement dynamic is missing in CC and similar systems.
For now, the Roto system constitutes but one example. We do not know how applicable it is to different organizations and under different circumstances. However, this example is interesting enough to be shared with the project management community—not only ecause the Roto system offers the (potential) advantages just detailed but also because bthis example teaches us how such systems may evolve. In particular, managerial systems are employed in environments that are usually too complicated and insufficiently understood to be derived from an organization model that serves as input to an optimizing method. Furthermore, when model‐based optimization is used, there is always the risk of its being incomplete. The CC method is a case in point. This method is based on a model of the organization (the theory of constraints) that recommends identifying the bottleneck resource and then protecting it with a buffer. The theory of constraints and Critical Chain have produced an impressive model‐based method; CC is widely used and, indeed, has influenced the Roto R&D department. However, even though it protects a project’s critical chain, this method remains incomplete. It does not explicitly account for employee motivations; it does not recognize that schedule buffers are sometimes inapplicable; it does not take into account the high variability of cross‐project constraints in an uncertain project environment, which renders a strictly scheduling‐oriented approach difficult; and it is tatic—neglecting the power of continuous improvement and collaboration across the smany actors that play a role in a project’s success. Critical Chain has done about as well as a model‐based, “technology push” method can to spark initiatives, but it is simply insufficient to address the range of project planning and control challenges typical of a modern‐day organization. We have shown that Roto had to go beyond CC in order to achieve its improvements. In other words, standard implementations of CC (or any other method) are bound to be of limited usefulness. Each individual organization must search to find answers to its own problems, which may be similar to but never the same as the problems and solutions of other rganizations. It is this search, in the context of an “improvement” mind‐set, that xpands the kernel of a good idea into a powerful dynamic yielding unique capabilities. oe
17
In addition to proclaiming another interesting PPC variant, the Roto case demonstrates he course that an improvement search may take. It also suggests that the quest for mprovement reflects a logic and attitude that will pay dividends to project managers. ti References Adler, P.S., A. Mandelbaum, V. Nguyen, and E. Schwerer. 1995. From project to process management: an empirically based framework for analyzing product development time. Management Science 41, 458–484.
Adler, P.S., A. Mandelbaum, V. Nguyen, and E. Schwerer. 1996. Getting the most out ofyour development process. Harvard Business Review Mar/Apr., 134–152.
Bevilacqua M., F.E. Ciarapica, and G. Giacchetta. 2009. Critical chain and risk analysis International Journal of Project applied to high‐risk industry maintenance: A case study.
Management 27(4), 419–432.
Cohen, I., A. Mandelbaum, A. Shtub. 2004. Multi‐project scheduling and control: A process‐base comparative study of the critical chain methodology and some alternatives. Project Management Journal 35(2) 39–50.
Fujimoto, T. and S. Thomke. 2000. The Effect of ‘Front‐Loading’ Problem‐Solving on Product Development Performance. Journal of Product Innovation Management 17 (2), 128–142.
in. The N Barrington. Goldratt, E.M. 1997. Critical Cha orth River Press, Great
e Goal. Gower, Aldershot, UK. Goldratt, E.M. and J. Cox. 1984. Th
Gray, C.F., and F.W Larson. 2006. Project Management: The Managerial Process. MacGrawHill, NY.
Gray, V., J. Felan, E. Umble, M. Umble. 2002. A comparison of drum‐buffer‐rope and critical‐chain buffering techniques. Chapter 25 in: Slevin, D.P., D.I Clelland, and J.K. Pinto
The Frontiers of Project Management Research(Eds): . Project Management Institute, Newton Square, PA, 419–434.
roject scheduling:
Herroelen, W., R. Leus, and E. Demeulemeester. 2002, Critical chain pDo not oversimplify. Project Management Journal 33(4), 48–60.
Herroelen, W. 2005. Project Scheduling—Theory and Practice. Production and Operations Management 14(4), 413–432.
Herroelen, W. and R. Leus. 2000. On the merits and pitfalls of critical chain scheduling. Proceedings of the PMI Research Conference 2000, June 21‐24, Paris.
Herroelen, W. and R. Leus. 2001. On the merits and pitfalls of critical chain scheduling. Journal of Operations Management, 19(5), 559–577.
Herroelen, W. and R. Leus. 2005. Project scheduling under uncertainty: Survey and s. European Journal of Operational Research, 165(2), 289–306. research potential
Kerzner, H. 2009. Project Management: a Systems Approach to Planning, Scheduling and th n. Controlling. Wiley, Hoboken, NJ, 10 editio
Leach, L.P. 2005. Critical Chain Project Management. Artech House Professional Development, Boston, Library, 2nd edition.
18
Lechler, T.G., B. Ronen, and E.A. Stohr 2005. Critical Chain: A NParadigm or Old Wine in New Bottles? Engineering Manageme
Loch, C. H. 1998. Operations Management and Reengineering. European Management
ew Project Management nt Journal, 17(4), 45–57.
Journal 16, 306–317.
Loch, C. H., and C. Terwiesch. 2007. Coordination and Information Exchange. Chapter 12 in: Loch, C. H., S. Kavadias (Eds). Handbook of New Product Development Management. Butterworth Heinemann/Elsevier.
Long, L.D., and A. Ohsato. 2008. Fuzzy critical chain method for project scheduling under resource constraints and uncertainty. International Journal of Project Management 26(6), 688–698.
Operational Excellence: Using Six Sigma to Translate Customer Value don: Auerbach.
Martin, J.W. 2008. Through Global Supply Chains. NY, Lon
J. Mantel. 2008. Project Management: a Managerial Approach. th
Meredith, J. R., and S.Hoboken, NJ: Wiley, 7 edition.
Project management in the fast lane – Applying the Theory of Newbold, R.C. 1998. Constraints. The St. Lucie Press, Boca Raton.
Raz, T., R. Barnes, and D. Dvir. 2003. A critical look at critical chain project management. Project Management Journal 34(4) 24–32.
nagement Science 46(6): 824–844. Rivkin, J. 2000. Imitation of Complex Strategies. Ma
Siggelkow, N. 2007. Persuasion with Case Studies. Academy of Management Journal 50(1): 20‐24.
Steyn, H. 2001. An investigation into the fundamentals of critical chain project scheduling. International Journal of Project Management 19(6), 363–369.
Steyn, H. 2002. Project management applications of the theory of constraints beyond critical chain scheduling. International Journal of Project Management 20(1), 75–80.
he
Umble M. and E. Umble. 2000. Manage Your Projects for Success: An Application of tTheory of Constraints. Production and Inventory Management Journal 41(2), 27–32.
Van de Vonder, S., E. Demeulemeester, W. Herroelen, and R. Leus.. 2005. The use of nagement: the trade‐off between stability and makespanl of Production Economics 97(2), 227–240.
buffers in project ma . International Journa
Wysocki, R.K. 2009. Effective Project Management: Traditional, Agile, Extreme. Wiley, edition. Indianapolis, 5th
in, R.K. 2009. Case Study Research – Design and Methods. Sage, Los Angeles, 4th edition. Y
