Project Planning: A Project Management Process Area at Maturity Level 2

Purpose

The purpose of Project Planning (PP) is to establish and maintain plans that define project activities.

Introductory Notes

One of the keys to effectively managing a project is project planning. The Project Planning process area involves the following activities:

• Developing the project plan

• Interacting with relevant stakeholders appropriately

• Getting commitment to the plan

• Maintaining the plan

Planning begins with requirements that define the product and project.

Project planning is based on the acquisition strategy, which is a guide for directing and controlling the project and a framework for integrating activities essential to acquiring an operational product or service. The acquisition strategy outlines acquisition objectives and constraints, availability of assets and technologies, consideration of acquisition methods, potential supplier agreement types and terms, accommodation of end-user considerations, considerations of risk, and support for the project throughout the project lifecycle.

Planning includes estimating the attributes of work products and tasks, determining the resources needed, negotiating commitments, producing a schedule, and identifying and analyzing project risks. Iterating through these activities may be necessary to establish the project plan. The project plan provides the basis for performing and controlling project activities that address commitments with the project’s customer. (See the definition of “project” in the glossary.)

Project Planning involves the development and maintenance of plans for all acquirer processes, including plans required for effective acquirer-supplier interaction. Once the supplier agreement is signed and schedule, costs, and resources from the supplier are established, the acquirer takes the supplier estimations for the project into account at an appropriate level of detail in its project plan.

Project planning includes establishing and maintaining a plan for the orderly, smooth transition of the acquired product from a supplier to its use by the acquirer or its customers. In addition, if an existing product is to be replaced as part of the acquisition, the acquirer may be required to consider the disposal of the existing product as part of the planning for acquiring the new product. All transition activities are included in the project plan and provisions for accommodating such specialized requirements are also included.

All relevant stakeholders should be involved in the planning process from all lifecycle phases to ensure all technical and support activities are adequately addressed in project plans.

The project plan is usually revised as the project progresses to address changes in requirements and commitments, inaccurate estimates, corrective actions, and process changes. Specific practices describing both planning and replanning are contained in this process area.

Changes to the supplier agreement can also affect the project’s planning estimates, budget, schedules, risks, project work tasks, commitments, and resources.

The term “project plan” is used throughout this process area to refer to the overall plan for controlling the project. The project plan can be a stand-alone document or be distributed across multiple documents. In either case, a coherent picture of who does what should be included. Likewise, monitoring and control can be centralized or distributed, as long as at the project level a coherent picture of project status can be maintained.

Related Process Areas

Refer to the Acquisition Requirements Development process area for more information about developing and analyzing customer and contractual requirements.

Refer to the Acquisition Technical Management process area for more information about evaluating the supplier’s technical solution and managing selected interfaces of that solution.

Refer to the Solicitation and Supplier Agreement Development process area for more information about establishing supplier agreements.

Refer to the Measurement and Analysis process area for more information about specifying measures.

Refer to the Requirements Management process area for more information about managing requirements.

Refer to the Risk Management process area for more information about identifying and analyzing risks and mitigating risks.

Specific Practices by Goal

SG 1 Establish Estimates

Estimates of project planning parameters are established and maintained.

Project planning parameters include all information needed by the project to perform necessary planning, organizing, staffing, directing, coordinating, reporting, and budgeting.

The acquirer develops estimates for project work based on the acquisition strategy, including high-level estimates for the work to be done by suppliers. Initial estimates can be revised based on supplier estimates in response to the solicitation package.

Estimates of planning parameters should have a sound basis to instill confidence that plans based on these estimates are capable of supporting project objectives.

The acquisition strategy is a key factor when estimating the project.

Documentation of the estimating rationale and supporting data is needed for stakeholder review and commitment to the plan and for maintenance of the plan as the project progresses.

SP 1.1 Establish the Acquisition Strategy

Establish and maintain the acquisition strategy.

The acquisition strategy is the business and technical management framework for planning, executing, and managing agreements for a project. The acquisition strategy relates to the objectives for the acquisition, the constraints, availability of resources and technologies, consideration of acquisition methods, potential supplier agreement types, terms and conditions, accommodation of business considerations, considerations of risk, and support for the acquired product over its lifecycle. The acquisition strategy reflects the entire scope of the project. It encompasses the work to be performed by the acquirer and the supplier, or in some cases multiple suppliers, for the full lifecycle of the product.

The acquisition strategy results from a thorough understanding of both the acquisition project and the general acquisition environment. The acquirer accounts for the potential value or benefit of the acquisition in the light of potential risks, considers constraints, and takes into account experiences with different types of suppliers, agreements, and terms. A well-developed strategy minimizes the time and cost required to satisfy approved capability needs, and maximizes affordability throughout the project lifecycle.

The acquisition strategy is the basis for formulating solicitation packages, supplier agreements, and project plans. The strategy evolves over time and should continuously reflect the current status and desired end point of the project.

