Accelerating Projects by Encouraging Help

In turbulent business landscapes with rapidly changing technological platforms, many organizations are trying to accelerate product introduction cycles by prioritizing project delivery. However, many projects have two characteristics that make optimal delivery times elusive: First, the projects themselves tend to involve uncertainty (for example, they develop a new product function whose feasibility has not yet been established); and second, the workers have information about the status of their project tasks that is not observable to anyone but themselves, which many don’t share. Therefore, behavioral issues are as important in project timeliness as diligent planning. These behavioral issues include the following:

• Willingness to communicate and collaborate under uncertainty and interdependence.1 Why should employees seek help for a problem or help resolve a colleague’s problem when they can leave the problem to later stages or hide behind their own task responsibilities?
• Individual buffers. If project workers face penalties for missed deadlines, why should they share private knowledge about task duration rather than “padding” their estimates of the amount of time they need to complete a task?
• On-time incentives. Why should employees exert themselves to finish their assigned tasks rather than fill time with fringe work or free ride on extra time buffers built into the project?2

This article examines the difficulties of project planning and execution and describes a management innovation at Roto Frank, a German company that produces hardware for industrial and residential windows and doors. Roto, headquartered in Leinfelden-Echterdingen, Germany, has augmented its project control system with a formal help process that encourages workers to seek and provide mutual assistance. We found that Roto’s help process achieved a measurable improvement in project cycle time without changing formal incentives or other management systems. The initiative’s success is based largely on two factors: establishing psychological safety, and encouraging cooperative behavior by emphasizing interdependence among workers. Because of its flexibility, we argue that this help process has the potential to accelerate projects in many environments.

Roto’s Management Innovation

Of course, project management professionals have long thought about how to plan and execute projects in robust ways. An important strategy for handling uncertainty in projects is creating buffers of extra time.3 But if buffers are applied at the task level, task owners sometimes hide behind them and almost always use them. The alternative is to aggregate the individual buffers into a combined project buffer, although it remains unclear how workers can be encouraged to give up their individual buffers.4

In general, it’s difficult for incentives to encourage people to work hard, reveal private information and collaborate with coworkers.

Another approach to uncertainty is to set task goals or deadlines.5 However, there are side effects: Unless penalties are set for not meeting the goals or deadlines, workers tend to estimate their project completion times too optimistically (a problem often referred to as the “planning fallacy”).6 Yet when workers are threatened with penalties for being late, they tend to protect themselves by building safety margins into their announced task-time predictions, sometimes referred to as “padding.”7 In summary, studies on project planning work have focused on rational management, ignoring behavioral issues (for instance, reporting exaggerated estimates of task duration).

Yet another approach to project planning is the application of “lean manufacturing” concepts to project management, which refers to principles including value for the customer, smooth flow of products through the value-creating steps and constant efforts to eliminate defects.8 (In fact, Roto’s project planning innovation was originally triggered by an idea from a lean-thinking workshop.) Lean thinking promotes adherence to flow standards and quick correction of deviations. However, this can’t be directly applied to product development project management because new product development projects are characterized by uncertainty about the nature of the tasks; typically, standards have yet to be established. Moreover, until the system is worked out, the interdependencies among the elements of the system are not known; one worker may cause unforeseen deviations for another.9 Hence it is not clear what a “smooth flow” is and what needs to be monitored.

The final method that seems similar to Roto’s system is “agile development” (a term coined in software development), which includes flexible development processes that incorporate quick feedback and iterations, and product architectures with built-in flexibility.10 Although agile development systems rely on collaboration among project employees, they don’t explicitly encourage such collaboration — a key change that was developed at Roto.

In developing a project planning and monitoring system that encouraged project workers to reveal private information about their tasks, Roto did not rely on incentives. In general, it’s difficult for incentives to encourage people to work hard, reveal private information and collaborate with coworkers.11 Information disclosure and collaboration require that the workers feel mutual obligation, as well as safety in reporting problems.12 Behavioral research has shown that employees can be more open to sharing what they know when offered psychological safety.13 Research has also examined the role of informal group dynamics, trust and respect, and supportive organizational contexts.14 Indeed, incentives don’t necessarily need to be monetary or career focused; they can also be social and geared toward building positive relationships.15

We have found no study that investigates how the formal components of a project management system interact with mutual relationships and psychological safety in promoting project success. How, exactly, do the formal components of a project management system interact with psychological safety? What forms of incentives can lead to reasonable expectations of reciprocity? Which combinations of managerial actions are most likely to succeed at harnessing behavioral tendencies? Our study describes an actual system that works, displaying how psychological safety and mutual reciprocity can be incorporated into a fully implemented system. (See “About the Research.”)

New Product Development at Roto

