“We choose to go to the moon in this decade, and do the other things, not because it is easy, but because it is hard.” With those words, President Kennedy launched the program that has become the stereotypical example of multi-generation project planning.
At the time, multi-generation project planning (MGPP) was not a popular tool, but the way in which the moon shot was achieved is an excellent example of the power of MGPP to navigate toward challenging objectives. And it provides a chance to explore how it fits with Six Sigma.
When an organization wants to make a sea change, Design for Six Sigma (DFSS) is usually the preferred way to accomplish the change. Organizations choose DFSS over DMAIC when an improvement in the current process will not be sufficient. It is clear that the change will require a “clean sheet of paper.” For these large, complex projects, there will often be a combination of things that need work. Keeping all these activities generally headed in the same direction is one of the key strengths of MGPP.
In some organizations, every DFSS project performs MGPP, or understands its fit within a bigger MGPP, during the Define phase. The MGPP can provide the context within which the project exists. This helps the project better understand its goals, to see beyond the boundaries of the projects, and give a better basis on which to make decisions.
The foundation of MGPP is developing an understanding the capabilities, or technologies that are required to accomplish the longer-term goal. The individual capabilities are categorized depending on what sort of grasp we have on those technologies.
For MGPP purposes, the needed technologies fall into three categories:
The MGPP process has three major steps: 1) defining the goal, 2) identifying the generations, and 3) identifying and categorizing the technologies.
The most important part of the multi-generation project planning process is identifying the overall goal. An organization does not undertake an MGPP for some trivial goal, in fact, an organization does not undertake a DFSS project on some small whim. The goal of the MGPP must be something worthwhile, compelling and difficult.
When JFK charged the nation with the goal of placing a man on the moon, this goal was one that captured the imagination, motivated people, and was unimaginably difficult. He also placed a deadline on the goal – “in this decade.” It is important to have time pressure for these very hard projects. Projects of this nature tend to go on forever if a stake is not placed in the ground.
Once the goal is visible, it is time to identify the generations. Typically, three or four generations are about right. However, sometimes more are necessary. The tool is often used to develop product plans, and especially in the case of a product plan, a larger number of generations may be desirable.
Each generation should be identifiable, something that everyone can understand and relate to. Each generation should represent a significant achievement in its own right, and yet be a step towards the larger goal.
It also is helpful if each generation can embody some subset of the capabilities needed for the ultimate goal. The overall goal can be made more accessible if each of the generations can focus on a smaller number of technologies.
For the moon shot, NASA identified three generations. Mercury put a man in space, something that the United States had not done up to that time. Gemini put two men in orbit, an even more challenging objective, but a capability that was needed in order to reach the ultimate goal. Finally, Apollo placed three men in orbit around the moon, and enabled two of them to descend to the moon’s surface and walk on the moon.
The generations help break up the combination of capabilities required into more manageable pieces. The identification of technologies and the identification of generations might be carried out in parallel. The best plans will have only a few totally new technologies in each generation.
As an example, Mercury required life support and some sort of recovery mechanism. Rockets capable of a payload were available, for simply putting a capsule into space and allowing it to fall back to earth ordinary aircraft communications capabilities were adequate, and navigation was not much of an issue.
However, when Mercury was done and the project turned to Gemini, the focus changed. While the basics of life support were explored by Mercury, the capability now needed to be enhanced to last much longer. The basic recovery technology developed by Mercury could be now used throughout the program. But Gemini now required much larger boosters to get a larger, heavier capsule not only into space, but into orbit. Communications capabilities now needed to be improved, and navigation becomes an issue.
By the start of Apollo, most of the required technologies were in hand. Apollo had only two major things that needed to be accomplished. First, the ability to orbit another body needed to be demonstrated. Gemini orbited the earth, but was the existing navigation sufficiently accurate to orbit a body a quarter of a million miles away? Secondly, and perhaps the most challenging of all the capabilities was the lunar lander. Never had anyone been able to get from a spacecraft orbiting an alien world, transfer down to the surface, and get back again. The first capability was little more than validating what NASA scientists thought they already knew. The lander, however, was entirely new territory.
As the project looks to the required technologies, it must understand what type of effort needs to be undertaken to develop those capabilities.
For many technologies, the organization understands how to get those capabilities. The technology might be licensed from some other organization, or it might be understood within the organization. Perhaps it makes sense to outsource the activity. These kinds of capabilities will lead to “just do it” projects that are within the organization’s current abilities.
For certain capabilities, however, the knowledge might be available, but be required at a higher level of capability than is currently available. For these technologies, it makes sense to execute DMAIC projects to improve the organization’s capability.
Finally, for technologies that require invention, that are totally new, DFSS projects will need to be executed to acquire the capability.
Once the various components are identified, the plan can be laid out in a simple grid. The exact format should be chosen to fit the organization, but the typical MGPP might look something like the table below.
|Goal: Put a Man on the Moon and Return to Earth|
Imrpoved Titan III Booster
Improved Saturn V Booster
|Just Do It||Aircraft Communications
|Recover Capsule||Recover Capsule
Obviously, the MGPP for the actual moon shot would be far more complex than this. However, for a very complex undertaking it may be preferred to “layer” the MGPP, having lower level MGPPs for some projects. The MGPP is an important communication tool, and participants must be able to grasp the plan easily.
Once the plan is in place and agreed to, it is time to kick off projects to develop each of the first generation technologies.
While the MGPP will frame the various projects, the projects also will affect the MGPP. Each project will make some discoveries, and these discoveries will often need to feed back into the MGPP. Projects should have an opportunity to influence the MGPP, at least at the close of the project, but often at other times. The end of the Measure phase is frequently a place where MGPP-impacting discoveries are available.
The MGPP also is important for scope management within the project. Projects frequently discover that something is more difficult than first imagined. Teams often discover things they could do and, especially in software projects, may pressure the Black Belt to include one or more useful extra features.
The MGPP allows the project to see whether pulling a particular feature forward makes sense, or whether some particular capability is better deferred until later in the program. By giving the Black Belt a more complete context, scope decisions can be made more rationally.
Strategic programs are often complex, and multi-generation project planning allows those complex programs to be managed. It allows projects to be rationally scoped, and provides individual project managers with the tool to manage those scopes. All the while it ensures that the capabilities ultimately required by the program are being developed.