CHAPTER 6
Life Cycle Planning: Programs and Phases

All projects have phases and a project life cycle. As the projects get larger in terms of resources required and greater duration, these phases become more pronounced. Various industries have special language or jargon to describe the various phases of the larger projects. Large projects often become programs over time, and many projects are thought of or planned as programs from the start. In this chapter, the concept of a Program WBS—as introduced in Chapter 2—is expanded and related to the Project WBS.

LIFE CYCLE CONCEPTS

Many industries and organizations do their planning in terms of life cycles. This section addresses several life cycles and illustrates their common features and relationship to WBS concepts.

Generic Life Cycle

A sample generic life cycle of a project is shown in Figure 6-1.

FIGURE 6-1 Sample Generic Life Cycle

One popular construct for defining the phases in the life cycle is as follows:

Feasibility/Conceptual or Initiation Phase: Conduct feasibility analyses, conduct economic analyses, establish preliminary project objectives, prepare a preliminary WBS, a preliminary SOW, and a project charter.

Planning Phase: Firm up objectives and scope statement, define the work, develop the WBS, schedule the work, schedule the resources, create the budget, and prepare the project plan.

Execution or Implementation Phase: Perform the work, and develop the products, services, or results.

Closeout Phase: Obtain final acceptance of deliverables, and complete all financial, administrative, contractual, and personnel activities (project ends).

Operations and Maintenance Phase: The customer or sponsor uses the output of the project.

When the projects are small or the project has been outsourced, many project managers are not involved in the first phase. A project may be assigned based on work or decisions made at higher levels in the organization or on the judgment of a senior manager. The organization may be serving as a contractor or subcontractor, and the customer may perform the feasibility and possibly the initial planning phase, and then a contract is awarded through a procurement process.

Small projects frequently have an informal initial phase, especially office projects that may be the result of a meeting or an idea of a manager. For such projects, life cycle considerations are not as important as they are for larger projects; however, the project manager must be aware of where the project is in the generic spectrum.

Generic Consumer Product Life Cycle

Figure 6-2 presents a Generic Consumer Product WBS for a program consisting of five life cycle phases and an overall program management office.

FIGURE 6-2 Generic Consumer Life Cycle Program

Descriptions of these phases follow:

Feasibility/Conceptual Phase: Studies of alternative concepts, proposals to prospective customers, marketing analyses, conceptual designs, and mockups. Management approval to proceed into the next phase.

Planning/Prototype Phase: Development of the product design and the fabrication and testing of breadboard or prototype hardware, preparation of production specifications and project plans for production. Further marketing studies. Approval by management to proceed into production.

Quantity Production Phase: Two components—The first is the fabrication and test of the initial production configuration and the design and acquisition of the non-recurring production items such as tooling, plant rearrangement, and issuance of selected initial component purchase orders. These items would be planned and scheduled in a detailed Gantt chart. Also, the initial MRP or ERP programs would be populated with production data. The second component of this phase is the actual serial production of large quantities of the product. This production phase would include large orders for components, the fabrication into the final products, performance of QC inspections, and lot acceptance tests, as required. Changes would be carefully monitored and controlled via a configuration management process.

Distribution and Support Phase: This phase would proceed in parallel to the Quantity Production Phase. Operating and maintenance manuals would be prepared, validated, and printed; field and customer support personnel would be trained in the product operation; maintenance, reliability, and spares analyses would be performed; spares would be ordered from manufacturing. Transportation and warehousing would be planned and implemented to move the product from the factory to the consumer.

Closeout Phase: The final phase consists of those actions necessary to close down the production line, arrange for long-term customer support, prepare a “lessons learned” report, and archive the records.

U.S. Department of Defense Life Cycle for Acquisition of Major Products

Figure 6-3 is an abbreviated illustration of the life cycle phases used by the U.S. Department of Defense (DoD) for acquisition of major products.¹ The more complete figure is referred to as “The 5000 Model” and is explained in detail in the DoD procedures.²

FIGURE 6-3 DoD Generic Life Cycle

The description of these phases is as follows:

Concept and Technology Development: Studies of alternative concepts for meeting a mission need; development of subsystems/components and concept/technology demonstration of new system concepts. Ends with selection of system architecture and a mature technology to be used.

System Development and Demonstration: System integration; risk reduction; demonstration of engineering development models; development and early operational test and evaluation. Ends with system demonstration in an operational environment.