Roto, which has two business divisions that employ about 3,800 and which generated 2013 revenue of about 658 million euros, illustrates how psychological safety and mutual reciprocity can be incorporated into a complex system. Roto’s roof and solar technology division, the focus of this article, produces roof windows with integrated solar systems. Its new product development (NPD) department was at the beginning of this study made up of 25 development engineers working on an average of 20 projects in parallel; four senior and two junior project managers; and four senior engineers who led small projects part-time. A portfolio manager supports the project managers and helps coordinate across projects.

A typical NPD project is a roof window platform that is composed of many elements, such as solar thermal applications, automatic closing mechanisms and ventilation devices. Roto’s window systems are designed for customized manufacturing and installation, which requires having a modular platform with many variants. Roto introduces its new products at annual trade fairs, and new models are critical for retaining market share. In addition, the company needs to comply with increasingly tight energy regulations, which shape the choices of customers seeking subsidies for energy conservation.

On average, Roto’s roof and solar technology division has 21 active projects and seven waiting to get started. The projects are discussed and prioritized monthly by the new product steering committee, which consists of the division CEO and the heads of development, purchasing, manufacturing and product management. Since 2005, Roto has used a standard stage-gate process for new product development. The process starts with a rigorous customer-needs document driven by product management, a business plan and a detailed specification document. For every project there are four more milestones, and for each major component there are five. Thus, a major project can easily have 100 to 150 milestones. A weekly schedule links the overall project plan to the individual activities, creating a weekly status report. Until late 2009, when visualization was decentralized to workers’ desks, this schedule was recorded on a large chart in a meeting room directly adjacent to the engineering open space, listing the tasks that were completed, pending or late.

Redesigning the Project Execution System

In 2009, Dirk Stempfhuber, Roto’s NPD manager, participated in a “visual management” workshop organized within the company’s manufacturing department to help make workflow metrics visible and controllable by local work teams.16 Stempfhuber was asked whether project management in his department at Roto was truly visual. His first reaction was: “Yes, of course.” But upon reflection, he realized that the big chart in the meeting room was not something the engineers actually used. Engineers did not assume responsibility for the chart’s accuracy on individual tasks, so it was often outdated. As a result, project managers often went directly to engineers to learn what was really going on, which further reduced the urgency to update the control chart. So even though there was a large chart, it was not aligned with the spirit of visual management.

Working with the portfolio manager and the project managers, Stempfhuber decided to relocate the control chart from the meeting room to each project desk, where the engineer’s critical tasks for every day of the week would be clearly written. Engineers were responsible for their own charts, which were supposed to reflect the current status. In addition, engineers were asked to put up a red flag — referred to as a “red card” and visible to anyone walking through the open space — whenever a critical task was becoming late enough to affect other tasks. A green card indicated that all tasks were on schedule.

However, the concept of the red card initially raised fears. The immediate flagging of a possible delay made the affected engineer feel vulnerable and exposed to criticism. Furthermore, in soccer, a red card signals a player’s banishment from the field — hardly a positive connotation for the engineers.

Management recognized that engineers needed to be reassured and that getting them to feel comfortable about using red cards might take a little time. Stempfhuber promised his staff that anyone who raised a red card: (1) would not be criticized, and (2) would receive help from either the portfolio manager, the project leader or Stempfhuber himself within 30 minutes. If a solution couldn’t be found immediately, management would create a task force (called a “red-card team”) to resolve the issue; the team (made up of selected people from all relevant technological and functional areas) would stay involved until the problem was resolved.

Although time would tell if this approach would be effective, the engineers had enough confidence in Stempfhuber to give the new system a try. The first red card for a project task was posted in December 2009, when a critical drawing for a window profile was delayed. Working alone, the project engineer had been unable to disentangle a design issue; however, the red-card team found a way to straighten out the problem and keep the project on schedule.

Within a short period of time, the red cards became accepted by Roto engineers as normal procedure. During the first 10 months, engineers used 30 red cards; the rate subsequently fell to about half that level. (See “The Frequency of Red-Card Postings.”) On the surface, adopting the change was relatively simple — it didn’t require new information or a new planning method. Yet the introduction of a help process was enough to affect performance.

The Impact on Performance

Roto’s red cards illustrate the impact of visual management. Moreover, in combination with the built-in help process, they have enabled the organization to react more rapidly to problems. In the past, it took longer to detect problems — often as long as a month, by which time some spiraled into larger issues. Now even the suspicion of a problem triggers an immediate red card. Project performance has improved significantly (with staffing and the quantity and quality of work in progress stable), as measured by decreases in late changes, the cost of late changes, the average number of delays per project, and the average processing time of red-card issues. (See “Improvements in Project Performance Indicators.”)

