Project Management Institute

Strategies for balancing the high-wire dynamics of product innovation

Gregory D. Githens, PMP, NPDP, Catalyst Management Consulting

Product development organizations are on a high wire, striving to maintain balance, move forward, and occasionally perform amazing stunts.

The most important element of success (or avoiding a plunge) in circus high-wire walking is keeping the center of mass balanced over the wire. Both the circus performer and the wire are in motion so the center of mass is always changing relative to the wire. Thus, the circus performer wobbles in a dynamic system that includes wire tension, the skill of performer, the physical/mental health of the performer, noise, and wind speed. Maintaining balance in this dynamic system is essential. The performer will fall if there are not quick adjustments.

While high-wire walking is physically complex and the dangers are salient, new product development (NPD) project management (PM) is mentally and socially complex and with subtler consequences. The NPD high wire is cut, jiggled, stretched, and reengineered while the performer is on it. The purpose of this paper is to show you techniques that can help you maintain or regain balance in the NPD PM environment.

The definition of “dynamic” that is appropriate for this paper is the forces of a sociotechnical system and their interplay, rather than the linear sense of the word as forceful or powerful. While there are many dynamics, I am limiting discussion to three that are very important for understanding and improving NPD PM performance: flexibility-control; improvement-throughput; and frontend-backend. The flexibility-control dynamic involves actors who desire control, other actors who react against control, and everyone's desire for creativity. People who are responsible for results want control, but those who are not the controllers resist control. The throughput-improvement dynamic comprises the essential nature of strategic management of organizations and projects: if organizations do not improve they stagnate and become irrelevant. The frontend-backend dynamic provides a perspective for improving product development process and strategy. Exhibit 1 provides a summary of the three dynamics discussed in this paper.

Two Balancing Strategies: Polarities and Systems Dynamics

Polarity management is a method for surfacing mental models that lead to conflict. I have previously described polarity management in the PMI 1998 paper on Rolling Wave project planning (Githens, 1998), which mapped the “Focus on Ends and Focus on Means” polarity and 1999 PM Network article on Paradox and the Effective Project Management Culture (Githens, 1999a), which mapped and explored the polarity of “Functional Centric and Project Centric.” Polarity Management is a very insightful tool, and I have mapped over 15 polarities affecting NPD performance and organizational change. There are few problems to solve, and many situations to manage!

System dynamics is essentially identical to the “systems thinking” methods described and popularized by Peter Senge (1990). The primary difference is the systems dynamics approach builds a formal model and tests the formal hypotheses with real data. The points raised in this paper originate from my own experience as well as research performed by the Systems Dynamics Group at the Massachusetts Institute of Technology on product development improvement efforts at Harley-Davidson, Lucent Technologies Inc., Analog Devices, Ford Motor Company, AT&T, and National Semiconductor Corporation.

Dynamic #1: Balancing Flexibility and Control

Culture is defined as shared learning of a social organization. The reasons for resistance of the process of project management lie in understanding polarization. As I wrote in PM Network July 1999, “cultural rigidity is learned behaviors that result in blind dogma, extreme command-and-control regulation, group think, measuring unimportant things in great detail, and conflict avoidance. Rigidity stems from normally valid and productive behavior.” For example, control is a necessary management function for managing uncertainty and threats. When organizations reward for control, organizations get more control. However, when taken to extremes, it produces unwanted side effects.

Exhibit 1. Summary of Three Dynamics Discussed in This Paper

Summary of Three Dynamics Discussed in This Paper

Exhibit 2. Polarity Map for Flexibility-Control

Polarity Map for Flexibility-Control

Many managers define project management as a control tool. When time is the only metric, people oversimplify and see project management as mechanically scheduling tasks and coordinating. Examples of the paradigm of PM as a control tool include project office, software, and scheduling techniques.

On the other hand, there are many in NPD organizations that fear rigid bureaucracy and suspect that project management is only a control technique. The cultural worlds of R&D and marketing participants in the NPD process are different (Griffin & Hauser, 1996), as people in early stages of product concept development tend to be more vague and ambiguous in setting requirements. Rules reduce the degrees of freedom of choice, thus, constraining creativity and limiting future options. The reason for a creative outlook is, of course, that personal and organizational growth stems from creativity.

