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

The Project Planning process area involves the following activities:

• Developing the project plan

• Interacting with stakeholders appropriately

• Getting commitment to the plan

• Maintaining the plan

Tip

In planning, you determine the requirements to be fulfilled, the tasks to perform, and the resources and coordination required, and then you document all of this to obtain the needed resources and commitments.

Planning begins with requirements that define the product and project.

Tip

The plan is a declaration that the work has been rationally thought through and requests for resources are credible. If you ask management to commit resources, they want to know it is worth the investment. A project plan helps you to convince them.

Before committing resources to an acquisition project, management needs a clear plan.

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.

X-Ref

PMC addresses tracking of project activities in the plan.

Project planning involves the development and maintenance of plans for all acquirer processes, including those 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.

Tip

Project planning is not just for large projects. Research with the Personal Software Process has demonstrated that individuals working on tasks lasting only a few hours increase overall quality and productivity by making time to 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.

Hint

To limit change in the plan, determine early in the project when and what kind of changes will be accepted.

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 the generic and specific practices in this process area to refer to the overall plan for controlling the project.

Hint

Both the organization and the project should define triggers for replanning.

Related Process Areas

Refer to the Acquisition Requirements Development process area for more information about developing requirements.

Refer to the Requirements Management process area for more information about managing requirements needed for planning and replanning.

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

Refer to the Acquisition Technical Management process area for more information about evaluations and reviews that must be included in technical planning.

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

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

Specific Goal and Practice Summary

SG 1 Establish Estimates

SP 1.1   Establish the Acquisition Strategy

SP 1.2   Estimate the Scope of the Project

SP 1.3   Establish Estimates of Work Product and Task Attributes

SP 1.4   Define Project Lifecycle Phases

SP 1.5   Estimate Effort and Cost

SG 2 Develop a Project Plan

SP 2.1   Establish the Budget and Schedule

SP 2.2   Identify Project Risks

SP 2.3   Plan Data Management

SP 2.4   Plan the Project’s Resources

SP 2.5   Plan Needed Knowledge and Skills

SP 2.6   Plan Stakeholder Involvement

SP 2.7   Plan Transition to Operations and Support

SP 2.8   Establish the Project Plan

SG 3 Obtain Commitment to the Plan

SP 3.1   Review Plans That Affect the Project

SP 3.2   Reconcile Work and Resource Levels

SP 3.3   Obtain Plan Commitment

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.

X-Ref

Specific goal 1 focuses on providing estimates of project planning parameters; actual values are monitored in PMC SP 1.1.

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 may be revised based on supplier estimates in response to the solicitation package.

Tip

Project planning parameters are a key to managing a project. Planning parameters primarily include size, effort, and cost.

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

Tip

The basis for estimates can include historical data, the judgment of experienced estimators, and other factors.

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.

Hint

Use this rationale to help justify to management why you need resources and why the effort and schedule estimates are appropriate.

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.

Hint

When you acquire a product or service, the earlier you prepare, the more likely you are to provide the right product of the right quality at the right time for project success.

Tip

The acquisition strategy should be developed to mitigate the unique technical and programmatic risks associated with the project.

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.

X-Ref

See “Techniques for Developing an Acquisition Strategy by Profiling Software Risks,” CMU/SEI-2006-TR-002, for guidance on how to use a risk-based approach to develop an acquisition strategy for a software-intensive system.

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.

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

    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.

  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.

Hint

For some acquisition programs, the acquisition strategy is created by a project team that precedes the creation of the final acquisition project team.

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

Hint

To develop estimates, decompose the project into smaller work items (the WBS), estimate the resources needed by each item, and then roll these up. This activity will result in more accurate estimates.

Tip

Interaction and iteration among planning, requirements definition, and design are often necessary. A project can learn a lot from each iteration and can use this knowledge to update the plan, requirements, and design for the next iteration.

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.

Hint

Consider establishing a management reserve commensurate to the overall uncertainty that allows for the efficient allocation of resources to address the uncertainty of estimates.

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