In the wake of the changes, planning for how long tasks will take has become more realistic. As one project engineer explained: “Previously, I had to deal with problems myself, so I had to give myself a buffer.” There is also evidence of systemwide efficiency gains. Because Roto uses lower-priority projects as “backup work” and as an implicit buffer, there was an expectation that some secondary projects would be delayed. However, such delays have not occurred; project engineers say they no longer spend time fretting about and trying to avoid problems but attack problems early, which makes solving them faster and cheaper.

Changing Attitudes and Behavior

The first step in our analysis was to define the stages in the evolution of Roto’s new project development process and to see how the use of the red cards changed over time. At the initial presentation, Stempfhuber made clear that the red cards were not tools for evaluating people but resources for characterizing the work. Over time, this view was internalized by the engineers, who came to see the cards not as a threat but rather as a source of help. As one mechanical part designer put it: “If I fall, I fall less hard because we work together and help one another.”

In the second part of our research, we analyzed the interview data to identify how the interviewees’ expressed attitudes affected their behavior in project work. We then compared attitudes over time in order to identify changes. The interviewees consistently reported two behavioral changes: (1) a decreased tendency to build individual time protection into project tasks, and (2) increased collaboration across tasks and projects.

We also interpreted the perceived attitudes and behavioral changes in light of behavioral operations management theory. Research on psychological safety has shown that employees may be willing to share their information (that is, give up their knowledge advantage in situations of information asymmetry) when they feel it is safe to take this interpersonal risk.17

The interview observations suggest that Roto’s help process promoted more proactive worker behavior toward disclosing problems; increased psychological safety ultimately led engineers to view the red cards as a standard support mechanism to be used without fear of punishment or reputational damage.

The active help seeking and help provision may explain the systemwide efficiency gains noted above. Without fears of being blamed, workers were more inclined to call for help rather than procrastinating or passing latent problems on to the next project worker. The red-card process fosters cross-functional problem solving in teams, which can reduce engineering project costs, shorten schedules and, over time, decrease the amount of time needed to resolve a red-card issue. However, collaborative problem solving does not imply that problems can be solved in a predictable way — only that solutions can be found more effectively. (See “Resolving Red Card Problems at Roto.”)

The Behavioral Dynamics of Mutual Help

In order for workers to cooperate in disclosing problems early, they needed to have confidence that they would receive assistance and wouldn’t be blamed. But it was also important to explain the benefits of the help process for the help seeker and to quickly create a positive experience. Psychological safety was reinforced by the workers’ experience that help was indeed forthcoming and that they would no longer be left alone with problems. A positive feedback cycle arose, initially created through implementation of the help process and the promise of no punishment.18 (See “A Positive Reinforcing Loop.”)

It’s interesting to examine why the use of the red cards declined and then leveled off after the initial activity, and also how the red cards were connected to the improved project performance characteristics of Roto’s NPD over time. First, capacity for helping others is limited — all employees are responsible for completing their own primary assigned project tasks. If workers have to spend too much time on helping others, the progress of their own tasks will suffer. So, to avoid delays on their own tasks, they will have to help others less. Thus, on an aggregate level, there is a natural limit to how many cards can be processed. But how do individual workers take this into account? Based on employee comments, we found that intensified cross-task and cross-project collaboration in the red-card teams made interdependencies explicit and fostered positive relationships across project workers. As a result, project workers self-regulate their use of red cards.

Although reciprocity encourages workers to help others, it limits using red cards to situations in which they are deemed essential. Workers don’t want to burden their peers with unnecessary calls for help because sooner or later they really may need support from others. And since the red-card process is a “give-and-take” process, workers view any substantial imbalance as undesirable. This equilibrium between seeking and providing help explains why the use of red cards leveled off. In the language of system dynamics, the coexisting positive and negative loops lead to an equilibrium of behavior in which the balance between seeking help and not overburdening colleagues settles at about 1.5 red cards per month.

A second factor has to do with the genuine productivity improvements of the product development department enabled by the red-card process. Based on their feelings of psychological safety, workers are willing to plan more tightly and reduce their private time buffers. Moreover, the collaborative problem solving resulting from the red-card process serves to identify project problems earlier, and problems that are uncovered earlier typically take less time and effort to resolve. The red cards thus helped to reap the efficiencies of front-loaded problem solving.19 Both effects reduce total project task times (including rework), thus reducing project duration and increasing the effectively available capacity.

Thus, the formal help process resulting from the red cards and the direct demands on project workers’ capacity interact with the productivity improvement effects (through shorter project cycles): Capacity is limited, but the limit is to some extent relaxed by the productivity improvements. In the language of system dynamics, the equilibrium between helping and working is lifted up, allowing for a higher level of helping than would be possible if productivity improvements were not achieved. (See “Red-Card Usage, Team Relationships and Capacity.”)

To be sure, other theories could explain reduced task times in projects at Roto. For example, some might wonder if the change of behavior is caused by the mere fact of management attention rather than by any particular feature of the new process itself, a phenomenon known as the Hawthorne effect.20 However, based on data we collected about the help process over a period of three years, we have excluded that possibility. During that period, the help process entered a normal mode of self-regulated operation by the employees without any special top management attention other than the regular monitoring of red cards.