Production and Deployment: Low-rate initial production (LRIP); complete development of manufacturing capability; phase overlaps with ongoing operations and support.

Support: This phase is part of the product (not project) life cycle and represents program-type ongoing activity. Projects may be conducted during this phase to improve capability, correct defects, upgrade the technology, and so on.

The DoD was a pioneer in life cycle planning. Figure 6-3 shows the life cycle for systems acquisition. The DoD concept of a Program WBS is different from the multiphase project WBS just described because it generally does not cover the entire life cycle. The DoD Program WBS focuses on the acquisition phases and the evolution of the Program WBS as the system engineering and definition work progresses. The intent of the DoD Program WBS is to provide the framework to plan and manage the acquisition of major DoD systems and do it within the procedures and discipline prescribed by the DoD. For this reason, the DoD and MIL-HDBK-881A³ have a narrower focus than the PMBOK^® Guide and this book.

From the DoD perspective, in order to use the WBS as a framework for the technical objectives of a program (in addition to its use as a management tool for cost and schedule control), the WBS must be product-oriented. The elements must represent identifiable work products, whether they are equipment, data, or related service products. The DoD approach ensures complete definition of the program effort so that it encompasses the work to be performed by all participants, prime contractors, contractors, and subcontractors.

The DoD Handbook does not preclude use of the WBS to provide a service or result, as discussed in this book, but it does recommend that certain philosophies and terminology be followed when major military hardware and software systems are being acquired.

Typical Construction Project Life Cycle

An example of life cycle phases for a typical construction project is presented in Figure 6-4.

FIGURE 6-4 Representative Construction Project Life Cycle

At the end of the Feasibility Stage, the Project “GO” decision is made. The end of the Planning and Design Stage is defined by the letting of all major contracts. At the end of the Construction Stage, the installation is substantially complete, and at the end of the Turnover and Startup Stage, the facility has been accepted and is in full operation.

If an “operations and maintenance” or a support phase is added, as was done in the DoD example, the project evolves into a program. It is important to note the definition of a program: A group of related projects managed in a coordinated way. Programs usually include an element of ongoing work.

Museum Program Life Cycle

Another example follows in Figure 6-5. It is a description of the phases used by a museum for the development of a new exhibit. Because of the existence of the Operation and Maintenance phase of ongoing work, the example is referred to as a program.

FIGURE 6-5 Representative Museum Exhibit Program Life Cycle

Other industries and government organizations have somewhat different life cycle structures. While all the examples presented have several things in common, the important thing they share is the fact that all the phases have well-defined outputs that are normally completed before proceeding into the next phase.

Such a circumstance is not always the case, because there may be an overlap between phases or there may be some loose ends that need to be completed before a phase is completely closed out. The term “substantially completed,” while somewhat vague, is often used successfully in cases in which a defined decision point or milestone exists at the end of one phase that constrains the start of the next phase.

In effect, each phase is a project by itself: a temporary endeavor undertaken to create a unique product, service, or result. For each of the examples presented in this section, each of the individual phases or stages meets the definition of a project.

Information Technology Program Life Cycle⁴

Information Technology (IT) Programs/Projects have their own life cycles and their own language for the work performed. The phases or stages in a generic IT program are shown in Figure 6-6 and are described in this section.

FIGURE 6-6 Information Technology Program

All projects start for a reason, which means all projects start with an idea or to meet a need. This idea or need might be to improve a process or product, to develop a new process or product, or to provide some result. Some action is required to start a project; this occurs during a project concept period. This is the creative period before any formal or informal discussions take place. It might be an idea that has occurred to a supervisor while driving to work or an idea that has been simmering in a computer programmer’s head for weeks. This is the spark that starts the project at WBS element 1, project initiation, as shown in Figure 6-6. A description of this and the other stages in a typical IT program life cycle follow.

1. Project Initiation Stage

At the start of any project, there will be a variety of ideas and opinions about the purpose and scope of the project, what the final product of the project will be, and how the project will be carried out. The Project Initiation stage is concerned with taking these ideas and intentions and developing them into a formal, planned, resourced, and funded project. It includes the development of the business case and defines what resources and associated time commitments are required to carry out the project.

The product of the Project Initiation stage is an overall plan for carrying out the whole project and a more detailed plan for the next stage of the project: the Design stage.

2. Design Stage

The work performed in the Design stage is to define and design a new system in a way that:

Rapidly establishes, agrees on, and prioritizes the critical requirements for the new system

Develops a functional description (data and process models) of the required system

Establishes a prototype based upon real-world business scenarios

Establishes a detailed set of acceptance criteria and an associated System Test

Produces a logical design for the system

Produces a detailed physical design for the system so that construction of the system can begin more quickly

3. Implementation Stage

The work performed in the Implementation stage consists of building and implementing the system in a way that meets the agreed-upon specifications, tests for defects, and implements live running of the system in the production environment so that users can begin live running of the system.

4. Closeout Stage

The Closeout stage is the same as the generic project management methodology. All loose ends are tied up and the project is completed.

Figure 6-7 presents the typical output from each IT life cycle phase. Note that it is somewhat different from the generic project management life cycle; however, the same concept applies here as it did to the earlier examples: There are discrete phases or stages where work is performed in order to plan and define the project, and there is an implementation phase in which the majority of the work is performed and in which the final product is delivered. (Figure 10-10 in Chapter 10 presents the complete WBS for an IT Program.)

FIGURE 6-7 Information Technology Life Cycle Output

U.S. Government Office of Management and Budget Life Cycle Planning

The U.S. Government Office of Management and Budget (OMB) requires life cycle planning and submittal of life cycle data on major projects—government-wide.⁶ The data required are for the general life cycle phases, defined by the OMB as:

Planning

Acquisition

Maintenance

New projects must be justified based on the need to fill a gap in the agency’s ability to meet strategic goals and objectives with the least life cycle costs of all the various possible solutions and on the need to provide risk-adjusted cost and schedule goals and measurable performance benefits.⁷ This means that agency programs should be planned and implemented on a life cycle basis, with each phase clearly defined and with clear output products.

An example is the museum program shown in Figure 6-5. As discussed, each individual phase should be planned and implemented as a project. For reconciliation with the OMB life cycle phases, the planning phase would include the program definition project plus the planning project; the acquisition phase would include the development and production project plus the closeout project; and the maintenance phase would be the operation and maintenance project. Depending on agency practices, the budget for the program management work activities would be covered by the normal in-house labor accounts or could include support contractor labor.

A program-wide WBS provides the planning framework for meeting the life cycle planning requirement, as well as other requirements of Exhibit 300 of Circular A-11, Part 7.

LIFE CYCLE WBS CONCEPTS

A WBS should be developed for each of the various phases of the life cycle of a project. Collectively these become the program WBS. The basis for the discussion in this section is the museum exhibit example outlined in Figure 6-8. The life cycle phases for the generic museum exhibit program are referred to as projects. The Museum Exhibit Program phase outputs are summarized in Figure 6-9.

FIGURE 6-8 Program WBS

FIGURE 6-9 Outputs of Life Cycle Phases

The Program WBS follows the rules outlined in Chapter 2, with only “Program Management” as the top-level cross-cutting element. Each element has its own set of deliverables. Each of the elements is a project, except for the “ongoing” Operation and Maintenance element that contains a combination of processes and projects. The Program Level is defined as Level 0 so that the top-level element of each project remains Level 1.

There are three types of “project management” WBS elements in a program organized and managed by life cycle phases:

The traditional project management activities at Level 1, relabeled “Program Management,” apply to activities that are “overhead” to the entire program and cross-cut all phases or lower-level projects.

Project management activities that relate to the management of each phase as an independent Level 2 project.

Project management activities that are performed in one phase but relate to subsequent phases; these activities are unique to life cycle subprojects within a larger program framework.

The first category, program management, may not always exist. A project may evolve into a program, and all Project Management elements are at Level 2. The existence of a program management level also implies that some effort is performed prior to the project definition phase. The outcome of the project definition phase may be the establishment of a program management function that provides program management support and performs project management functions for all phases.

The second category is the “normal” Project Management element of the WBS, as described in Chapter 2.

The third category is somewhat different because it includes specific deliverables within the Project Management element that relate to later phases of the program. It is no longer just an overhead type of element but includes cross-cutting analytical elements. In each phase of the museum example in Figure 6-5, there are analytical WBS elements that relate to the planning of the subsequent phase and require input from the other work in the phase. For example, outputs of the Project Management element in the Project Definition phase are the WBS and scope statement for the Planning phase and the preliminary WBS, schedule, and resource plans for the later phases.