Balancing flexibility and control is essential for understanding and creating effective project management culture. Polarity management explains well what happens when a control paradigm confronts a creativity paradigm. Exhibit 2 illustrates the flexibility and control polarity developed by a firm that had functionally siloed creative design people and detailed mechanical engineers. This flexibility-control polarity explains much of the conflict between marketing and engineering in NPD environments. (Readers should consider the polarity maps as an artifact and recognize that the value for organizations is in the process of developing the polarity map.)

It is important to ask each person to contribute the upside in their own language, and not attribute beliefs to others. Given there is often a dominant subculture oriented toward either control/fixing or flexibility/creating we find that people often crusade to change the other pole's point of view, as I described in my 1999 article. As I wrote (Githens, 1999b), “the emergence of a project management culture derives from a holistic understanding of the purposes, traditions, and value creation abilities of project management and functional management.” Polarity mapping cause people to look deeper into their values and belief. A well-managed polarity focuses time on the upper half of the map.

Is Project Management Strategic or Operational?

By exploring the flexibility-control polarity, project managers can gain insight to the cultural barriers and the question of the value of project management to the enterprise. For those with a tools paradigm, PM is just a control/compliance mechanism. Control enhances psychological comfort. A strategic perspective is to regard project management as a capability or enabler of outcomes. In my opinion, project management should have a much bigger role to play in creating opportunity for the organization, but people need to regard it as an enabler and not label it as a tool.

Fundamentally, organizations have to ask and answer several profound questions: (1) What kind of NPD results do we want? (2) What are the cultural enablers and barriers? (3) Are we willing to invest time? The organization needs to determine appropriate balancing strategies and consider programs to improve capabilities, as discussed in the next section.

Dynamic #2: Allocating Effort to Throughput or Improvement

In this dynamic, organizations must understand the balance between throughput and improvement, and allocate resources strategically. NPD throughput sustains utilization of assets and provides for business growth.

Given a keen need to improve NPD throughput performance, firms invest in improvement programs to “work smarter.” These programs frequently consist of training, software tools, and data repositories. However, management pressures the development organization to fill the development pipeline and move products through it. The pressure thwarts the amount of time spent on improvement.

Let's consider the experience of an unsuccessful NPD improvement effort that did not manage the throughput-improvement balance well (Repenning & Sterman, 1997). Following a successful manufacturing improvement effort, the organization expanded it to the NPD process with the target of 50% improvement in performance. They report that the NPD improvement effort was consistent with much of the current thinking on organizational change and process improvement. The firm hired an outside consultant to provide a process framework and documented process with many detailed steps. They benchmarked other companies. They involved many people in the process. They added software tools and advanced design techniques such as CAD/CAM systems and FMEA. In the end, “Among the engineers interviewed, not one believed that the initiative had materially influenced his or her job.” The General Manager thought it was only a 50% success. The executive in charge felt they had only met 20% of objectives for using project management. Repenning and Sterman's paper provides a detailed treatment of the failure to manage the NPD improvement as a dynamic process.

A simple systems dynamics model explains what the organization hoped to achieve (as a baseline to describe how they fell short). The firm intended to create a “Productivity Chain” as illustrated in Exhibit 3. The starting point is the increase in commitment to an improvement program, which would lead to an increase in effort in the improvement program. Ideally, effort allocated to improvement boosts NPD productivity, which boosts NPD process throughput (Loop R1). The improved throughput would reduce pressure on managers and workers, and create slack that could be reinvested in other improvements or treated as a cost saving.

Naturally, the effort associated with improvement is effort that the organization cannot allocate to throughput. As effort to the improvement program increases, the effort to throughput decreases. Because of the reduced effort, throughput goes down and managers sense a gap between their desired throughput and actual performance, so they react and increase throughput pressure. To sustain a program, managers must support the reinforcing nature of improvement by limiting the effect of throughput pressure on effort allocation. Nevertheless, the reality is that managers continue to exert pressure on the NPD organization—improvement most always is deemphasized. This is illustrated by Loop B1, “The Effort Squeeze,” as illustrated in Loop B1 of Exhibit 3. A balancing loop is negative feedback to a reinforcing loop—it stops the reinforcement. (Do not confuse the high-wire balancing metaphor with the counteracting of a system feedback loop.)

One factor that undermines improvement is the pressure to fix problems and/or meet new goals. The study reported, “People had to do their normal work as well as keep track of the work plan. There just were not enough hours in the day. How do we catch up? We stay late. Most of the team was working from 7 a.m. to 8 p.m. and right through vacations.” Engineers report that project management failed due to lack of time and intense work pressure. The managers of the engineers attributed the program's failure to “undisciplined engineers.”