Hint

Learn to quantify the resources needed for particular tasks by associating size measures with each type of work product and building historical data. By collecting historical data from projects, you can learn how measured size relates to the resources consumed by tasks. This knowledge can then be used when planning the next project.

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.

X-Ref

For more information on tools and methods used for cost estimating, see www.cssc.usc.edu.

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.

Hint

Consider providing guidelines on how to estimate the difficulty or complexity of a task to improve estimation accuracy, especially when size measures are not available.

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.

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

Tip

For example, in a single-step acquisition, at the end of the requirements analysis phase, the requirements are evaluated to assess consistency, completeness, and feasibility, and to decide whether the project is ready (from a technical and risk perspective) to commit resources for suppliers to begin the design phase.

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

SP 1.5 Estimate Effort and Cost

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.

Hint

Calibrate estimation techniques and methods to take into consideration the project’s specific characteristics.

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.

Tip

Unprecedented efforts often require an evolutionary acquisition approach as part of the acquisition strategy. These methods provide frequent opportunities for feedback, which helps to resolve issues or risks and allows planning of the next iteration.

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

Tip

Differences between the acquirer’s estimate and the supplier’s estimate should be analyzed to uncover risks that may demand management attention.

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.
  3. Estimate effort and cost using models and historical data.

    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.

Tip

In some cases, each project phase may have a more detailed and focused plan of its own, in addition to the overall project plan. Also, a detailed plan typically is provided for each increment or iteration when using an evolutionary acquisition approach and will focus on particular requirements issues, design issues, or other risks.

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.

Tip

Plans that may affect the project plan include configuration management plans, plans for interfacing acquisition projects, the system’s support plan, the organization’s process improvement plan, and the organization’s training plan.

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.

Hint

If the budget is dictated by others and it doesn’t cover your estimated resource needs, replan to ensure that the project will be within budget. Likewise, if the schedule is dictated by others and it isn’t consistent with your plan, replan to ensure that the project will be able to deliver the product on time (perhaps with fewer features).

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

Tip

In an event-driven schedule, tasks can be initiated only after certain criteria are met.

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.

  5. Define 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 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.

SP 2.2 Identify Project Risks

Identify and analyze project risks.

Tip

Risk management is a key to project success.

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.

Hint

Once suppliers are selected, the acquisition project should define how risks are continuously identified, managed, and escalated by all stakeholders. Don’t rely on the supplier to do all the work; many risks are under the purview of the acquirer and must be identified, analyzed, and mitigated by the acquisition project team.

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.

    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.

Tip

Managing risk can be considered a “team sport.” It may be prudent to manage some risks with suppliers, gain insight on suppliers’ handling of their unique risks, and manage specific acquisition risks independently.

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, 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).

Tip

This specific practice helps to answer questions such as what data the project should collect, distribute, deliver, and archive; how and when it should do this; who should be able to access it; and how data will be stored to address the need for privacy and security, yet give access to those who need it.

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.

Hint

Interpret data broadly to benefit from data management more fully.

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.

Tip

Selecting a standard form can facilitate communication and understanding.

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.

Tip

Providing a reason for the data being collected encourages cooperation from those providing the 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.

Hint

In addition to making sure that all the relevant stakeholders (suppliers, end users, etc.) have access to project data, consider who you want not to have access. Doing so ensures that the acquisition process keeps competitors and adversaries in the dark.

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.

Tip

The data management plan defines the data necessary for the project, who owns it, where it is stored, and how it is used. It may even specify what happens to the data after the project terminates.

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.

  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.

X-Ref

Measurement data is a subset of project data. See MA SPs 1.3 and 2.3 for more information on collecting, storing, and controlling access to measurement data.

SP 2.4 Plan the Project’s Resources

Plan for necessary resources to perform the project.

Tip

This practice addresses all resources, not just personnel.

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.

Tip