Similarly, the Planning Project Management element for the Planning phase would include those elements that related to management of the Planning phase and would include the important output of the planning activity that results in a Project Plan for the subsequent Development and Production phase of the project, where most of the money and resources will ultimately be spent.

The Level 3 breakdown of WBS element B.7 is shown graphically in Figure 6-10 in the partial WBS. The complete project is presented at Level 1 with six elements labeled A through F. These six elements meet the 100 percent rule. Five of these elements, A through E, are also identified as projects in the figure and are phases of the program as well. A phase of a program is a project that bears a time relationship to the other projects that make up the program.

FIGURE 6-10 WBS for Program and Project Management in the Life

The Program Management element at Level 1 is neither a subproject nor a phase; it is a normal Project Management element, except for the fact that it cross-cuts the entire program. A possible decomposition of this element, as shown in Figure 6-11, includes only total program elements.

FIGURE 6-11 Program Management Decomposition

This example is not the only possible decomposition, and various organizations may approach the structuring of the Program Management element of the WBS differently. For example, all the planning for the various phases could be included in the Program Management element rather than a part of each Project Management element within each phase. The important factor is to identify all the work.

The decomposition of the Planning Phase/Subproject (B) is shown on Figure 6-10. Elements B.1 through B.6 are normal Level 2 WBS elements, and B.7 is a normal Project Management element except for the fact that it includes one of the major deliverables from this phase. The decomposition of Planning Project Management has four major elements at Level 3: B.7.1 through B.7.4. The Level 4 decomposition of these elements is also shown in Figure 6-8 as numbered items under the Level 3 element.

The Level 3 WBS elements consist of the following types of elements:

B.7.1 Planning Phase Project Management: The normal, analytical project management effort that includes the work of managing the Planning Phase of the project.

B.7.2 Development and Production Phase Plan: An integrative element that produces one of the major deliverables or outputs from this phase of the overall program. This element could have been arrayed at Level 2 but is normally considered work performed as part of the project management category. In this case, the plan is a cross-cutting element of both Level 2 and Level 3.

B.7.3 Closeout and O&M Phase Plans: Also an analytic element that will produce a preliminary deliverable during this planning subproject phase; this deliverable will be completed prior to the end of the Development and Production phase.

B.7.4 Project Management Office: Another normal WBS element under B.7 Planning Project Management that in this case represents the work performed by personnel resources supporting the project as part of the project management office.

These descriptions illustrate the differences in a WBS for a single project and for a set of projects or subprojects that make up the program life cycle. The difference is the role of project management in integrating the project at several levels. Although the phases are different in terms of the work performed in each phase, they are all part of one larger program that is planned in its totality by the program manager and the program management office.

PHASES WITHIN PROJECTS

Some organizations operate with a standard set of process steps as they proceed through a particular phase of a typical project. These are sometimes incorrectly referred to as life cycle steps and include such items as design – procure – fabricate – test for a hardware product. For a software product, the steps may be requirements – design – code – test.

Because of the familiarity with this process within a particular organization, it is a temptation to structure the WBS accordingly, even though the output is a product and not a result. (It is important to recall that “result” projects have process elements at Level 2.) It is important to keep the WBS focused on the output products and deliverables, and the decomposition should start there. There is no problem in structuring a program WBS by life cycle phases, as discussed earlier in this chapter. That is a different issue.

NOTES

1. Department of Defense, Mandatory Procedures for Major Defense Ac- quisition Programs (MDAPS) and Major Automated Informa tion System (MAIS) Acquisition Programs, DoD 5000.2-R (Washington, D.C.: Department of Defense, 2002).

2. Ibid.

3. Department of Defense, DoD Handbook: Work Breakdown Structures, MIL-HDBK-881A, Sections 2.1 and 2.2 (Washington, D.C.: Department of De fense, 2005).

4. Material used in this section is adapted from Gregory T. Haugan, Project Management Fundamentals: Key Concepts and Methodology (Vienna, VA: Management Concepts, 2006), Appendix D.

5. Note the definition of “initiation” by custom is different for IT projects from that used in the project management methodology for a generic life cycle.

6. Office of Management and Budget, Circular A-11: Preparation, Submission, and Execution of the Budget (Washington, D.C.: Office of Management and Budget, 2002), Part 7.

7. Ibid., Section 300, “Planning, Budgeting, Acquisition, and Management of Capital Assets,” 8.