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.

Typical 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 summary 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 determining capabilities and customer requirements.

   The acquirer defines objectives in terms of cost, schedule, and 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 that, in the customer’s judgment, provide the needed capability. While the number and specificity of measures may 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 reevaluation 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.

   Examples of cost parameters include the following:

   • Research, development, test, and evaluation costs

   • Acquisition costs

   • Acquisition-related operations, support, and disposal costs

   • Total product quantity (to include both fully configured development and production units)

2. Identify the acquisition approach.

   The acquirer defines the approach the project will use to achieve full capability—either 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.

   Tip

   The type of acquisition varies according to the nature of products and services that are available to satisfy the project’s needs and requirements (including commercial-off-the-shelf [COTS] products).

   Examples of additional considerations for the acquisition approach include the following:

   • Actions a project team can take on its own if the acquiring organization has an acquisition, contracting, or purchasing department

   • Who will prepare independent estimates and if these estimates are needed as evaluation criteria

   • Managing multiple suppliers

   • Anticipated lead times from potential suppliers to acquire items

   Tip

   The acquisition approach and the supplier’s development approach are complementary but not always the same. For example, the acquisition approach can be single-step whereas the supplier may use an incremental approach in developing the solution.

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.

   Other examples of business considerations for an acquisition strategy include the following:

   • Product and technology areas critical to satisfying or providing the desired capabilities

   • Data rights

   • Socio-economic constraints

   • Safety and health issues

   • Security issues (physical and information technology)

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 and maintaining a risk management strategy.

5. Identify the preferred supplier agreement type.

   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; or 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.

   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 must approve the acquisition strategy before initiating a 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 the organization’s 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. Initially, 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-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).

Typical Work Products

1. Task descriptions
2. Work package descriptions
3. WBS

Subpractices

1. Develop a WBS based on the product architecture.

   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

   Hint

   Use the WBS to help you define the product architecture.

   You may select different suppliers to deliver different architectural components. Make sure you account for the integration activities if this is the case.

2. Identify the work packages in sufficient detail to specify estimates of project tasks, responsibilities, and schedule.

   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.

   Tip

   The level of detail often depends on the level and completeness of the requirements. Often, the work packages and estimates evolve as the requirements evolve.

3. Identify products and product components to be externally acquired.
4. Identify work products to be reused.

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. The models can also be based on inputs such as connectivity, complexity, 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 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.

Typical Work Products

1. Technical approach
2. Size and complexity of tasks and work products
3. Estimating models
4. Attribute estimates

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 breadth of the functionality 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.

   X-Ref

   Mature organizations maintain historical data to help projects establish reasonable estimates (see MA SP 1.5 and IPM SP 1.2).

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.

   Examples of attributes include the following:

   • Maturity of the technology specified in the technical solution

   • Amount and complexity of the work potentially assigned to suppliers

   • Number of locations where the product is to be installed

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

   Examples of current methods include the following:

   • Number of logic gates for integrated circuit design

   • Lines of code or function points for software

   • Number and complexity of requirements for systems engineering

   • Number of square feet for standard-specified residential homes

3. Estimate the attributes of work products and tasks.

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 significant commitments are made concerning resources and technical approach. Such points provide planned events at which project course corrections and determinations of future scope and cost can be made.

Project lifecycle phases must 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 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 may 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 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.

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.

Typical Work Products

1. Project lifecycle phases

Estimate the project’s effort and cost for work products and tasks.

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 may be occasions when available historical data does not apply, such as when efforts are unprecedented or when the type of task does not fit available models. An effort is unprecedented (to some degree) if a similar product or component has never been built. An effort may also be unprecedented if the development group has never built such a product or component.

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

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, and software engineers) to ensure all technical considerations have been accounted for in the estimates. As the project evolves, these estimates may 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 independently reviewed by individuals external to the project to ensure that the project estimation and WBS can be validated.

Typical 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 must be established as well.

   Hint

   If you are using only one parametric model, make sure it is calibrated to your project’s characteristics.

   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 your project. Multiple models and methods can be used to ensure a high level of confidence in the estimate.

   Tip

   Scaling can be reliable when applied from experiences similar to the one at hand. However, increased complexity usually adds more interactions with other acquisition projects or legacy capabilities requiring additional coordination effort.

   Historical data 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.

   Examples of supporting infrastructure typically provided by the supplier include the following:

   • Critical computing resources in the host and testing environment (e.g., memory, disk, and network capability)

   • Test equipment

