Planning Large Programs

The following is an abstract introduction to the methodology we’ve developed to manage large programs over the past 20 years, through hundreds of client experiences around the world--from the $6B Saturn program at GM to multi-million & billion dollar solar and semiconductor fabs. They all share a common foundation in our best practice research into how teams deliver the right “thing” at the right time.

Obvious, but rarely clear in large programs. What is the goal? Clarifying and articulating this is our starting point. Typically, this is different for each stakeholder...can remain fluid, and is subject to retroactive change to meet the immediate needs of the situation. Without a clear end-state around which to converge, large programs tend to expand which means delay...which can mean large losses.

Goal convergence has everything to do with defining the requirements clearly and ideally based on the customer’s voice. Again, another obvious statement, but in our experience, rarely done well and also subject to fluid change over time. When requirements have high degrees of freedom, so does the schedule. Yet, best practice teams rarely fix requirements, but rather they keep them flexible within upper and lower bounds. The requirements then drive the plan.

The third high-level element is the plan. This is the basis of execution. Again, another rather obvious statement, but why do most plans fail to capture the reality of the situation, are out of date, and can’t keep up with the complex and changing environment of a large program? The other extreme, based on experience, are plans that present too much detail; deep vertical silos of data that provide little in the way of the lateral “touch-points with which to manage by. In both cases though, data is usually stale and not relevant to decision-makers trying to run things.

Some of this problem is solved with our macro and micro approach. The macro provides a complete view of the program from 32,000 feet. It ties all the big pieces together and provides the management team with a single thread from start to finish; from concept to realization.

The micro provides the next level of detail that validates the macro and provides the team with the mechanism to execute. The macro runs through the complete program and the micro defines just the near term, i.e., the next 2-3 months. This kind of hybrid approach to planning is an essential best practice of fast teams, they don’t waist time planning details they don’t know about or they know will change!

The reason to do all this is to get a schedule that is real and that is accurate in order to be able to accelerate the program. Again, we know from best practices that fast teams pull-in their schedules before they slip in order to bank time, for when it is needed in the future when things go wrong, which they will...regardless of how well they plan.

Lets look at Requirements in more detail... they tend to take a two level form, first to define market requirements and second to understand the customer requirements. We do this with decision-models that help us prioritize first the segment to focus on and then the most important customer needs or wants around which to design and deliver the capability, be it a product, a service, or a production resource. Knowing the 20% of the requirements that generate 80% of the value is key to understanding how to deliver more with less... and to understand what customers value most. It’s virtually impossible to base planning assumptions on unclear, poorly articulated, and changing requirements.

We start planning top-down with a macro plan, not bottom-up from the detail. “Seeing the forest for the trees” is a key success factor in managing a large program, and “seeing the trees and not the forest” from the detail up is a recipe for disaster. This macro thinking is counter intuitive since we all learned in schools that more is better, but in complex programs more is just more, and the more of it you get, the more overwhelmed you become!

The macro mind-map, with the big buckets of work and their subsequent doneness criteria, provide the holistic and integrated thread that laterally links the goal with the end-state. Most large programs lack this big-picture view, or if they have one, it is so “big-pitcure” as to be of now value to actually running the program. On a large semiconductor fab this became a 300-400 activity macro plan, on a first Saturn car program this was a less than 100 activity critical path that linked the development of the car to construction the billion-dollar plant... and then to the creation of a $750M dealer network. These are just some of the examples of how this thinking was used.

The macro map becomes the macro critical path schedule where the critical touch-points are defined and managed laterally, rather that vertically through classic functional silo management practices. Again, this concept is based on best practices of exceptional teams.

Refresh Planning is the process of updating the schedule with what actually happened, breaking down the macro to the next level of detail, and then engaging the team in pulling-in the schedule. Fast teams do this short-interval-scheduling in order to accelerate the schedule and make sure that it reflects reality. They manage the trends, before-the-fact rather than after things are a mess.

Still this is not enough on very large programs. Large programs require management of multiple contractors and vendors, all working at the same time to deliver their piece of the puzzle. When these resources are left to “self-manage” ...chaos breaks out, since they’re only objective is to sub-optimize their piece so they can get in, get out, and get paid. The key to changing this “manage the owner” dynamic is to use the macro and micro schedule as the top-down framework, around which you hang the detail that is rolled-up from the contractor and vendor schedules.

The difference with this approach is that rather than building schedules from the bottom-up and trying to hopelessly integrate them from the top down, we use the top-down schedule to drive the detailed schedules since the critical interface and integration points are in the top-level schedule and carefully managing these touch-points are really the drivers for a successful program. These roll-ups need to be carefully architected and managed by the owner team in order for this process to work.

The reason to do this is to accelerate the schedule, since we know from best practices that we need to accelerate the schedule just so we can hit it on time since its natural direction is to the right if left alone. The macro and micro plan becomes the vehicle to simulate these pull-ins and drive them back down to the detailed schedule silos.

Example of large program priorities