Example Work Products

1. Acquisition strategy

Subpractices

1. Identify the capabilities and objectives the acquisition is intended to satisfy or provide.

The capabilities describe what the organization intends to acquire. Typically, the capabilities included in the acquisition strategy highlight product characteristics driven by interoperability or families of products. The acquisition strategy also identifies dependencies on planned or existing capabilities of other projects or products.

Refer to the Acquisition Requirements Development process area for more information about developing and analyzing customer and contractual requirements.

The acquirer defines objectives in terms of cost, schedule, and performance. Performance related objectives are stated in terms of key process, product, and service level measures and technical performance measures as defined in requirements. These measures reflect customer expectations and threshold values representing acceptable limits for key quality attributes (addressing, e.g., responsiveness, safety, reliability, and maintainability) that, in the customer’s judgment, provide the needed capability. While the number and specificity of measures can change over the duration of an acquisition, the acquirer typically focuses on the minimum number of measures that, if thresholds are not met, will require a re-evaluation of the project.

The acquisition strategy establishes the milestone decision points and acquisition phases planned for the project. It prescribes the accomplishments for each phase and identifies the critical events affecting project management. Schedule parameters include, at a minimum, the projected dates for project initiation, other major decision points, and initial operational capability.

2. Identify the acquisition approach.

The acquirer defines the approach the project will use to achieve full capability, e.g., whether evolutionary or single step, and includes a brief rationale to justify the choice. When a project uses an evolutionary acquisition approach, the acquisition strategy describes the initial capability and how it will be funded, developed, tested, produced, and supported. The acquisition strategy previews similar planning for subsequent increments and identifies the approach to integrate or retrofit earlier increments with later increments.

3. Document business considerations.

Business considerations include the type of competition planned for all phases of the acquisition or an explanation of why competition is not practicable or not in the best interests of the acquirer. Also included are considerations for establishing or maintaining access to competitive suppliers for critical products or product components. Availability and suitability of commercial items and the extent to which interfaces for these items have broad market acceptance, standards, organization support, and stability are other business considerations. Also included are considerations for both international and domestic sources that can meet the required need as primary sources of supply consistent with organizational policies and regulations.

4. Identify major risks and which risks will be addressed jointly with the supplier.

Major acquisition risks, whether primarily managed by the acquirer or supplier, should be identified and assessed by the acquirer. The acquisition strategy identifies major risks, which risks are to be shared with the supplier, and which are retained by the acquirer.

Refer to the Risk Management process area for more information about establishing a risk management strategy.

5. Identify the preferred type of supplier.

The acquirer identifies standardized acquisition documents (e.g., standard supplier agreements), if any. The acquirer also determines the preferred type of supplier agreement (e.g., firm fixed-price; fixed-price incentive, firm target; cost plus incentive fee; cost plus award fee) and the reasons it is suitable, including considerations of risk and reasonable risk sharing by the acquirer and supplier.

The acquisition strategy explains the planned incentive structure for the acquisition and how it encourages the supplier to provide the product or service at or below the established cost objectives and satisfy the schedule and key measurement objectives. Considerations should be given to using incentives to reduce primary project risks. If more than one incentive is planned for a supplier agreement, the acquisition strategy explains how the incentives complement one other and do not interfere with one another. The acquisition strategy identifies unusual terms and conditions of the planned supplier agreement and all existing or contemplated deviations to an organization’s terms and conditions, if any.

6. Identify the product support strategy.

The acquirer develops a product support strategy for lifecycle sustainment and continuous improvement of product affordability, reliability, and supportability, while sustaining readiness. The support strategy addresses how the acquirer will maintain oversight of the fielded product and ensure satisfaction of support related quality attributes.

If support is going to be performed by an organization different from the supplier, a sufficient overlap period should be defined to ensure smooth transition.

The acquirer’s sustainment organization or supplier typically participates in the development of the product support strategy.

7. Review and obtain agreement with senior management on the acquisition strategy.

The development of the acquisition strategy for a project typically requires senior management sponsorship. Appropriate senior management should approve the acquisition strategy before initiating a project.

SP 1.2 Estimate the Scope of the Project

Establish a top-level work breakdown structure (WBS) to estimate the scope of the project.

The acquirer establishes the objectives of the project in the acquisition strategy. An initial set of requirements and project objectives form the basis for establishing the WBS or for selecting a standard WBS from organizational process assets. To ensure the full scope of the project is estimated, the WBS includes activities performed by the acquirer as well as milestones and deliverables for suppliers.

The acquisition strategy drives a key decision in this practice, specifically how much work, and what work, to give to a supplier. The acquirer develops a WBS that clearly identifies the project work performed by the acquirer and the project work performed by the supplier. The supplier work identified in the WBS becomes the foundation for the statement of work defined in the Solicitation and Supplier Agreement Development process area. The WBS identifies deliverables from the supplier and work products developed by the acquirer.