The WBS established in SP 1.2 is expanded to help identify roles as well as staffing, process, facility, and tool requirements; to assign work; to obtain commitment to perform the work; and to track it to completion. Automated tools can help you with these activities.

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.

SP 2.5 Plan Needed Knowledge and Skills

Plan for knowledge and skills needed to perform the project.

Tip

This practice addresses the training that is specific to 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.

Tip

At maturity level 2, the organization may not be capable of providing much training for its projects. Each project might address all of its knowledge and skill needs. At maturity level 3, the organization takes responsibility for addressing common training needs (e.g., training in the organization’s set of standard processes).

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

Tip

Either the project or the organization can maintain these typical work products.

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.

    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.

SP 2.6 Plan Stakeholder Involvement

Plan the involvement of identified stakeholders.

X-Ref

Identifying and involving relevant stakeholders is also addressed in PMC SP 1.5, IPM, and GP 2.7.

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.

Hint

For each project phase, identify stakeholders important to the success of that phase and their role (e.g., implementer, reviewer, or consultant). Arrange this information into a matrix to aid in communication, obtain their commitment (SP 3.3), and monitor status (PMC SP 1.5).

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.

Tip

Not all stakeholders identified will be relevant stakeholders. Only a limited number of stakeholders are selected for interaction with the project as work progresses.

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

SP 2.7 Plan Transition to Operations and Support

Plan transition to operations and support.

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

Tip

A successful transition involves planning for the appropriate facilities, training, use, maintenance, and support.

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.

Tip

Acquirers should not overlook a supplier’s responsibilities for ongoing maintenance and support. Long-term support needs should be considered when establishing the supplier agreement.

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.

SP 2.8 Establish the Project Plan

Establish and maintain the overall project plan.

Tip

The plan document should reflect the project’s status as requirements and the project environment change.

A documented plan communicates resources needed, expectations, and commitments; contains a game plan for relevant stakeholders, including the project team (SP 3.3); documents the commitment to management and other providers of resources; and is the basis for managing the project.

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.

Hint

Most project plans change over time as requirements are better understood, so plan how and when you will update the plan.

Tip

Before making a commitment, a project member analyzes what it will take to meet the commitment. Project members who make commitments should continually evaluate their ability to meet their commitments, communicate immediately to those affected when they cannot meet their commitments, and mitigate the impacts of being unable to meet their commitments.

Typical Work Products

  1. Overall project plan

X-Ref

Commitments are a recurring theme in CMMI. Requirements are committed to in REQM. Commitments are documented and reconciled in PP, monitored in PMC, and addressed more thoroughly in IPM.

SG 3 Obtain Commitment to the Plan

Commitments to the project plan are established and maintained.

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

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

Hint

Beware of commitments that are not given freely. A favorite quote that applies is “How bad do you want it? That is how bad you will get it!” If you do not allow commitments to be made freely, staff members most likely will try to provide the commitment you want to hear instead of a well-thought-out answer that is accurate.

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

Hint

How related plans are documented is up to the project. Sometimes it makes sense to have all plans in one document. Other times it doesn’t. However, all the plans must be consistent and be consistently updated.

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

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

Tip

A well-written plan includes estimates of the resources needed to complete the project successfully. When the estimates are higher than the resources available, the situation must be reconciled so that all relevant stakeholders can commit to a feasible plan (SP 3.3).

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.

Tip

Since resource availability can change, such reconciliation will likely need to be done multiple times during the life of the project.

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

SP 3.3 Obtain Plan Commitment

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

Tip

Commitments are a two-way form of communication.

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.

Tip

In maturity level 1 organizations, management often communicates a different picture of the project than the staff does. This inconsistency indicates that commitments were not obtained.

Typical Work Products

  1. Documented requests for commitments
  2. Documented commitments

Tip

Documenting commitments makes clear the responsibilities of those involved with the project.

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.

X-Ref

For more information on managing commitments, dependencies, and coordination issues among relevant stakeholders, see IPM SG 2. For more information on identifying and managing interfaces, see ATM SG 2.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.218.119.156