THE PROJECT PLAN
3.2 NEEDS, GOALS, OBJECTIVES, AND REQUIREMENTS
This first part of a project plan can be divided into two parts, the first consisting of needs, goals, and objectives, and the second constituting the requirements.
Requirements are of two types, project and system, with the latter being quite voluminous and usually a part of the formal contract between the customer and the system developer. Statements of needs, goals, and objectives can be rather variable.
The statements of needs, goals, objectives, and requirements come from the customer and acquirer of the system to be developed. The outside system developer, therefore, is a recipient (rather than an original source) of these statements. For at least this reason, they are much condensed or simply reit- erated or incorporated by reference when a Project Manager deals with them in a project plan.
3.2.1 Needs
The Department of Defense (DoD) acquisition directive [3.1] states that three key aspects of acquisition management are
1. Translating operational needs into stable affordable programs 2. Acquiring quality products
3. Organizing for efficiency and effectiveness
With respect to the first key, the statement is made [3.1] that “prudent man- agement also dictates that new acquisition programs only be initiated af- ter fully examining alternative ways of satisfying identified military needs.”
Mission needs are also “identified as a direct result of continuing assessments of current and projected capabilities in the context of changing military threats and national defense policy.” Examples of possible military needs that are identified in the acquisition directive are
1. The need to impede the advance of large armored formations 200 kilo- meters beyond the front lines, or
2. The need to neutralize advances in submarine quieting made by potential adversaries
Whereas the DoD may have rather formal procedures and processes for iden- tifying and documenting needs, other government agencies and potential commercial clients are likely to be much less structured in their approach to this issue.
The bottom line, with respect to needs, is simply that the system acquirer must make sure that a true need exists for the system in question. If that is not the case, the project may ultimately not be able to be sustained. The reader who wishes to explore this matter in greater depth may obtain the DoD directive cited or examine the commentary of J. Davidson Frame, who spends an entire chapter in his book [3.2] on the matter of “making certain that a project is based on a clear need.”
In terms of the program plan, the statement of need can be abstracted from the needs as represented by the acquisition agent. It can be very short and expressed in only a few lines. This is in distinction to the needs analysis and confirmation carried out by the acquirer of the system. As indicated by the earlier DoD directive, such a needs analysis and assessment can be rather formal and substantial, following the guidelines of the DOD.
3.2.2 Goals and Objectives
Goals and objectives are usually short declarative statements, with goals being rather broad and objectives under each goal being somewhat more specific, although some treat goals and objectives in reverse order. They are often established for programs in distinction to projects. For this reason, they may not be a firm requirement as part of a project plan. An illustrative set of goals and objectives is shown in Table 3.1, in relation to an overall defense science and technology strategy.
Another example of a stated objective, as articulated by the U.S. Coast Guard (USCG) in a real-world project procurement [3.3], is
1. To support marine safety and law enforcement activities 2. To record activities and resource usage
3. To analyze mission performance
4. To monitor program effectiveness and resource usage
TABLE 3.1 Illustrative Defense Science and Technology Goals and Objectives
Goal A: Deterrence Objectives
A.I Deploy weapon systems that can locate, identify, track, and target strategically relocatable targets.
A.2 Attain worldwide, all-weather force projection capability to conduct limited warfare operations (including special operations forces and low intensity conflict) without the requirement for main operating bases, including a rapid deployment force that is logistically independent for 30 days.
A.3 Eliminate the threat posed by nuclear ballistic missiles of all ranges, through non-nuclear methods and in compliance with all existing treaties.
Goal B: Superiority Objectives
B.1 Attain affordable, on-demand launch and orbit transfer capabilities for space deployed assets with robust, survivable command and control links.
B.2 Regain the substantial antisubmarine warfare advantages the United States enjoyed until recent years.
B.3 Achieve worldwide, instantaneous, secure, survivable, and robust command, control, communications, and intelligence (C3I) capabilities within 20 years to include: (a) on-demand surveillance of selected geographical areas; (b) real-time information transfer to command and control authority; and (c) responsive, secure communications from decision makers for operational implementation.
B.4 Field weapon systems and platforms that deny enemy targeting and allow penetration of enemy defenses by taking full advantage of signature management and electronic warfare.
B.5 Deploy enhanced, affordable close combat and air defense systems to overmatch threat systems.
B.6 Field affordable “brilliant weapons” that can autonomously acquire, classify, track, and destroy a broad spectrum of targets (hard fixed, hard mobile, communications nodes, etc.).
Goal C: Affordability Objectives
C.1 Reduce operations and support resource requirements by 50% without impairing combat capability.
C.2 Reduce manpower requirements for a given military capability by 10% or more by 2010.
C.3 Ensure the affordability, producibility, and availability of future weapons systems.
5. To exchange information between USCG offices, other government agencies at the federal and state level, natural resource trustees, and certain private organizations
6. To fulfill specific statutory requirements
We note that these statements of objectives are concise and to the point and refer specifically to the project work that is being procured by the customer, in this case from the Coast Guard.
3.2.3 Requirements
Requirements, as alluded to in earlier chapters, is a dense and important subject. At the outset, we make a distinction between two types:
1. Requirements to be fulfilled by the project (project requirements) 2. Requirements of the “system” that the project addresses (system re-
quirements)
Project requirements refer to all the work to be performed on the project.
System requirements are applicable to the “system” that is being addressed by the project. To illustrate the difference, let us assume that the project is to design, but not build, a new “subway” system for a city. That is, the project is limited to design and does not include the construction of any hardware or software for the system. The project requirements, therefore, are limited to all the work to be accomplished as part of the design process only. This may include estimating the cost of the subway system for each year during its entire life cycle. However, the cost of the project itself, limited as it is to the design phase, is clearly a subset of that total cost, and is likely to be only a minor part of the life-cycle cost of the subway system. The system requirements describe, at increasing levels of detail, the full characteristics of the subway system, from initial design to operations and support.
Thus, the Project Manager (PM) must keep in mind this distinction when constructing the project plan. The latter should be focused on the project requirements, with the system requirements carried forth, as defined by the customer, in an ancillary document to be used in engineering the system in question. Further discussions of the ways in which the system requirements are to be handled are found in Chapter 8.
Project requirements are often stated by a customer in the main body of a request for proposal in both broad and specific terms, whereas system requirements can be described in several volumes of reports. An example of the former is shown in Exhibit 3.1, drawn from a requirements statement in a U.S. Coast Guard procurement dealing with mission-oriented information systems engineering (MOISE) support.
Exhibit 3.1: U.S. Coast Guard Statement of Requirements [3.3]
The contractor shall furnish the equipment, software, maintenance, ser- vices, and support required under the terms and conditions of the contract.
The major requirements are
1. Technical, functional, data, programmatic, and strategic integration of information systems
2. System and software development services within the information sys- tem (IS) life-cycle phases defined by the U.S. Coast Guard
3. Management, quality assurance, and requirements metrics
4. Cross-cutting requirements that span more than one life-cycle phase 5. Limited quantities of hardware, services, and software to support sys-
tem development and to transition the systems to an operating and maintenance provider
6. Establishment, staffing, operation, and management of the System De- velopment Center (SDC) to support the development of ISs by a phased approach using task orders
7. Contractor management and personnel requirements, and security pro- cedures
In a similar vein, the Federal Aviation Administration (FAA), in its procure- ment of technical assistance contract (TAG) services related to its advanced automation program (AAP) and automation program (ANA), has documented the summary of requirements set forth in Exhibit 3.2.
Exhibit 3.2: FAA Summary of Requirements for TAC Support [3.4]
a. The contractor shall support FAA’s Advanced Automation Program (AAP) and Automation Program (ANA) in an engineering and tech- nical assistance capacity. The contractor’s efforts shall complement, support, and extend those of the AAP/ANA engineering staff, which are responsible for the overall technical and contractual direction of the AAP and ANA programs.
b. The contractor shall provide assistance to the FAA in critical technical areas at key periods throughout the contract. A broad range of talents are required to address complex technical problems, for varying periods of time and under stringent response constraints. The contractor’s skills must have particular depth, breadth, and quality as follows: [as listed].
c. The contractor’s experience and performance must be at a level to pro- vide the highest quality of analytic expertise and, if required, to support the provision of expert testimony.
The two exhibits focus on project requirements. The Project Manager will normally accept these customer statements of requirements for integration into the project plan. Also note that they are relatively brief and differ from
system requirements when a large-scale system is being procured. If provided, the system requirements can be cited by reference in the program plan rather than being an integral part of the plan itself.
Other project requirements may also be stated in a procurement that may be regarded as subordinate requirements. These may be described as mini- mum position qualification requirements, or estimated staffing requirements, or even special contract requirements. For example, Exhibit 3.3 shows the estimated staffing requirements associated with a NASA procurement [3.5].
Exhibit 3.3: Illustrative Estimated Staffing Requirements
Labor Category Estimated Hours Required
1. Program Manager 100
2. Senior Instructor 300
3. Instructor 120
4. Senior Facilitator 100
5. Facilitator 80
6. Course Development Specialist 240
7. Administrative/Clerical 120
Total 1060
These subordinate requirements impact the staffing of the project and, of course, the estimated cost of the project, as described in later parts of the project plan. A list of other special contract requirements from this same NASA procurement follows:
1. Printing and duplicating 2. Task ordering procedure 3. Key personnel and facilities 4. Observance of legal holidays 5. Protection of information 6. Level of effort (cost) 7. Property administration 8. Contractor’s program manager
9. Special provisions regarding travel costs 10. Minimum position qualifications 11. Identification of contractor employees
12. Advance understanding: nonfee-bearing costs 13. General-purpose equipment
14. Contractor-acquired property: submission of vouchers
These subordinate requirements should only be cited by reference and not be included in detail in the requirements portion of the project plan. An alternative is to list them as an appendix to the plan.
3.3 TASK STATEMENTS, STATEMENT OF WORK (SOW),