The WBS evolves with the project. A top-level WBS can serve to structure initial estimating. The development of a WBS divides the overall project into an interconnected set of manageable components.

Typically, the WBS is a product, work product, or task oriented structure that provides a scheme for identifying and organizing the logical units of work to be managed, which are called “work packages.” The WBS provides a reference and organizational mechanism for assigning effort, schedule, and responsibility and is used as the underlying framework to plan, organize, and control the work done on the project.

Some projects use the term “contract WBS” to refer to the portion of the WBS placed under contract (possibly the entire WBS). Not all projects have a contract WBS (e.g., internally funded development).

Example Work Products

1. Task descriptions

2. Work package descriptions

3. WBS

Subpractices

1. Develop a WBS based on the product architecture.

The WBS provides a scheme for organizing the project’s work. The WBS should permit the identification of the following items:

• Risks and their mitigation tasks

• Tasks for deliverables and supporting activities

• Tasks for skill and knowledge acquisition

• Tasks for the development of needed support plans, such as configuration management, quality assurance, and verification plans

• Tasks for the integration and management of nondevelopmental items

2. Define the work packages in sufficient detail so that estimates of project tasks, responsibilities, and schedule can be specified.

The top-level WBS is intended to help gauge the project work effort for tasks and organizational roles and responsibilities. The amount of detail in the WBS at this level helps in developing realistic schedules, thereby minimizing the need for management reserve.

3. Identify products and product components to be externally acquired.

4. Identify work products to be reused.

SP 1.3 Establish Estimates of Work Product and Task Attributes

Establish and maintain estimates of work product and task attributes.

Size is the primary input to many models used to estimate effort, cost, and schedule. Models can also be based on other attributes such as service level, connectivity, complexity, availability, and structure.

Estimation methods include using historical acquirer and supplier data and standard estimating models to compare projects of similar complexity. Where historical size data are not available, develop an estimate based on the understanding of the design of similar products.

Estimation models can be built based on historical data as part of organizational process performance, and estimates for any project can be validated using these models.

Refer to the Organizational Process Performance process area for more information about establishing process performance models.

The estimates should be consistent with project requirements to determine the project’s effort, cost, and schedule. A relative level of difficulty or complexity should be assigned for each size attribute.

Example Work Products

1. Size and complexity of tasks and work products

2. Estimating models

3. Attribute estimates

4. Technical approach

Subpractices

1. Determine the technical approach for the project.

The technical approach defines a top-level strategy for development of the product. It includes decisions on architectural features, such as distributed or client/server; state-of-the-art or established technologies to be applied, such as robotics, composite materials, or artificial intelligence; and the functionality and quality attributes expected in the final products, such as safety, security, and ergonomics.

The technical approach provides a basis for interoperability and supportability of the technical solution developed by the supplier. The technical approach is often developed as part of and included in the acquisition strategy.

2. Use appropriate methods to determine the attributes of the work products and tasks to be used to estimate resource requirements.

Methods for determining size and complexity should be based on validated models or historical data.

The methods for determining attributes evolve as the understanding of the relationship of product characteristics to attributes increases.

3. Estimate the attributes of work products and tasks.

SP 1.4 Define Project Lifecycle Phases

Define project lifecycle phases on which to scope the planning effort.

The determination of a project’s lifecycle phases provides for planned periods of evaluation and decision making. These periods are normally defined to support logical decision points at which the appropriateness of continued reliance on the project plan and strategy is determined and significant commitments are made concerning resources. Such points provide planned events at which project course corrections and determinations of future scope and cost can be made.

Understanding the project lifecycle is crucial in determining the scope of the planning effort and the timing of initial planning, as well as the timing and criteria (critical milestones) for replanning.

Depending on the nature of the project, explicit phases for “project startup” and “project close-out” can be included in the lifecycle.

Project lifecycle phases should be defined depending on the scope of requirements, estimates for project resources, and the nature of the project.

The acquirer includes the entire project lifecycle (i.e., from end user needs through initial and subsequent upgrades) when planning lifecycle phases and refines the acquisition strategy as appropriate. The acquirer considers all supplier agreements in the context of the acquisition so that an integrated approach results. A complex project can involve managing multiple supplier agreements simultaneously or in sequence. In such cases, any acquisition lifecycle can end during any phase of the project lifecycle. Depending on the acquisition strategy, there can be intermediate phases for the creation of prototypes, increments of capability, or spiral model cycles.

Refer to the Establish Lifecycle Model Descriptions specific practice in the Organizational Process Definition process area for more information about acquisition lifecycles.

During establishment of the supplier agreement, the acquirer works with the supplier to understand supplier lifecycle models and processes, especially those models and processes that interact directly with acquirer processes. Agreement on the lifecycle models and processes to be used during the project enables seamless interactions between supplier and acquirer, resulting in a successful acquirer-supplier relationship.

Example Work Products

1. Project lifecycle phases

SP 1.5 Estimate Effort and Cost