Exhibit 3. Hoped-for Improvements Leading to Throughput, and Effort Squeeze that Limits Improvement

Hoped-for Improvements Leading to Throughput, and Effort Squeeze that Limits Improvement

Many managers increase the pressure for production and control when the first tools do not work. The reasoning is that if the minimal control does not work, managers need to exert more control. The manager's belief of low individual capability (e.g., undisciplined engineers) was not discussed during the process, and the antagonistic relationship between managers and process participants was not resolved. The failure of the program further widened the gulf between the mental models of the managers and engineers. One engineer reported, “I believe this is a good process. Someday I'd really like to work on a project that actually follows it.”

When Best Practices Do Not Work

The NPD improvement program studied by Repenning and Sterman (Repenning & Sterman, 1997) used most of the techniques touted as “best practices.” They contrast the success of a change effort in the manufacturing area with the change effort in the NPD process. “First, while the product development process initiative focused on laying out a specific process and creating structures to make participants adhere to that process, the manufacturing process focused on improving managers' and operators understanding of dynamics. The product development process initiative drew on many of the currently popular change strategies, but none of these were sufficient to overcome managers' flawed understanding of the dynamics of the product development organization.”

Exhibit 4. Polarity Map for Throughput and Improvement

Polarity Map for Throughput and Improvement

Are More and Better Tools the Answer?

While there is considerable anecdotal evidence emphasizing the need for better tools planning and executing projects, consider that the naive introduction of tools could cause a permanent degradation of quality for the following reasons. First, it requires time to learn. Second, learning reduces the amount of effort in throughput: effort applied to learning is effort that can't be applied to throughput. Third, the change is often symptomatic (“we are missing dates—we need to schedule better”) rather than the root cause (the organization has too projects, not enough resources, and no strategy). Improperly introducing tools can cause a reduced capability.

Estimating Delay Between Improvement Effort and Benefits