3. Estimate effort and cost using models and historical data.

   Effort and cost inputs used for estimating typically include the following:

   • Judgmental estimates provided by an expert or group of experts (e.g., Delphi Method)

   • Estimates for the development of requirements

   • Risks, including the extent to which the effort is unprecedented

   • Critical competencies and roles needed to perform the work

   • The WBS

   • Costs of acquired work products

   • Selected project lifecycle model and processes

   • Lifecycle cost estimates

   • Skill levels of managers and staff needed to perform the work

   • Knowledge, skill, and training needs

   • Facilities needed (e.g., office and meeting space and workstations)

   • Travel required

   • Level of security required for tasks, work products, hardware, software, personnel, and the work environment

   • Service level agreements for call centers and warranty work

   • Direct labor and overhead

   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.

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 those 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 independently 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.

Typical Work Products

1. Project schedules
2. Schedule dependencies
3. Project budget

Subpractices

1. Identify major milestones.

   Milestones are often imposed to ensure completion of certain deliverables by the milestone. Milestones can be event-based or calendar-based. If calendar-based, once milestone dates have been agreed on, it is often difficult to change them.

   X-Ref

   Defining event-based milestones and monitoring their completion (PMC SP 1.1 subpractice 1) provides visibility into the project’s progress.

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 is 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 must be identified as early as possible. The examination of the attributes of work products and tasks often brings these issues to the surface. Such attributes can include task duration, resources, inputs, and outputs. Since key characteristics of prequalified 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, and business type and size) in identifying constraints for the project.

4. Identify task dependencies.

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

   Examples of tools that can help determine optimal ordering of task activities include the following:

   • Critical Path Method (CPM)

   • Program Evaluation and Review Technique (PERT)

   • Resource-limited scheduling

   • Critical chain method

5. Define the budget and schedule.

   An example of a system used for documenting the costs and schedule of a project is an EVMS [GEIA 748 2002].

   Establishing and maintaining the project’s budget and schedule typically includes the following:

   • Defining the committed or expected availability of resources and facilities

   • Determining the time phasing of activities

   • Determining a breakout of subordinate schedules

   • Defining dependencies among activities (predecessor or successor relationships)

   • Defining schedule activities and milestones to support accuracy in progress measurement

   • Identifying milestones for the delivery of products to the customer

   • Defining activities of appropriate duration

   • Defining milestones of appropriate time separation

   • Defining a management reserve based on the confidence level in meeting the schedule and budget

   • Using appropriate historical data to verify the schedule

   • Defining incremental funding requirements

   • Documenting project assumptions and rationale

   • Determining the approach to incorporating supplier schedules at an appropriate level of detail

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 may require replanning, which may include revising the original plan, establishing new agreements, or including mitigation activities in the current plan.

   Hint

   Establish corrective action criteria early in the project to ensure that issues are addressed appropriately and consistently.

   Criteria for corrective action are based on key objectives defined in the acquisition strategy using process, product, and service level measures. The measures represent key stakeholder needs and threshold values of acceptable limits that, in the stakeholder’s judgment, will provide the needed capability. All measures that represent key stakeholder needs and other measures for monitoring the supplier are defined in the Statement of Work (SOW), along with their associated minimum allowed performance levels. These measures are used to identify issues and problems and gauge whether corrective actions should be taken. The plan should define how these measures will be assessed and evaluated.

Identify and analyze project risks.

Refer to the Risk Management process area for more information about risk management activities.

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

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, and end user) to ensure all project risks are considered comprehensively in planning activities. Applicable regulatory and statutory requirements with respect to safety and security must 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 may be revised based on changed conditions.

Typical 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 must be identified and described in an understandable way before they can be analyzed. 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.

   Examples of risk identification and analysis tools include the following:

   • Risk taxonomies

   • Risk assessments

   • Checklists

   • Structured interviews

   • Brainstorming

   • Performance models

   • Cost models

   • Network analysis

   • Quality factor analysis

   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, and the skills and availability of supplier resources to meet commitments).

   Tip

   Risk identification and analysis tools help to identify risks more completely and rapidly, analyzing them more consistently, and allowing what has been learned on previous projects to be applied to new projects.

   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.

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, and procurement). The data can take any form (e.g., reports, manuals, notebooks, charts, drawings, specifications, files, or correspondence). The data may exist in any medium (e.g., printed or drawn on various materials, photographs, electronic, or multimedia).