Estimate the project’s effort and cost for work products and tasks based on estimation rationale.

Estimates of effort and cost are generally based on results of analysis using models or historical data applied to size, activities, and other planning parameters. Confidence in these estimates is based on rationale for the selected model and the nature of the data. There can be occasions when available historical data do not apply, such as when efforts are unprecedented or when the type of task does not fit available models. For example, an effort can be considered unprecedented if the organization has no experience with such a product or task.

Unprecedented efforts are more risky, require more research to develop reasonable bases of estimate, and require more management reserve. The uniqueness of the project should be documented when using these models to ensure a common understanding of any assumptions made in the initial planning phases.

Estimates address all processes and activities performed by the project for the project lifecycle, including an estimate of effort and cost for supplier work. The project estimate includes detailed estimates for activities performed by the acquirer and its stakeholders. The acquirer should include members of their technical community (e.g., systems, hardware, software engineers) to ensure all technical considerations have been accounted for in the estimates. As the project evolves, these estimates can be revised based on changed conditions (e.g., new circumstances encountered during execution of the supplier agreement).

In addition to creating an estimate for the project work products, the acquirer is encouraged to have its estimate and WBS reviewed by individuals external to the project to ensure that the project estimation and WBS can be validated.

Example Work Products

1. Estimation rationale

2. Project effort estimates

3. Project cost estimates

Subpractices

1. Collect models or historical data to be used to transform the attributes of work products and tasks into estimates of labor hours and costs.

Effort estimation at the work product and task level needs to be established for acquirer work. Effort estimation for supplier deliverables and processes should be established as well.

Many parametric models have been developed to help estimate cost and schedule. The use of these models as the sole source of estimation is not recommended because these models are based on historical project data that may or may not be pertinent to the project. Multiple models and methods can be used to ensure a high level of confidence in the estimate.

Historical data should include the cost, effort, and schedule data from previously executed projects and appropriate scaling data to account for differing sizes and complexity.

2. Include supporting infrastructure needs when estimating effort and cost.

The supporting infrastructure includes resources needed from a development and sustainment perspective for the product.

Consider the infrastructure resource needs in the development environment, the test environment, the production environment, the operational environment, or any appropriate combination of these environments when estimating effort and cost.

3. Estimate effort and cost using models, historical data, or a combination of both.

The amount of supplier work for a project largely determines the amount of acquirer work required to manage the project and the supplier. Effort for the acquirer includes (1) effort associated with defining the scope of the project; (2) effort associated with the development of the solicitation and supplier agreement; agreement and technical management; project planning, monitoring, and control; acquisition requirements development, verification, and validation; configuration management; measurement and analysis; process and product quality assurance; requirements management; and risk management; (3) operating and maintenance effort associated with the sustainment of the solution; and (4) disposal effort.

SG 2 Develop a Project Plan

A project plan is established and maintained as the basis for managing the project.

A project plan is a formal, approved document used to manage and control the execution of the project. It is based on project requirements and established estimates.

The project plan should consider all phases of the project lifecycle. Project planning should ensure that all plans affecting the project are consistent with the overall project plan.

SP 2.1 Establish the Budget and Schedule

Establish and maintain the project’s budget and schedule.

The project’s budget and schedule are based on developed estimates and ensure that budget allocation, task complexity, and task dependencies are appropriately addressed.

The project’s budget and schedule (including the lifecycle related activities of the acquirer), the supplier’s efforts, and efforts of supporting organizations and other stakeholders (including any supplier that supports the acquirer) are established, tracked, and maintained for the duration of the project. In addition to creating a schedule for project work products, the acquirer should have the schedule reviewed by individuals external to the project to ensure that the project schedule can be validated.

Event driven, resource-limited schedules have proven to be effective in dealing with project risk. Identifying accomplishments to be demonstrated before initiation of an event provides some flexibility in the timing of the event, a common understanding of what is expected, a better vision of the state of the project, and a more accurate status of the project’s tasks.

Example Work Products

1. Project schedules

2. Schedule dependencies

3. Project budget

Subpractices

1. Identify major milestones.

Milestones are pre-planned events or points in time at which a thorough review of status is conducted to understand how well stakeholder requirements are being met. (If the project includes a developmental milestone, then the review is conducted to ensure that the assumptions and requirements associated with that milestone are being met.) Milestones can be associated with the overall project or a particular service type or instance. Milestones can thus be event based or calendar based. If calendar based, once agreed, milestone dates are often difficult to change.

2. Identify schedule assumptions.

When schedules are initially developed, it is common to make assumptions about the duration of certain activities. These assumptions are frequently made on items for which little if any estimation data are available. Identifying these assumptions provides insight into the level of confidence (i.e., uncertainties) in the overall schedule.

3. Identify constraints.

Factors that limit the flexibility of management options should be identified as early as possible. The examination of the attributes of work products and tasks often bring these issues to the surface. Such attributes can include task duration, resources, inputs, and outputs.