The increased effort for improvement leads to increased productivity, after a delay. If change agents would learn to estimate better, the delay time between the application of effort and outcomes, they would do a better job of setting realistic expectations. It has been my experience that most improvement targets are feasible, but the time frame is not. When technical people are faced with objectives that they perceive as illogical or impossible, they find reasons to withdraw their energy (“We've got too much throughput to do”).

Allocating Resources to Improvement

An improvement program is more likely to succeed if managers facilitate a shift of workers time from throughput to improvement and limit opportunities for workers to shift effort back toward throughput. After all, workers will typically get in trouble for not meeting throughput goals, and can explain away the improvement effort, as “I didn't have enough time.” To simultaneously get the job done and undergo improvement, NPD project managers must heroically work extremely long hours to achieve targets.

The Improvement and Throughput Polarity

Organizations need to address both the future and the current, pressing issues of operations. This is a balancing act, and polarity management techniques can help. Exhibit 4 provides a polarity map for the improvement-throughput polarity. Remembering that there are situations-to-manage, the goal is to stay in the top half of the map by developing an understanding of balance. It is possible to both create improvement and to solve urgent and immediate needs associated with throughput.

To manage strategically is to balance maintaining a systematic product development capability with investing to improve productivity. Too often, a firefighting and crisis management culture arises and people become cynical. In the next section, I will describe the dynamic of anticipating defects and choosing whether to address them early or late.

Dynamic #3: Balancing the Allocation Effort to Project Front-End Work (Concept) versus Back-End Work (Development)

Many people, including me (Githens, 2000a), have declared that work in the front-end of the project is an investment in good performance. Project rework is substantial, and much of the rework is avoidable. In retrospect, people state they could have benefited by more project planning. Most project managers have heard the chestnut, “failing to plan is planning to fail.” Despite this, projects keep making the same mistakes. By recognizing the presence of the front-end and back-end dynamics, I hope to show you the pathway to effective management of product development.

In fact, many if not most organizations are caught in a trap of firefighting and crisis management. A firefighting mode is common (Githens, 2000b) and is a high-wire dynamic. They spend more time catching up to the problems than they do in preventing them.

Defect Prevention or Defect Fixing

Repenning developed an interesting analysis using data from Harley Davidson (Repenning, 1999). He studied the processes that drive multiproject organizations to allocate an increasing fraction of scare resources away from preventing problems and towards fixing problems in existing projects.

The concept development phase, focuses efforts that make the design work more productive. Many people call this first phase the fuzzy front end (FFE). Projects often skip or perform these actions poorly. The second phase is product design and testing: the typical product development work that leads to launch. Engineers must handle defects in this phase. The poor quality of execution of upstream tasks (Concept Phase) is typically only noticed in downstream activities when symptoms appear, e.g., rework, project cancellation, or poor launch. Projects will only perform well on FFE execution activities to the extent that slack resources are available and the project team perceives the benefit of FFE work. There is a strategic balance of attention in front-end and back-end of the development project.

Starving Projects to Death

Resource allocation decisions are the key to the shift from upstream to downstream. Repenning declared, “If resources are sufficiently scarce, then the low state of firefighting will occur.” The analysis suggests that a good-performing firm could absorb a 20% increase in the upfront workload (a shock to the system), but a 25% increase in workload could tip the organization to a permanent decline in performance.

This downward spiral drives an organization to allocate an increasing portion of its scarce resources toward fixing problems in existing projects and away from preventing future problems. Repenning concluded, “Managers must pay close attention to increases in project resource requirements, and if resource plans are not rapidly updated to account for them, they may be sufficient to create the downward spiral.”

Delays Between Action and Results

Organizations skip over the front-end activities for many of the same reasons that they reduce allocation of effort to improvement. First, while people acknowledge the benefits of front-end activities, they are largely intangible and intellectual. The front-end requires thoughtfulness, but anti-intellectualism is prevalent in many organizations. Second, firms effectively work around problems, perpetuating a short-term problem-solving competency that discounts long-term consequences. Third, there is preference for action: “ready-fire-aim.” Fourth, front-end work tends to surface disagreements that cause discomfort. In different analysis, “upstream” members (i.e., marketing) believe that the work is ready, while the “downstream” members declare the work is not ready for development (Ford & Sterman, 1997).

Purposes of NPD Processes Are Not Understood

One reason is that NPD people are not aware of standard concepts (Githens, 1999b). For example, stages and gates foster synchronization, but they may not lead to development speed. One resulting symptom is that people “salute” process and then “end run” it in the name of results. The stage gate approach is ill fitted to many firms' strategies and competitive dynamics (e.g., highly turbulent, internet businesses). Perhaps the process is only followed about 50% of the time. Recognizing these violations, NPD process owners end up being “rule enforcers”—or look the other way. Regardless, the mismatch of NPD and process becomes an internal joke.

To bring improvement to NPD process requires that firms recognize several factors. First, products have different business purposes. Derivative products need much less upfront effort than radical projects. Second, current metrics tend to focus on wrong things (usually the most easily measurable) that leads to dysfunction. Third, firms do not fully appreciate or have adequate tools for understanding, evaluating, and reducing risk. The fourth reason is the previously described issues with intangibles. Finally, because of the proceeding there is not one best way to manage a project, yet firms persist in trying to install standardized “methodologies.” For simple projects there is familiarity and hence an ability to quickly respond with workarounds. Innovations that are more radical need different approaches (Kessler & Chakabarti, 1999), but people tend to stay with tools they already know.

The Front-End and Back-End Polarity

Like most complex organization phenomena, balancing the front-end and back-end is a situation to manage, not a problem to solve. The upside of front-end perspective emphasizes anticipating problems/opportunities and reducing risk, whereas the back-end perspective emphasizes fixing problems and making commitments.

Some people pride themselves on their ability to react. For example, a manufacturing engineer recently told me, “We can build anything that our product engineers design. We may not be the low cost producer, but we are very familiar with the product technology and can quickly adapt.” (He felt there was little reason to involve manufacturing in NPD improvement.) At this same firm, it was a source of pride for the sales, marketing, and product engineering to be able to meet unique and peculiar customer needs.

The dynamics pointed out in this paper suggest a pernicious problem. Organizations are attempting to overcome complexity with standardization. The very nature of NPD suggests that organizations need dynamic flexibility: projects are not the same and portfolios differ; thus, they need a tailored development process.

Roberto Verganti (1999) describes improved state of NPD process capability as “planned flexibility.” The front-end assumptions are typically problem anticipatory whereas the backend assumptions react to identified problems with problem solving. He declared the importance of the capability to use either or both of problem anticipation and problem solving as planned flexibility. Exhibit 5 is a polarity map of the balancing emphasis on the front-end and back-end. A well-managed polarity is found in the upper half of the map.

Exhibit 5. Polarity Map of Front-End and Back-End

Polarity Map of Front-End and Back-End

The Future of Project Management

To consider project management strategic, organizations need to determine if they regard project management as a tools paradigm or a capabilities paradigm. The tools perspective/paradigm is a basic, practical approach that sees project management as a means to an end. Many organizations are in this paradigm and are comfortable with it. However, for leading-edge firms, project management is an organization capability for increasing performance, not just a control tool. Tools are optional, whereas capabilities are not optional.

Building Individual and Team Capabilities

Individuals are the basis of the learning organization. Cognitive skills have never been more important than they are now. We need to become systems thinkers to make effective decisions in a world of growing dynamic complexity. People have to learn to manage situations that are complex, abstract, ambiguous, and with a delay between event and outcome. They need to recognize that heuristics (rules of thumb) have limitations. Finally, they need to learn to avoid “fixing” others, and instead search for common values.

Building Organizational Capabilities

There are several actions needed for project management to realize its potential as a core organizational capability. First, organizations need to clearly link project strategy and product strategy to the underlying business model. They need to determine whether fast product development really means more numbers of product launches, or more agility, or first to market. Second, in the face of the uncertainty, organizations need to find and apply forecasting techniques for launches, resources, and portfolio management. All organizations are resource constrained, so they need to focus on the priorities and search for leverage. Third, organizations need to consider the cultural factors (as described in the next section) more carefully and become informed buyers of “tools” programs. They need to understand better the dynamics of improvement.

Overcoming the Inertia of Cynicism and Control

Anybody who has been around organizations knows well the meaning of the term “flavor of the month change program” and this has certainly been true of project management improvement efforts in NPD organizations.

Companies should ask themselves the question, “Why is cynicism increasing?” This paper touches upon a number of reasons: a control mindset, emphasis on throughput, and reactionary fixes in the back-end of the NPD process. Cynicism keeps organizational improvement efforts off balance, making high-wire management impossible. Cynical cultures tip energy toward throughput and away from improvement. Cynicism reinforces itself with low performance and passionless compliance with improvement efforts.

Perhaps the supreme high wire for NPD organizations is that of shaping culture. I firmly believe that the three dynamics I have described in this paper are profoundly important: flexibility and control, improvement and throughput, and front-end and backend. I urge you to think about whether your performance is balanced, wobbling wildly, or already in a death spiral.

At times, the task of fundamentally individual and organizational capabilities seems daunting, but I am optimistic. Polarity management is easy to learn and apply. Systems dynamics models are a little more difficult to construct and operate, but I foresee company-tailored NPD “Flight Simulators” to allow project managers to do trial runs of their projects and learn the points of leverage. People need to understand that the tools reveal structure and facilitate communications that are the basis of organizational culture. The high wire is dynamic and there are no simple solutions.


Ford, David, & Sterman, John. (1997). Dynamic modeling of product development processes. Unpublished paper

Githens, Gregory. (1998). Rolling wave project planning. Proceedings of the 29th Seminars & Symposium.

Githens, Gregory. (1999a, July). Paradox and Project Management Culture. PM Network, 13, 51–58.

Githens, Gregory. (1999b, July). Are project phases the same as stages? The case for different definitions. Project Management Innovations (NPD SIG Newsletter), 4, 8.

Githens, Gregory. (2000a, February). Capturing project requirements and knowledge. PM Network 14,49–59.

Githens, Gregory. (2000b). Fire fighting and crisis management: Causes and relief. Unpublished white paper-

Griffin, Abbie, & Hauser, John. (1996, May). Integrating R&D and marketing: A review and analysis of the literature. Journal of Product Innovation Management, 13,191–215.

Kessler, Eric, & Chakrabarti, Alok. (1999, May). Speeding up the pace of new product development. Journal of Product Innovation Management, 16,231–247.

Repenning, Nelson. (1999). Why good processes sometimes produce bad results: A formal model of self-reinforcing dynamics in product development,

Repenning, Nelson, & Sterman, John. (1997). Getting quality the old-fashioned way: Self-confirming attributions in the dynamics of process improvement.

Senge, Peter. (1990). The fifth discipline: The art and practice of the learning organization. Currency Doubleday.

Verganti, Roberto. (1999, July). Planned flexibility: Linking and anticipation reaction in product development projects. Journal of Product Innovation Management, 16, 363–376.

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI or any listed author.

Proceedings of the Project Management Institute Annual Seminars & Symposium
September 7–16, 2000 • Houston, Texas, USA



Related Content