Data may be deliverable (e.g., items identified by a project’s contract data requirements) or data may be nondeliverable (e.g., informal data, trade studies and analyses, internal meeting minutes, internal design review documentation, lessons learned, and 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 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 within 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 must be considered.

Typical 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 must 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 personnel and nondisclosure agreements between the acquirer and supplier.

   Tip

   Data privacy and security should be considered, but may not be an applicable consideration for certain types of projects.

   For example, when the supplier performs work for the acquirer off-site (e.g., off-shore development center), the acquirer must consider additional security measures such as a firewall between acquirer and supplier networks and restricted access to the acquirer’s workplace.

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 reprocurement 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. Decide which project data and plans require version control or more stringent levels of configuration control and establish mechanisms to ensure project data are controlled.

Plan for necessary resources to perform the project.

Defining project resources (e.g., labor, machinery/equipment, materials, and methods) and quantities needed to perform project activities, builds on the 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 or work product 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, 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 must 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 may be revised based on the supplier agreement or changes in conditions during project execution.

Typical Work Products

1. WBS 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

Subpractices

1. Determine process requirements.

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

   The acquirer must determine 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 the very least, processes should be compatible across interfaces.

   X-Ref

   At maturity level 3, the organization is typically the main source of process requirements, standard processes, and process assets that aid in their use (see OPF SP 2.3 and OPD).

2. 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 must 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.

3. Determine facility, equipment, and component requirements.

   Most projects are unique in some sense 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. Lead-time items must be identified early to determine how they will be addressed. Even when required assets are not unique, compiling a list of all of facilities, equipment, and parts (e.g., number of computers for the personnel working on the project, software applications, and 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 must also identify and ensure that facilities or equipment to be provided to the supplier for project work are accounted for in the project plan.

Plan for knowledge and skills needed to perform the project.

Refer to the Organizational Training process area for more information about knowledge and skills information to be incorporated into the project plan.

Knowledge delivery to projects involves both training project personnel 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 personnel 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.

Typical Work Products

1. Inventory of skill needs
2. Staffing and new hire plans
3. Databases (e.g., skills and 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.

   Hint

   Consider all knowledge and skills required for the project, not just the technical aspects.

   Example mechanisms include the following:

   • In-house training (both organizational and project)

   • External training

   • Staffing and new hires

   • External skill acquisition

   Tip

   If a skill is needed for the current project, but is not expected to be needed for future projects, external skills acquisition may be the best choice. However, if the skill needed for the project is expected to continue, training existing employees or hiring a new employee should be explored.

   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.

Plan the involvement of identified stakeholders.

Stakeholders are identified from all phases of the project lifecycle by identifying the people and functions that need to 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 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, memorandums of understanding, and memorandums 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.

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

Typical Work Products

1. Stakeholder involvement plan

Plan transition to operations and support.

Planning for transition must 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 transitioning 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 may 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 acceptance criteria and accepting the product.

Refer to the Acquisition Technical Management process area for more information about evaluation methods for the product.

Typical 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.

Establish and maintain the overall project plan.

A documented plan that addresses all relevant planning items is necessary to achieve the mutual understanding, commitment, and performance of individuals, groups, and organizations that must 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; technical and management tasks; budgets and schedules; milestones; data management; risk identification; resource and skill requirements; and stakeholder identification and interaction. Infrastructure descriptions include responsibility and authority relationships for project staff, management, and support organizations.

The project plan may 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.

Typical Work Products

1. Overall project plan

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 may 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 may have a hierarchy of plans (e.g., risk mitigation plans, transition plans, quality assurance plans, and configuration management plans). In addition, stakeholder plans (e.g., operational, test, support, and supplier plans) must be reviewed to ensure consistency among all project participants. Acquirer review of plans must include reviewing cross-supplier dependencies.

Typical Work Products

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

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 lowering or deferring technical performance 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 may incorporate major supplier milestones, deliverables, and reviews.

Typical Work Products

1. Revised methods and corresponding estimating parameters (e.g., better tools and the use of off-the-shelf components)
2. Renegotiated budgets
3. Revised schedules
4. Revised requirements list
5. Renegotiated stakeholder agreements

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.

Typical 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.

   Hint

   Use the WBS to ensure that all tasks are considered when obtaining commitments. Use the stakeholder involvement plan (or matrix) to ensure that all relevant stakeholders are considered.

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

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

   Tip

   A commitment not documented is a commitment not made (memories are imperfect and thus unreliable).

3. Review internal commitments with senior management, as appropriate.
4. Review external commitments with senior management, as appropriate.

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

   Tip

   Senior management must be informed of external commitments (especially those with customers, end users, and suppliers), as they can expose the organization to unnecessary risk.

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.