Since key characteristics of pre-qualified or other potential suppliers are elements of project success, the acquirer considers these characteristics (e.g., technical and financial capability, management and delivery processes, production capacity, business type and size) in identifying constraints for the project.

4. Identify task dependencies.

Frequently, the tasks for a project or service can be accomplished in some ordered sequence that minimizes the duration. This sequencing involves the identification of predecessor and successor tasks to determine optimal ordering.

5. Establish and maintain the budget and schedule.

6. Establish corrective action criteria.

Criteria are established for determining what constitutes a significant deviation from the project plan. A basis for gauging issues and problems is necessary to determine when corrective action should be taken. Corrective actions can lead to replanning, which may include revising the original plan, establishing new agreements, or including mitigation activities in the current plan. The project plan defines when (e.g., under what circumstances, with what frequency) the criteria will be applied and by whom.

SP 2.2 Identify Project Risks

Identify and analyze project risks.

Refer to the Monitor Project Risks specific practice in the Project Monitoring and Control process area for more information about risk monitoring activities.

Refer to the Risk Management process area for more information about identifying potential problems before they occur so that risk handling activities can be planned and invoked as needed across the life of the product or project to mitigate adverse impacts on achieving objectives.

Risks are identified or discovered and analyzed to support project planning. This specific practice should be extended to all plans that affect the project to ensure that appropriate interfacing is taking place among all relevant stakeholders on identified risks.

Risks are identified from multiple perspectives (e.g., acquisition, technical, management, operational, supplier agreement, industry, support, end user) to ensure all project risks are considered comprehensively in planning activities. Applicable regulatory and statutory requirements with respect to safety and security should be considered while identifying risks.

The acquisition strategy and the risks identified in other project planning activities form the basis for some of the criteria used in evaluation practices in the Solicitation and Supplier Agreement Development process area. As the project evolves, risks can be revised based on changed conditions.

Example Work Products

1. Identified risks

2. Risk impacts and probability of occurrence

3. Risk priorities

Subpractices

1. Identify risks.

The identification of risks involves the identification of potential issues, hazards, threats, vulnerabilities, and so on that could negatively affect work efforts and plans. Risks should be identified and described understandably before they can be analyzed and managed properly. When identifying risks, it is a good idea to use a standard method for defining risks. Risk identification and analysis tools can be used to help identify possible problems.

Numerous risks are associated with acquiring products through suppliers (e.g., the stability of the supplier, the ability to maintain sufficient insight into the progress of their work, the supplier’s capability to meet product requirements, the skills and availability of supplier resources to meet commitments).

The process, product, and service level measures and associated thresholds should be analyzed to identify instances where thresholds are at risk of not being met. These project measures are key indicators of project risk.

2. Document risks.

3. Review and obtain agreement with relevant stakeholders on the completeness and correctness of documented risks.

4. Revise risks as appropriate.

SP 2.3 Plan Data Management

Plan for the management of project data.

Data are forms of documentation required to support a project in all of its areas (e.g., administration, engineering, configuration management, finance, logistics, quality, safety, manufacturing, procurement). The data can take any form (e.g., reports, manuals, notebooks, charts, drawings, specifications, files, correspondence). The data can exist in any medium (e.g., printed or drawn on various materials, photographs, electronic, multimedia).

Data can be deliverable (e.g., items identified by a project’s contract data requirements) or data can be nondeliverable (e.g., informal data, trade studies, analyses, internal meeting minutes, internal design review documentation, lessons learned, action items). Distribution can take many forms, including electronic transmission.

Data requirements for the project should be established for both data items to be created and their content and form, based on a common or standard set of data requirements. Uniform content and format requirements for data items facilitate understanding of data content and help with consistent management of data resources.

The reason for collecting each document should be clear. This task includes the analysis and verification of project deliverables and nondeliverables, data requirements, and customer supplied data. Often, data are collected with no clear understanding of how they will be used. Data are costly and should be collected only when needed.

Project data include both acquirer and supplier created data. The acquirer identifies the minimal data required to cost-effectively operate, maintain, and improve the acquired product and to foster source-of-support competition throughout the product’s lifecycle in the acquirer’s intended environment. Data should be available in a format that is compatible with the intended end user’s environment and a quality assurance program should be implemented to guarantee the accuracy and completeness of data.

The acquirer considers how data will be shared between acquirer and supplier as well as across relevant stakeholders. In many cases, leaving acquirer data in the physical possession of the supplier and having access to supplier data is the preferred solution. In addition to data access, the requirement for acquirer use, reproduction, manipulation, alteration, or transfer of possession of data should be part of the data management plan. The supplier agreement specifies appropriate acquirer rights to the data acquired, in addition to requirements for delivery or access.

