Program Plan

Fundamental to the success of any project is documented planning in the form of a program plan. In a ideal situation, the program office can present the functional manager with a copy of the program plai simply say "accomplish it." The concept of the program plan came under severe scrutiny during the 1 when the Department of Defense required all contractors to submit detailed planning to such extreme many organizations were wasting talented people by having them serve as writers instead of doers. Si then, because of the complexity of large programs, requirements imposed on the program plan have b eased.

For large and often complex programs, customers may require a program plan that documents all activities within the program. The program plan then serves as a guideline for the lifetime of the prog and may be revised as often as once a month, depending on the circumstances and the type of program (i.e., research and development programs require more revisions to the program plan than manufacturing or construction programs). The program plan provides the following framework:

• Eliminates conflicts between functional managers

• Eliminates conflicts between functional management and program management

• Provides a standard communications tool throughout the lifetime of the program. (It should be geared to the work breakdown structure.)

• Provides verification that the contractor understands the customer's objectives and requirements

• Provides a means for identifying inconsistencies in the planning phase

• Provides a means for early identification of problem areas and risks so that no surprises occur downstream

• Contains all of the schedules defined in Section 11.19 as a basis for progress analysis and reporting

Development of a program plan can be time-consuming and costly. The input requirements for the program plan depend on the size of the project and the integration of resources and activities. All levels of the organization participate. The upper levels provide summary information, and the lower levels provide the details. The program plan, like activity schedules, does not preclude departments from developing their own planning.

The program plan must identify how the company resources will be integrated. Finalization of the program is an iterative process similar to the sequence of events for schedule preparation, shown in Figure 11-12. Since the program plan must explain the events in Figure 11-12, additional iterations are required, which can cause changes in a program. This can be seen in Figure 11-14.

The program plan is a standard from which performance can be measured, not only by the customer, but by program and functional management as well. The plan serves as a cookbook for the duration of the program by answering these questions for all personnel identified with the program:

• What will be accomplished?

• How will it be accomplished?

• Where will it be accomplished?

• When will it be accomplished?

• Why will it be accomplished?

The answers to these questions force both the contractor and the customer to take a hard look at:

• Program requirements

• Program management

• Program schedules

• Facility requirements

• Logistic support

• Financial support

• Manpower and organization

Figure 11-14. Iterations for the planning process.

The program plan is more than just a set of instructions. It is an attempt to eliminate crisis by preventing anything from ''falling through the cracks." The plan is documented and approved by both the customer and the contractor to determine what data, if any, are missing and the probable resulting effect. As the program matures, the program plan is revised to account for new or missing data. The most common reasons for revising a plan are:

• "Crashing" activities to meet end dates

• Trade-off decisions involving manpower, scheduling, and performance

• Adjusting and leveling manpower requests

Maturity of a program usually implies that crisis will decrease. Unfortunately, this is not always the case.

The makeup of the program plan may vary from contractor to contractor.12 Most program plans can be subdivided into four main sections: introduction, summary and conclusions, management, and technical. The complexity of the information is usually up to the discretion of the contractor, provided that customer requirements, as may be specified in the statement of work, are satisfied.

The introductory section contains the definition of the program and the major parts involved. If the program follows another, or is an outgrowth of similar activities, this is indicated, together with a brief summary of the background and history behind the project.

The summary and conclusion section identifies the targets and objectives of the program and includes the necessary "lip service" on how successful the program will be and how all problems can be overcome. This section must also include the program master schedule showing how all projects and activities are related. The total program master schedule should include the following:

• An appropriate scheduling system (bar charts, milestone charts, network, etc.)

• A listing of activities at the project level or lower

• The possible interrelationships between activities (can be accomplished by logic networks, critical path networks, or PERT networks)

• Activity time estimates (a natural result of the item above)

The summary and conclusion chapter is usually the second section in the program plan so that upper-level customer management can have a complete overview of the program without having to search through the technical information.

The management section of the program plan contains procedures, charts, and schedules as follows:

12 Cleland and King define fourteen subsections for a program plan. This detail appears more applicable to the technical and management volumes of a proposal. They do, however, provide a more detailed picture than presented here. See David I. Cleland and William R. King, Systems Analysis and Project Management (New York: McGraw-Hill, 1975), pp. 371-380.

• The assignment of key personnel to the program is indicated. This usually refers only to the program office personnel and team members, since under normal operations these will be the only individuals interfacing with customers.

• Manpower, planning, and training are discussed to assure customers that qualified people will be available from the functional units.

• A linear responsibility chart might also be included to identify to customers the authority relationships that will exist in the program.

Situations exist in which the management section may be omitted from the proposal. For a follow-up program, the customer may not require this section if management's positions are unchanged. Management sections are also not required if the management information was previously provided in the proposal or if the customer and contractor have continuous business dealings.

The technical section may include as much as 75 to 90 percent of the program plan, especially if the effort includes research and development. The technical section may require constant updating as the program matures. The following items can be included as part of the technical section:

• A detailed breakdown of the charts and schedules used in the program master schedule, possibly including schedule/cost estimates.

• A listing of the testing to be accomplished for each activity. (It is best to include the exact testing matrices.)

• Procedures for accomplishment of the testing. This might also include a description of the key elements in the operations or manufacturing plans as well as a listing of the facility and logistic requirements.

• Identification of materials and material specifications. (This might also include system specifications.)

• An attempt to identify the risks associated with specific technical requirements (not commonly included). This assessment tends to scare management personnel who are unfamiliar with the technical procedures, so it should be omitted if at all possible.

The program plan, as used here, contains a description of all phases of the program. For many programs, especially large ones, detailed planning is required for all major events and activities. Table 11-5 identifies the type of individual plans that may be required in place of a (total) program plan. However, the amount of detail must be controlled, for too much paperwork can easily inhibit successful management of a program.

The program plan, once agreed on by the contractor and customer, is then used to provide program direction. This is shown in Figure 11-15. If the program plan is written clearly, then any functional manager or supervisor should be able to identify what is expected of him.

The program plan should be distributed to each member of the program team, all functional managers and supervisors interfacing with the program, and

TABLE 11-5. TYPES OF Type of Plan


Configuration management


Logistics support




Quality assurance








How much money is allocated to each event? How are technical changes made? What facilities resources are available? How will replacements be handled? How is the program office organized? What are the time-phase manufacturing events?

What are my sources? Should I make or buy? If vendors are not qualified, how shall I qualify them?

How will I guarantee specifications will be met?

What are the technical activities?

Are all critical dates accounted for?

What are my time-phased tooling requirements?

How will I maintain qualified personnel?

How will goods and services be shipped?

Figure 11-15. Program direction activities.

all key functional personnel. The program plan does not contain all of the answers, for if it did, there would be no need for a program office. The plan serves merely as a guide.

One final note need be mentioned concerning the legality of the program plan. The program plan may be specified contractually to satisfy certain requirements as identified in the customer's statement of work. The contractor retains the right to decide how to accomplish this, unless, of course, this is also identified in the SOW. If the SOW specifies that quality assurance testing will be accomplished on fifteen end-items from the production line, then fifteen is the minimum number that must be tested. The program plan may show that twenty-five items are to be tested. If the contractor develops cost overrun problems, he may wish to revert to the SOW and test only fifteen items. Contractually, he may do this without informing the customer. In most cases, however, the customer is notified, and the program is revised.

Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook

Post a comment