In addition, we can rule out that other factors were driving the performance changes. In particular, we don’t believe that Roto has benefited solely from the cognitive benefits of visualization (as implemented via the red cards); the reduced planning fallacy from unpacking tasks (implemented via fine-grained weekly planning by every project worker); and the operational benefits from pooling task uncertainties. We also show that the help process described in this case study is not merely a variant of lean manufacturing methods.

Cognitive Benefits of Visualization

By compressing information, visual representations can aid in solving complex problems.21 Research shows that human input channel capacity is greater when visual abilities are addressed and used.22 Clearly, the red cards have improved visibility at the level of the NPD department versus having a central project control chart in a separate room. However, our interviews indicate that individual workers had previously been reluctant to share their problems (and instead tried to fix them alone) was not because of insufficient visualization but because they were afraid of being blamed or looking incompetent. As one project engineer noted, visualization alone (for example, a red card without the guarantee of help) would not yield the proactive behavior because “we [the project engineers] still try to weigh the benefits of help against all the stress when raising the card.” Thus, while visualization was helpful, it does not explain the changed problem-solving approach.

Reduced Planning Fallacy From Unpacking Tasks

Decomposing problems into manageable bites can mitigate the tendency to produce overly optimistic task-time estimates.23 However, two observations argue against this being influential at Roto. First, the planning fallacy can lead to excessive optimism, and unpacking tasks should encourage more conservative (longer) task-time estimates. But we observed the opposite: The estimates actually became shorter, suggesting that “unpacking” was not an issue. Second, when we asked interviewees to describe changed behavior and its possible causes, project engineers noted the importance of the availability of help.

Operational Benefits From Pooling Task Uncertainties

The red cards facilitate pooling, which allows for more efficient use of capacity by reducing the possibility of one resource sitting idle while another faces a work backlog. Once a project worker faces a problem that threatens on-time completion of a task and thus increases actual workload, additional capacity can be shifted to the troubled task from less urgent projects. The benefits of pooling could, in principle, lead to both lower task times and efficiency gains. However, at Roto, the total shift of capacity between top-priority projects amounted to only 5% of total capacity; moreover, the impact on less urgent projects was quite minimal. Any small changes in pooling that might have escaped management attention (for example, because engineering time was not faithfully recorded) would be too small to entirely explain the front-loading and efficiency gains that were observed.

Comparisons With Lean Manufacturing: Red Cards and Yellow Cards

A final possible explanation for the improvements is lean management and its visual control to correct deviations. (One example is the well-known Andon system, which authorizes workers to stop the production line when they detect a deviation from the standard.) We have already mentioned that lean methods correct deviations from a predefined standard, while the red-card system deals with task problems where the outcomes have yet to be determined, and where more complex problems involve partially emergent interdependencies among multiple components and tasks.

To understand the difference between the red-card process and lean management, it is instructive to consider a “hybrid” system that Roto developed in 2012 involving “yellow cards.” Yellow cards were introduced to address a simpler and more structured problem than new product development: namely, customer complaints about existing products and small product modifications that typically require a change in a manufacturing tool. The problems that yellow cards address are therefore conceptually closer to lean manufacturing than team support; these problems deal with variations from an existing product specification standard. The yellow-card system is highly organized and built on hierarchical responsibility (like the Andon system of lean manufacturing). In contrast, the red-card process relies on flexible teamwork, reflecting more fundamental problem solving.

Psychological safety was reinforced by the workers’ experience that help was indeed forthcoming and that they would no longer be left alone with problems.

This article is based on a longitudinal single-case study that documents a project management method innovation — how the implementation of a help process improves project performance. We identified two key factors that drove these changes. First, management created a formal process that led to the offering of help. The process was accompanied by managers’ assurance that they would not blame or pressure help seekers. What’s more, management led by example in calling for help themselves. It is important to note that the promise was based on the trust and improvement-oriented culture already present in the organization, which was necessary to get the help process started in the first place. The promises and their subsequent fulfillment had the effect of increasing the level of psychological safety, which made project engineers more comfortable about sharing information about problems or improvement opportunities on a timely basis. The availability and effectiveness of help guaranteed by the help process reinforced that psychological safety. Second, the identified problems were tackled collaboratively by teams that cut across project lines. This dynamic made the interdependencies explicit and encouraged the development of reciprocal relationships throughout the engineering department. Such institutionalized relationships motivated project engineers to adopt a “mutual help” orientation rather than focusing solely on their own respective domains of responsibility.

Although our study documents the innovation, it does not prove applicability in other project environments. However, the help process has been implemented (with appropriate adjustments) at other sites,24 which suggests that formal help systems can be used to improve project performance.