Data, when delivered to the acquirer, are formatted according to accepted data standards to ensure their usability by the acquirer. Planning for managing data, including during transition to operations and support, is addressed as part of project planning to avoid unexpected costs to procure, reformat, and deliver data. Plans for managing data in project teams and the infrastructure required to manage data between the supplier, operational users, and other relevant stakeholders are included.

Project data and plans requiring version control or more stringent levels of configuration control are determined and mechanisms established to ensure project data are controlled. The implications of controlling access to classified and sensitive data (e.g., proprietary, export controlled, source selection sensitive) and other access controlled data also should be considered.

Example Work Products

1. Data management plan

2. Master list of managed data

3. Data content and format description

4. Lists of data requirements for acquirers and suppliers

5. Privacy requirements

6. Security requirements

7. Security procedures

8. Mechanisms for data retrieval, reproduction, and distribution

9. Schedule for the collection of project data

10. List of project data to be collected

Subpractices

1. Establish requirements and procedures to ensure privacy and the security of data.

Not everyone will have the need or clearance necessary to access project data. Procedures should be established to identify who has access to which data as well as when they have access to which data. Security and access control are critical when the acquirer provides data access to the supplier. Security and access control includes access lists of authorized supplier staff and non-disclosure agreements between the acquirer and supplier.

2. Establish a mechanism to archive data and to access archived data.

Accessed information should be in an understandable form (e.g., electronic or computer output from a database) or represented as originally generated.

The data management plan is ideally supported by an integrated data system that meets the needs of both initial acquisition and support communities. Integrating acquisition and sustainment data systems into a total lifecycle integrated data environment provides the capability needed to plan effectively for sustainment and to facilitate technology insertion for affordability improvements during re-procurement and post-production support, while ensuring that acquisition planners have accurate information about total lifecycle costs.

3. Determine the project data to be identified, collected, and distributed.

4. Determine the requirements for providing access to and distribution of data to relevant stakeholders.

A review of other elements of the project plan can help to determine who requires access to or receipt of project data as well as which data are involved.

5. Decide which project data and plans require version control or other levels of configuration control and establish mechanisms to ensure project data are controlled.

SP 2.4 Plan the Project’s Resources

Plan for resources to perform the project.

Defining project resources (e.g., labor, equipment, materials, methods) and quantities needed to perform project activities builds on initial estimates and provides additional information that can be applied to expand the WBS used to manage the project.

The top-level WBS developed earlier as an estimation mechanism is typically expanded by decomposing these top levels into work packages that represent single work units that can be separately assigned, performed, and tracked. This subdivision is done to distribute management responsibility and provide better management control.

Each work package in the WBS should be assigned a unique identifier (e.g., number) to permit tracking. A WBS can be based on requirements, activities, work products, services, or a combination of these items. A dictionary that describes the work for each work package in the WBS should accompany the work breakdown structure.

The resource plan should include planning for staff with appropriate training and experience to evaluate supplier proposals and participate in negotiations with suppliers. The resource plan identifies the project resources expected from the supplier, including critical facilities or equipment needed to support the work. The resource plan can be revised based on the supplier agreement or changes in conditions during project execution.

Example Work Products

1. Work packages

2. WBS task dictionary

3. Staffing requirements based on project size and scope

4. Critical facilities and equipment list

5. Process and workflow definitions and diagrams

6. Project administration requirements list

7. Status reports

Subpractices

1. Determine process requirements.

The processes used to manage a project are identified, defined, and coordinated with all relevant stakeholders to ensure efficient operations during project execution.

The acquirer determines how its processes interact with supplier processes to enable seamless execution of the project and successful acquirer-supplier relationships. Considerations include the use of a common process across multiple suppliers and the acquirer or the use of unique but compatible processes. At least, processes should be compatible across interfaces.

2. Determine communication requirements.

These requirements address the kinds of mechanisms to be used for communicating with customers, end users, project staff, and other relevant stakeholders.

3. Determine staffing requirements.

The staffing of a project depends on the decomposition of project requirements into tasks, roles, and responsibilities for accomplishing project requirements as laid out in the work packages of the WBS.

Staffing requirements should consider the knowledge and skills required for each identified position as defined in the Plan Needed Knowledge and Skills specific practice.

The acquirer determines its staffing requirements, including staffing for solicitation and supplier agreement management activities and staffing expected by the supplier to complete its portion of the work as defined in the WBS.

4. Determine facility, equipment, and component requirements.

Most projects are unique in some way and require a set of unique assets to accomplish project objectives. The determination and acquisition of these assets in a timely manner are crucial to project success.

It is best to identify lead-time items early to determine how they will be addressed. Even when required assets are not unique, compiling a list of all facilities, equipment, and parts (e.g., number of computers for the staff working on the project, software applications, office space) provides insight into aspects of the scope of an effort that are often overlooked.

The acquirer considers what it may need to provide for acceptance of supplier deliverables and for transition and support of the acquired product.

The acquirer should also identify and ensure that facilities or equipment to be provided to the supplier for project work are accounted for in the project plan.

