Program managers in new product development (NPD) and other technical environments face a number of challenges: information overload, numerous decisions, complexity, shifting strategies, unreliable suppliers, low participant commitment, management expectations for detailed control, futility of scheduling inventions, speed and urgency, high uncertainty, finite market windows, and customer desires for flexibility. Some organizations approach these challenges by defining program management as “rules and tools” and end up rigid, bureaucratic, and ineffective at innovating. (I use the term “program” to include projects as well.) Other organizations become overwhelmed by the challenges, give up on process, and rely on smart people to put forth their best efforts. The minimalist approach leads to inconsistency: often the program achieves spectacular success, but just as often the program spirals into an abyss. The best program managers find the middle ground. They balance flexibility with control and find that the rolling wave technique is one of the best techniques in their product innovation toolbox.
Rolling wave is a program management approach that applies an iterative style of planning and execution in defined time periods. Initially, the program establishes a top-down structure and then fills out the work bottom-up within each defined phase. The work proceeds iteratively.
Rolling wave, if done well, gives the program team a framework for creating a balanced program approach for control and flexibility. Through rolling wave, the team creates a process for aligning work with product development strategies. Kurian Jacob, a rolling-wave practitioner at Motorola, states: “We develop advanced technology capabilities that have never been done before. Rolling wave helps to meet the challenge of keeping energy focused on short-term work with the eye on long term.” Rolling wave resolves uncertainty through a phased, iterative approach, often summarized as “plan a little, do a little.” Because there are planned points of relearning, rolling wave can achieve faster results and outcomes that are more creative.
Don't misapply rolling wave! Rolling wave is a program management technique better suited for development than for deployment. Development programs experience and must cope with a high degree of uncertainty; for example, new requirements, customer demand, and technology. Also, they are “inventive” in nature, and the design process is inherently iterative. Thus, development is a process of removing major blocks of uncertainty, hence the value of the “plan-do-plan-do” approach of rolling wave.
Deployment projects, by contrast, involve little design work; thus, the program effort centers on deploying the design into the operations environment. Deployment is linear. The sidebar, “Some Differences Between Development and Deployment Projects,” provides additional discussion of the distinction.
Process of Rolling Wave
Rolling wave program management works exceedingly well because it encourages a strategic perspective while executing the day-to-day work. Exhibit 1 illustrates the six steps of the rolling wave approach to balancing top-down and bottom-up planning.
Step 1: Applying an Integration Strategy. The program manager must take the lead in establishing the theme of uncertainty recognition and reduction. All development programs are fraught with unknowns and require dialogue among different people with different expertise. Here are three activities for readying the team for rolling wave:
■ First, evaluate the quality of the product vision and requirements. The product vision needs to be only a few sentences describing the expected customer benefits, form, and technology. If the team determines it has weak requirements, then an initial phase of the program would be requirements capture.
■ Second, evaluate and delineate the initial product architecture. Recalling that development projects are iterative and design-oriented, the program should consider the design constraints and technical philosophies of the delivering organization. For example, many e-businesses use modular design principles as a basis for their core technical architecture. Thus, you need to determine which requirements are met and when.
■ Third, align the program architecture with product architecture. I use the phrase “program architecture” to describe program planning strategy: team composition, levels of authority, review and approval cycles, roles and responsibilities, risk and issues analysis approach, escalation strategy, and so on. Most importantly, the program manager must guide the selection of the appropriate project lifecycle strategy.
In deployment projects, it is common for people to work on their individual contributions, and then the program manager pulls it together. This assembly-process approach does not work well for development programs.
Step 2: Perform Top-Down Planning, Starting with Level 1 of the Work Breakdown Structure. In rolling wave, the program team performs the first cut at planning with a top-down perspective. Develop initial estimating approximations for time durations, resources, and expenses, starting by estimating the sizing of the time buckets. Start top-down: examine, validate, and document system-level assumptions, then subsystem-level assumptions, and then component-level assumptions. As Ken Delcol of MDS Sciex warns, “Don't go planning crazy.”
Program management tools for describing the high-level perspective are familiar: organizational breakdown structure (OBS), work breakdown structure (WBS), product breakdown structure (PBS), and cost breakdown structure (CBS). The WBS is the most important structuring device for program management, and it is essential to construct the WBS for managing the evolving change. Keep the focus high level and broad; a rule of thumb is to avoid decomposing to lower than Level 2 of the WBS.
Develop criteria for planning horizons (or “time buckets”) to include total number of horizons and duration for each horizon. As an analogy, imagine navigating a boat across a treacherous and unknown sea. Say, the horizon is 5 miles off, and you think the crossing is 25 to 30 miles long. You should stop the boat, peer off to the horizon, and rechart your course at least 5 times. This is the assumed total distance of the crossing divided by the distance to the horizon, plus a safety factor. Here's an example: An 18-month program with 3-month planning horizons and a 20 percent safety factor would have 7 time horizons at Level 1 of the WBS.
Step 3: Perform the First Planning Iteration, Starting Bottom-Up. In this step, the team details out individual work packages for the first horizon, “bottom up.” (This includes estimating task durations, resources, and cost.) Then, analyze the work with a network logic chart and publish it as a Gantt chart. Other important points include:
■ Keep visible the theme of uncertainty reduction. Key in on knowledge capture and use. Ask these questions: Are our current assumptions still valid? What new information do we need? What are the warning signals of potential program problems, and are they present?
Exhibit 2. In development projects, it is not always possible for the program to initially identify all work. What is first defined as black box “A” decomposes into more finite units, each of which appears on the WBS as the program team progressively elaborates the WBS.
■ Identify any work that might occur in the later horizons using top-down methods. Include any identifiable work in the later time buckets, using what I call a “black box” placeholder to indicate that you expect to define certain work later. Exhibit 2 provides an example of a black box and its placement on a WBS.
■ Define and validate the project's processes of contract closeout (verifying the design and deployment meets customer requirements) and administrative closure (for the delivering organization). There is a saying, “Never start a project that you don't know how to finish!” You do not want to fall into the trap of having the program team retain responsibility for the product after the project closes. Do not conclude this first pass at planning without discussing the launch and transition plan!
■ Establish a work package and fixed date for replanning for the next time horizon. The deliverable of the replanning work package is an updated rolling wave plan. (Phase transition techniques are discussed later in this article.)
Step 4: Baseline. At this point, the program has identified two kinds of work: the work contained in not totally defined “black boxes” and the detailed work of the first time bucket. If you have not yet done so, perform a risk analysis and establish management reserves before setting the time, cost, and scope baselines. You should also revisit your change management strategy and determine how you will use the WBS to track the new work packages that will emerge from the black boxes. You now have an integrated program plan ready for baselining by securing the appropriate approvals from executives, sponsors, users, program manager, and participants. There are no hard-and-fast rules for when to baseline: it's judgment based on analysis, experience, and intuition.
Step 5: Execute the Planned Work in the First Time Bucket. Inside the time buckets, work is straightforward: plan your work, and work your plan. For rolling wave it is particularly important to have a learning orientation. Capture learning for feed-forwarding to anticipate and avoid future problems, or to quickly react to the risks that the team decides to accept. Continue to emphasize the theme of uncertainty reduction. Ken Delcol offers some practical advice: “Make things certain or make them go away.”
Step 6: Iterate Through the Planning Horizons and Close the Project. This last step involves the continuing iteration of the “plan a little, do a little” approach, ending with the closing of the program. The important elements include:
■ Assess the team's learning, the needed work, and replan the next horizon of the program (go back to Step 3).
Some Differences Between Development Projects and Deployment Projects
I have found it useful to segregate projects into two types: deployment and development projects. Deploy means to scatter, commonly meaning to spread out a military unit in battle formation. In commercial settings, deployment typically means a detailed, logistical approach to installing or inserting the system into the environment. Design is inherently creative and iterative. Most good designers focus on removing major blocks of uncertainty; hence, designers like the plan-do-plan-do approach of rolling wave.
Uncertainty implies a lack of predictability of structure and of information. The very nature of product innovation is uncertainty and rolling wave's focus is on uncertainty reduction.
Decision framing is the part of the decision-making process that helps the decision-maker determine the crux of the situation. The best managers of development programs actively address and manage uncertainty. They keep the focus on “known” and “unknown” by asking questions: What do we know? How good is what we know? What don't we know? How much have we progressed in evaluating what we don't know?
Research by Gina Colarelli O'Connor and Mark Rice of Rensselaer Polytechnic Institute's Radical Innovation Program reveals four types of uncertainty in product development projects: organizational uncertainty, resource uncertainty, technical uncertainty, and market uncertainty. Radical innovations are particularly noteworthy for the indeterminate nature of the uncertainty. I believe that the greater each of these types of product development uncertainty, the more the program needs to use techniques that foster agility, such as rolling wave.
Many program managers have been trained in deployment methods, but do not recognize the unique challenges of product development environments. Rolling wave is better for development projects than for deployment projects, and rolling wave may backfire on deployment projects by making them more inefficient and slower. It is essential for program managers to understand the differences.
Development projects are different due to their innovative and uncertain nature! What may work for a deployment program may not work for a development project. Glenn Luker recently joined the NPD group with Essilor of America. He reports that, “NPD is much different than my former job in engineering, which had a very finite nature. In NPD, there are higher levels of complexity and uncertainty. I have had to learn how to be patient and respond to ambiguity with more sophisticated project management tools.” Ken Delcol of MDS Sciex is a little more direct: “The PM needs an innate sense: Is there a big bad problem given all the noise?”
Here are a few of the differences between development projects and deployment projects:
|Examples are new product development, software development, organizational change, architecture
|Examples are construction, systems integration and installation
|Progress measured by uncertainty reduction
|Progress measured by deliverables
|Many project lifecycles used
|Waterfall project lifecycle is most common
|Investment objectives include preserving strategic options and minimizing regrets
|Investment objective is tactical efficiency
|Leadership style emphasizes learning and dialogue
|Leadership style emphasizes supervisory command and control.
|Information systems are relatively informal
|Information systems are highly structured and capable of producing copious detail
|Adaptive and evolving with permeable boundaries to sense and respond to changes
|Closed and impermeable; task oriented
■ Modify the WBS to reflect the added detail as time and cost baselines become refined. Expand the black-box placeholders.
■ Keep focus on how the program will recognize and use validation and verification processes.
Managing the Dynamics of Phase Transition
Surfers need to maintain balance and momentum as they ride the face of the breaking wave. If surfers don't adapt to the wave's forces, they will plunge into the abyss. While most survive, they are often badly bruised by the forces crashing down on them. Likewise, NPD programs need to maintain balance and momentum. If done well, the team gets a thrilling sense of accomplishment. Managing phase-to-phase transitions is the key to success.
I refer to planning in the transition as inter-phase planning (contrasted to intra-phase planning, which is essentially Steps 3 and 4). Inter-phase planning is tricky and involves the transition from the closing processes of the prior phase to the initiating process of the following phase. Rolling wave requires skill; most of the typical mistakes made with rolling wave have to do with poor management of the phase transition. There are many forces that the program needs to manage, including execution inertia, high emphasis on detail, functional and personal conflict, creeping elegance, and listening closely to customer requests.
Three questions that the program manager should ask to help manage the phase transition are:
■ “Do we have enough information to move to the next gate?” Delcol finds that this question is a good criterion for helping the team to consider when to start and stop replanning. (Delcol is referring to the gate in a Stage GateTM NPD process for synchronizing and sustaining the investment in the development program.)
■ “Is that still our vision?” Often vision and objectives change. This question encourages the development and validation of a vision or completion statement that can serve as a touchstone. A good program manager will recognize the dynamics and continue the efforts in uncertainty reduction, whereas a mediocre program manager has tunnel vision and will get lost in technical details and problem solving.
■ “What changes need to be made to our WBS?” The complexity and dynamism of a development program is no excuse for not practicing change management. Motorola's Jacob notes: “You might not be able to do everything, though you thought you could at the start.”
(For more detail on managing phase dynamics, see my PMI 1998 symposium paper titled “Rolling Wave Project Planning,” where I apply the polarity management tool to balance a number of seemingly opposed imperatives.)
Become a Tools Strategist
I have evaluated the program management practices of some of the world's best new product development organizations and reached the conclusion that there are no “best practices” applicable to all projects. The practices that produce superior performance in one type of program will create dysfunction in others. The best program managers are “tools strategists” who select tools that are most likely to create expected outcomes with minimum potential for harmful side effects. These tools strategists evaluate the upside and downside of the strategies before electing to apply the tool.
I BELIEVE THAT INNOVATION PROJECTS benefit from approaches like rolling wave because they provide a framework for balancing structure and process (for control) with flexibility (for opportunity capture). Do not blindly accept my assertion that rolling wave program management can help NPD program managers bring an adaptive, flexible discipline to program planning and implementation. For example, if time to market and modularity are important to the product strategy, then the rolling wave approach will prioritize working on some features over others. Develop your maturity as a tools strategist by asking: To what extent does the tool enhance the alignment of the project architecture with the product strategy? What are the priorities that drive development? To what extent is the technique quick to learn, easy to teach, complete, and create tangible value for the customer?
Rolling wave is an excellent technique for development projects, because it provides a framework for agility: the balance of control and flexibility.
Reader Service Number 104