Manage innovation programs with a rolling wave

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.

Exhibit 1. Rolling wave is an iterative style of planning that balances top-down and bottom-up planning. The arrows show major planning transition points.

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
Program Management

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).

■ 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 Gate^TM 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

Gregory D.Githens, PMP and certified NPD Professional, is managing partner with Catalyst Management Consulting (www.CatalystPM.com). In addition, he teaches the rolling wave technique in the PMI^® Seminars World program on Rapid Project Development; was a member of the core team for the PMBOK^® Guide-2000 edition revision; is a co-founder and past chair of PMI's NPD SIG and past editor of its Project Management Innovations newsletter; and is a frequent contributor to PM Network.