5. Determine other continuing resource requirements.

Beyond determining processes, reporting templates, staffing, facilities, and equipment, there may be a continuing need for other types of resources to effectively carry out project activities, including the following:

• Access to intellectual property

• Access to transportation (for people and equipment)

• Consumables (e.g., electricity, office supplies)

The requirements for such resources are derived from the requirements found in (existing and future) agreements (e.g., customer agreements, service agreements, supplier agreements), the project’s strategic approach, and the need to manage and maintain the project’s operations for a period of time.

SP 2.5 Plan Needed Knowledge and Skills

Plan for knowledge and skills needed to perform the project.

Refer to the Organizational Training process area for more information about developing skills and knowledge of people so they can perform their roles effectively and efficiently.

Knowledge delivery to projects involves training project staff and acquiring knowledge from outside sources.

Staffing requirements are dependent on the knowledge and skills available to support the execution of the project.

The acquirer plans for knowledge and skills required by the project team to perform their tasks. Knowledge and skill requirements can be derived from project risk.

Orientation and training in acquirer processes and the domain knowledge required to execute the project are also required. The acquirer also plans for knowledge and skills needed from the supplier.

Planning for needed knowledge and skills includes ensuring that appropriate training is planned for staff involved in receiving, storing, using, and supporting the transitioned product. Also included is ensuring that costs and funding sources to pay for training are available and lead times to obtain the funding are identified.

Example Work Products

1. Inventory of skill needs

2. Staffing and new hire plans

3. Databases (e.g., skills, training)

4. Training plans

Subpractices

1. Identify the knowledge and skills needed to perform the project.

2. Assess the knowledge and skills available.

3. Select mechanisms for providing needed knowledge and skills.

The choice of in-house training or outsourced training for needed knowledge and skills is determined by the availability of training expertise, the project’s schedule, and business objectives.

4. Incorporate selected mechanisms into the project plan.

SP 2.6 Plan Stakeholder Involvement

Plan the involvement of identified stakeholders.

Stakeholders are identified from all phases of the project lifecycle by identifying the people and functions that should be represented in the project and describing their relevance and the degree of interaction for project activities. A two-dimensional matrix with stakeholders along one axis and project activities along the other axis is a convenient format for accomplishing this identification. Relevance of the stakeholder to the activity in a particular project phase and the amount of interaction expected would be shown at the intersection of the project phase activity axis and the stakeholder axis.

Stakeholders can include operational users and project participants as well as potential suppliers. When acquiring products that must interoperate with other products, the acquirer plans the involvement of relevant stakeholders from other projects or communities to ensure the delivered product can perform as required in its intended environment. Such planning often includes steps for establishing and maintaining supplier agreements with these stakeholders (e.g., interagency and intercompany agreements, memoranda of understanding, memoranda of agreement).

For inputs of stakeholders to be useful, careful selection of relevant stakeholders is necessary. For each major activity, identify stakeholders who are affected by the activity and those who have expertise that is needed to conduct the activity. This list of relevant stakeholders will probably change as the project moves through phases of the project lifecycle. It is important, however, to ensure that relevant stakeholders in the latter phases of the lifecycle have early input to requirements and design decisions that affect them.

Sometimes the supplier will be using an Agile method. The phrase “Agile method” is shorthand for any development or management method that adheres to the Manifesto for Agile Development [Beck 2001]. More guidance on the use of Agile methods can be found in CMMI-DEV Section 5.0 Interpreting CMMI When Using Agile Approaches and in the SEI technical notes CMMI or Agile: Why Not Embrace Both! [Glazer 2008] and Considerations for Using Agile in DoD Acquisition [Lapham 2010].

When the supplier is using an Agile method, the risk is shared with the acquirer and end users for the product being developed. To be effective, the end user or their proxy, acquirer, and supplier will need to operate as a team that crosses organizational and contractual boundaries. The results of the acquirer’s stakeholder involvement planning can be incorporated in a team charter that defines roles and responsibilities for the three parties. For example, the team charter can specify who has responsibility for making changes to project scope and requirements and how such changes will be made and managed.

Implementing this specific practice relies on shared or exchanged information with the previous Plan Needed Knowledge and Skills specific practice.

Example Work Products

1. Stakeholder involvement plan

SP 2.7 Plan Transition to Operations and Support

Plan transition to operations and support.

Planning for transition should be considered part of initial planning for the project.

Transition and support plans include the approach for introducing and maintaining readiness, sustainment, and the operational capability of the products delivered by the supplier. Plans for transition to operations and support include assignment of responsibility for transition to operations and support of the product, as well as all activities needed to manage the transition and to support the product in its intended environment (e.g., definition of transition readiness criteria agreed to by relevant stakeholders). These plans can include reasonable accommodations for potential risks and for the evolution of acquired products and their eventual removal from operational use.

If support is to be provided by an organization different from the supplier, a sufficient overlap period should be included in the plan.

Refer to the Agreement Management process area for more information about accepting the acquired product.

Refer to the Acquisition Technical Management process area for more information about evaluating technical solutions.

Example Work Products

1. Transition to operations and support plans

Subpractices

1. Determine the transition scope and objectives.

2. Determine transition requirements and criteria.

3. Determine transition responsibilities and resources to include post-transition support enhancements and lifecycle considerations.

4. Determine configuration management needs of the transition.

5. Determine training needs for operations and support.

SP 2.8 Establish the Project Plan

Establish and maintain the overall project plan.

A documented plan that addresses all relevant planning items is necessary to achieve the mutual understanding and commitment of individuals, groups, and organizations that execute or support the plans.

The plan generated for the project defines all aspects of the effort, tying together the following in a logical manner:

• Project lifecycle considerations

• Project tasks

• Budgets and schedules

• Milestones

• Data management

• Risk identification

• Resource and skill requirements

• Stakeholder identification and interaction

• Infrastructure considerations

Infrastructure considerations include responsibility and authority relationships for project staff, management, and support organizations.

The project plan can include multiple plans such as staffing plans, stakeholder involvement plans, measurement and analysis plans, monitoring and control plans, solicitation plans, agreement management plans, risk mitigation plans, transition plans, quality assurance plans, and configuration management plans. Regardless of form, the plan or plans should address the acquisition strategy as well as the cradle-to-grave considerations for the project and product to be acquired.

Example Work Products

1. Overall project plan

SG 3 Obtain Commitment to the Plan

Commitments to the project plan are established and maintained.

To be effective, plans require commitment by those who are responsible for implementing and supporting the plan.

Refer to the Solicitation and Supplier Agreement Development process area for more information about establishing the supplier agreement.

SP 3.1 Review Plans That Affect the Project

Review all plans that affect the project to understand project commitments.

Plans developed in other process areas typically contain information similar to that called for in the overall project plan. These plans can provide additional detailed guidance and should be compatible with and support the overall project plan to indicate who has the authority, responsibility, accountability, and control. All plans that affect the project should be reviewed to ensure they contain a common understanding of the scope, objectives, roles, and relationships that are required for the project to be successful. Many of these plans are described by the Plan the Process generic practice.

The project can have a hierarchy of plans (e.g., risk mitigation plans, transition plans, quality assurance plans, configuration management plans). In addition, stakeholder plans (e.g., operational, test, support, supplier plans) should be reviewed to ensure consistency among all project participants. Acquirer review of plans should include reviewing cross-supplier dependencies.

Example Work Products

1. Record of the reviews of plans that affect the project

SP 3.2 Reconcile Work and Resource Levels

Adjust the project plan to reconcile available and estimated resources.

To establish a project that is feasible, obtain commitment from relevant stakeholders and reconcile differences between estimates and available resources. Reconciliation is typically accomplished by modifying or deferring requirements, negotiating more resources, finding ways to increase productivity, outsourcing, adjusting the staff skill mix, or revising all plans that affect the project or its schedules.

During supplier selection and negotiation of the supplier agreement, the acquirer reconciles overall project work and resource levels based on proposals from the supplier. Following completion of the supplier agreement, the acquirer incorporates supplier plans at an appropriate level of detail into the project plan to support the alignment of plans. For example, an acquirer can incorporate major supplier milestones, deliverables, and reviews.

Example Work Products

1. Revised methods and corresponding estimating parameters (e.g., better tools, the use of off-the-shelf components)

2. Renegotiated budgets

3. Revised schedules

4. Revised requirements list

5. Renegotiated stakeholder agreements

SP 3.3 Obtain Plan Commitment

Obtain commitment from relevant stakeholders responsible for performing and supporting plan execution.

Obtaining commitment involves interaction among all relevant stakeholders, both internal and external to the project. The individual or group making a commitment should have confidence that the work can be performed within cost, schedule, and performance constraints. Often, a provisional commitment is adequate to allow the effort to begin and to permit research to be performed to increase confidence to the appropriate level needed to obtain a full commitment.

Example Work Products

1. Documented requests for commitments

2. Documented commitments

Subpractices

1. Identify needed support and negotiate commitments with relevant stakeholders.

The WBS can be used as a checklist for ensuring that commitments are obtained for all tasks.

The plan for stakeholder interaction should identify all parties from whom commitment should be obtained.

2. Document all organizational commitments, both full and provisional, ensuring the appropriate level of signatories.

Commitments should be documented to ensure a consistent mutual understanding and for project tracking and maintenance. Provisional commitments should be accompanied by a description of risks associated with the relationship.

3. Review internal commitments with senior management as appropriate.

4. Review external commitments with senior management as appropriate.

Management can have the necessary insight and authority to reduce risks associated with external commitments.

5. Identify commitments regarding interfaces between project elements and other projects and organizational units so that these commitments can be monitored.

Well-defined interface specifications form the basis for commitments.