Projects establish the foundation by institutionalizing basic project management and supplier management practices. The acquirer ensures that processes are planned and executed in accordance with policy; employs skilled people who have adequate resources to produce controlled outputs; involves relevant stakeholders; and monitors, controls, reviews, and evaluates projects for adherence to their process descriptions (see Figure A-1).

Figure A-1. Level 2 process areas

The process discipline helps to ensure that you retain existing practices during times of stress. For instance, the status of the work products and the delivery of services are visible to management at defined points (such as at major milestones and at the completion of major tasks). Commitments are established among relevant stakeholders and are revised as needed. Work products are reviewed with stakeholders and are controlled. The work products and services satisfy their specified requirements, standards, and objectives.

The acquisition strategy and existing supplier agreements drive how much work, and what work, to give to a supplier. Depending on your acquisition strategy, there may be intermediate phases for the creation of prototypes, increments of capability, or spiral model cycles. In a complex project, you may be managing multiple supplier agreements simultaneously or in sequence. In such cases, any acquisition life cycle can end during any phase of the project life cycle.

You consider all supplier agreements within the context of the acquisition so that you develop an integrated approach rather than deal with activities individually. The characteristics of prequalified or other potential suppliers—including technical and financial capability, management and delivery processes, production capacity, and business type and size—are key elements of project success, and therefore you consider these characteristics in identifying constraints for the project.

The Solicitation and Supplier Agreement Development process area defines practices to prepare a solicitation package, select a capable supplier, and establish the supplier agreement. Acquisition Management focuses on maintaining the supplier agreement, including resolving disputes and managing your relationship with the supplier. This includes managing payments to and ongoing communications with suppliers. The Solicitation and Supplier Agreement Development and Acquisition Management process areas are described in detail in section A.3.

The purpose of the Project Planning area is to establish and maintain plans that define project activities. The amount of supplier work for a project largely determines the amount of your work that it takes to manage the project and the supplier. Estimate supplier work at a high level, and your work at a more detailed level. Your effort includes (1) effort associated with defining the scope of the project, (2) effort associated with the development and deployment of the technical solution, (3) operating and maintenance effort associated with the maintenance of the solution, and (4) disposal effort.

In addition to creating an estimation of the work products, you are encouraged to have your estimate independently reviewed by individuals outside the project to ensure that your estimates can be validated. Be sure to include the effort and cost of supporting execution of your processes as well as developing the product.

You develop a work breakdown structure (WBS) that clearly identifies which project work is performed by you and which is performed by the supplier. The WBS includes activities performed by you as well as milestones and deliverables for the suppliers. The supplier work identified in the WBS becomes the foundation for the statement of work for suppliers. The WBS identifies the deliverables from the supplier and the work products you develop. Your understanding of suppliers’ life-cycle models and processes, especially those that interact directly with your processes, enables you to plan for seamless interactions between you and your suppliers, resulting in a successful acquirer-supplier relationship.

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

The project plan may include multiple plans, such as staffing plans, stakeholder involvement plans, risk mitigation plans, transition plans, quality assurance plans, and configuration management plans. Regardless of the form they take, the plans should address the acquisition strategy as well as the cradle-to-grave considerations for the project and product to be acquired. For example, you should consider what facilities and equipment must be provided by the supplier, as well as what you may need to provide for acceptance of the supplier deliverables, transition, and support of the acquired product. The supplier agreement must include any facility or equipment requirements for the supplier. You must also identify and ensure that any facilities or equipment to be provided to the supplier for its project work are accounted for in the project plan.

You must also plan for how data will be shared between you and the supplier as well as among relevant stakeholders. This planning avoids unexpected costs to procure, reformat, and deliver data. In many cases, the ideal solution is to leave your data in the physical possession of the supplier and have access to the supplier’s data. In addition to data access, the data management plan should include the requirement for your use of data and for its reproduction, manipulation, altering, or transfer of possession.

The supplier agreement specifies appropriate acquirer rights to the data in addition to requirements for delivery or access. Data, whenever it is delivered to you, is formatted in accordance with accepted data standards to ensure its usability by you. Include plans for managing data within the project teams and for the infrastructure required to manage data between the supplier, operational users, and other relevant stakeholders. Decide which project data and plans require version control or more stringent configuration control, and establish mechanisms to ensure that project data is controlled. Consider the implications of controlling access to classified and sensitive data (e.g., proprietary, export-controlled, source-selection-sensitive) and other access-controlled data.

When you provide data access to the supplier, security and access control are critical. This includes creating access lists of authorized supplier personnel and nondisclosure agreements between you and the supplier. For example, when the supplier performs work for you off-site (e.g., at an offshore development center), then you need to consider additional security measures. Examples include a firewall between your network and the supplier’s and restricted access to your workplace.

Ideally, the data management plan is supported by an integrated data system that meets the needs of both initial acquisition and the support community. Integrating acquisition and maintenance data systems into a total life-cycle integrated data environment lets you plan effectively for maintenance and facilitates insertion of new technology. It also ensures that acquisition planners have accurate information about total life-cycle costs.

The purpose of the Requirements Management process area is to manage the requirements of the project’s products and components and to identify inconsistencies between those requirements and the project’s plans and work products. Typically, you directly manage changes to customer and contractual requirements developed by you and oversee the supplier’s requirements management process. You negotiate commitments with the customer and supplier before committing to any changes in requirements. Requirements changes may result in changes to the supplier agreement; these changes need to be agreed upon between the project and the supplier after appropriate negotiations. The supplier maintains comprehensive bidirectional traceability to the requirements you define in the supplier agreement, and you verify that traceability.

You are responsible for monitoring the progress and output of the project. The Project Monitoring and Control process area is concerned with monitoring and control of acquirer activities and oversight of the progress and performance of the supplier’s execution according to the project plans. Project Monitoring and Control practices give you an understanding of the project’s progress; in this way, you can take appropriate corrective actions when the project’s performance deviates significantly from the plan.

As the acquisition unfolds, monitoring and control are essential to ensuring that appropriate resources are being applied and that your activities are progressing according to plan. For instance, you track commitments for resources that will result in expenditures (e.g., issued purchase orders and completed supplier deliverables that have been accepted) when they are incurred, even before formal payment. In this way, you can ensure that future financial and legal obligations are accounted for as soon as they are incurred.

You monitor overall project risk. Many risks are your sole responsibility and may include sensitive information that should not be shared with the supplier (e.g., source-selection-sensitive, recompetition, internal staffing, or other risks). There can also be risks (e.g., the feasibility of the technology to meet end user performance requirements) that require careful coordination with suppliers and appropriate escalation of risks and risk status. Shared risks may affect the mitigation approaches and may result in jointly planned mitigations.

After you select a supplier and establish a supplier agreement, the role of monitoring and control becomes twofold. You continue to monitor and control your activities and work products while also monitoring and controlling the progress and performance of the supplier’s execution under the supplier agreement and the supplier’s project plans. You monitor the progress of the supplier—including achievement of service levels established in the supplier agreement—by using the supplier’s measurement data about its progress and output. This includes monitoring the availability of resources provided by the supplier and the skills and knowledge of the supplier personnel. In addition to monitoring the attributes of your work products, you monitor the attributes of supplier deliverables through acceptance criteria and through analysis of the supplier’s peer review results.

If a corrective action is required to resolve variances from project plans, these actions should be defined and tracked to closure. Corrective action is taken for your deviations and when supplier execution does not satisfy the supplier agreement or align with project planning (e.g., date slippages in milestones and work products). Some corrective actions may be assigned to a supplier. When your monitoring of measurement data indicates, for example, that supplier progress does not appear to be sufficient to meet a service level defined in the supplier agreement, then you initiate and manage corrective action for the supplier. If the supplier does not comply appropriately, you escalate and handle this as a supplier agreement issue or dispute.

You use the practices in the Measurement and Analysis process area to support the information needs of the business, organization, and project. Some of this information may be needed from you, some from the supplier, and some from all parts of a project. The supplier agreement must designate all information required from the supplier. The measures you specify are designed to enable you to determine the status of your progress and output, the supplier’s progress and output per contractual requirements, and the status of the evolving products.

You use measurement objectives to define specific measures and their collection, analysis, storage, and usage procedures. You establish measurement objectives for your activities and work products and for supplier deliverables. The measurement objectives are derived from information needs that come from project objectives, organizational objectives, and business needs. Measurement objectives focus on your performance as well as the supplier’s performance, and on your understanding their effects on customer, operational, and financial performance. Measurement objectives for the supplier enable you to define and track service level expectations documented in the supplier agreement. You need to consider the impact of existing supplier agreements on measurement objectives.

To manage projects, you use supplier-reported measures in addition to your own measures of progress and output. The supplier measures allow you to comprehensively address the measurement objectives and determine the progress and output of the project. In some cases, these supplier measures will augment your measures. For instance, your return on investment measure can incorporate the supplier’s cost performance index.

In most cases, the supplier measures are the primary source of data, especially with regard to the development of the product. For instance, for effective management of the quality, size, cost, and schedule of the project (e.g., the amount of new, modified, and reused code; the percentage of function points complete; defect removal efficiency), it is essential that you apply technical performance measures to measure and analyze the product or components provided by a supplier.

When you are acquiring multiple products to deliver a capability to the end user, or when there are relationships with other projects to acquire joint capabilities, you can identify additional measures to track and achieve interoperability objectives in terms of programmatic, technical, and operational interfaces.

Measures may be provided by the supplier as detailed measurement data or measurement reports. The measures that come from suppliers must be associated with your acceptance criteria for supplier measures. The acceptance criteria can be captured in measurement specifications or by checklists, if appropriate.

The acceptance criteria should be defined in a way that enables the intended use of the supplier measures, such as potential aggregation and analysis. They need to include any criteria associated with the collection and transfer mechanisms and procedures that must be performed by the supplier. Consider all characteristics of the supplier measures that may affect their use, such as differences in financial calendars used by different suppliers. If data is not available or data integrity checks indicate potential errors, follow up with suppliers.

Supplier measures must be defined in the supplier agreement, including the supplier’s measurement collection requirements and the measurement reports to be provided to you. Data collection from a supplier can be integrated with periodic monitoring and review of supplier activities. You can conduct validity checks of supplier data by means of periodic audits of the supplier’s execution of the data collection and analysis procedures for your required measures. The supplier agreement specifies which measurement data the supplier must provide to you, the required format, the means of its collection and storage (e.g., retention period of data), how and how often it will be transferred to you, and who has access to the data. The supplier may consider some supplier data proprietary, and you may need to protect it as such. Also consider that some of your measurement data (e.g., total project cost data) may be proprietary and should not be shared with suppliers. You need to plan for the collection, storage, and access control of this type of sensitive data.

The Process and Product Quality Assurance area has processes for evaluating your critical work products, your processes, and the results of the supplier’s process quality assurance activities with respect to supplier deliverables and processes. You evaluate the project’s execution of your processes, including interactions with suppliers and reviews of the quality assurance reports provided by suppliers, to determine whether they follow their processes. There should be sufficient process quality assurance that you can detect noncompliance issues as early as possible that may affect your or the supplier’s ability to successfully deliver the technology solution to the customer. For example, process and product quality assurance ensures that the solicitation package was developed per the standard processes you agreed to and that it conforms to all applicable policies.

You can review the results of the supplier’s quality assurance activities for supplier processes to ensure that the supplier is following its own processes. Typically, you select critical supplier processes, such as engineering or verification processes, where the supplier is required (through the supplier agreement) to follow project-specified standards. In exceptional cases, you can directly perform product and process quality assurance for selected supplier processes.

You and the supplier periodically share quality assurance issues and findings that are of mutual interest. For example, the supplier agreement can require the supplier to provide detailed appraisal results of mandatory, acquirer-scoped CMMI for Development appraisals of supplier processes. Through the supplier agreement, you should retain the right to audit supplier processes if there is an indication that suppliers are not following acceptable processes.

You perform product quality assurance by applying practices from the Acquisition Technical Solution and Acquisition Verification process areas. In addition to objectively evaluating your critical work products, you use objective acceptance criteria to evaluate supplier deliverables throughout the project life cycle. For that purpose, your acceptance criteria for supplier deliverables are consistent with the project objectives and sufficient to allow the supplier to satisfactorily demonstrate that the technology solution conforms to contractual requirements.

The Configuration Management process area (not depicted in Figure A-1) uses configuration identification, configuration control, configuration status accounting, and configuration audits to establish and maintain the integrity of work products such as solicitation packages. Your approach to configuration management depends on acquisition-specific factors, such as your acquisition approach, the number of suppliers, your design responsibility, your support concept, and associated costs and risks. The level of control is typically selected based on project objectives, risk, or resources (or all three).

Levels of control can range from informal control (which simply tracks changes made when you are developing the configuration items or when supplier work products are delivered or made accessible to you) to formal configuration control (using baselines that can be changed only as part of a formal configuration management process). Although the supplier may manage configuration items on your behalf, you are responsible for approval and control of changes to such configuration items.

Configuration items may vary widely in complexity, size, and type, from an aircraft to commercial off-the-shelf software to a test meter or project plan. Any item required for product support and designated for separate procurement is a configuration item. Your work products provided to suppliers, such as solicitation packages and technical standards, are typically designated as configuration items.

Consider how configuration items will be shared between you and suppliers as well as among relevant stakeholders. If you extend the use of your configuration management system to a supplier, you must exercise security and access control procedures. If a configuration management system is shared between you and suppliers, then the supplier agreement must specify clear responsibility for managing the configuration items, baselines, security aspects, access restrictions, and backup and restore processes. You must ensure that the supplier agreement specifies the configuration management requirements for the supplier (e.g., status reporting and providing configuration audit results). In many cases, you can leave acquired configuration items in the physical possession of the supplier and have access to supplier deliverables. The supplier agreement specifies appropriate acquirer rights to the supplier deliverables in addition to requirements for delivery or access. Supplier work products, whenever they are delivered to you, are formatted in accordance with accepted standards to ensure usability by you.

In any case, configuration management involves interaction between you and suppliers. You review and approve the release of the product baselines created by the supplier. You create baselines for your work products to mark the agreement regarding the description of the project, requirements, funding, schedule, and performance parameters and to make a commitment to manage the program to those baselines. For example, your baseline might be a collection of your work products such as contractual requirements and acceptance criteria that are related to the product baseline managed by the supplier.

With regard to the technical solution, you maintain configuration control of the contractual requirements, and the supplier performs configuration management for the technical solution (e.g., it establishes and maintains a product baseline). Thus, you retain the authority and responsibility for approving any design changes that affect the product’s ability to meet contractual requirements. The supplier manages other design changes.

Change requests can be initiated by either you or the supplier. Changes that affect your work products and supplier deliverables as defined in the supplier agreement are handled through your configuration management process. You analyze the impact of submitted change requests to the supplier agreement. You maintain the right to access configuration data at any level required to implement planned or potential design changes and support options. Configuration management of legacy systems should be addressed on a case-by-case basis as design changes are contemplated.

Acquirers are using defined processes for establishing and managing standard supplier agreements, and they embed tenets of project management and engineering best practices, such as requirements development and design constraints, into the standard process set. These processes are well characterized and understood and are described in standards, procedures, tools, and methods.

Your set of standard processes is established and improved over time. These standard processes are used to establish consistency across the organization. Projects establish their defined processes by tailoring the organization’s set of standard processes according to tailoring guidelines.

A critical distinction between defined processes and managed processes is the scope of standards, process descriptions, and procedures. Managed processes may be quite different in each specific instance of the process (e.g., from project to project). Defined processes for a project, on the other hand, are tailored from the organization’s set of standard processes to suit a particular project or unit, and therefore they are more consistent except for the differences allowed by the tailoring guidelines. Another critical distinction of defined processes is that they are typically described more rigorously than managed processes are. A defined process clearly states the purpose, inputs, entry criteria, activities, roles, measures, verification steps, outputs, and exit criteria.

Acquisition Requirements Development focuses on specifying customer and contractual requirements that express customer value (see Figure A-2). You use Acquisition Validation processes to ensure that the products received from the supplier will fulfill the stakeholders’ intentions. You provide design constraints to the supplier, and the product is designed and implemented by the supplier consistent with your design constraints.

Figure A-2. Level 3 process areas

Acquisition Technical Solution covers developing design constraints and verifying the supplier’s technical solution. You apply Acquisition Verification processes to address whether the acquired product, intermediate acquirer work products, and supplier deliverables meet their contractual requirements. Acquisition Requirements Development, Acquisition Validation, Acquisition Technical Solution, and Acquisition Verification process areas are described in detail in section A.3.

You apply Integrated Project Management practices to establish and manage the project and the involvement of the relevant stakeholders according to an integrated and defined process that is tailored from the organization’s set of standard processes. The project’s defined process logically sequences acquirer activities and supplier deliverables (as identified in the supplier agreement) to deliver a product that meets the requirements. It is driven by your acquisition strategy. For example, the acquisition strategy might be to introduce new technology to the organization, or it might focus on consolidating the acquired products or services you are using. Which strategy you’ve adopted affects the project’s defined process.

You need to involve and integrate all the relevant acquisition, technical, support, and operational stakeholders. You ensure that stakeholder coordination and cooperation are maximized to the extent possible. Depending on the project’s scope and risk, your coordination efforts with the supplier can be significant. The supplier agreement provides the basis for managing supplier involvement.

The purpose of Risk Management is to identify potential problems before they occur so that you can plan and invoke risk handling activities as needed during the life of the product to mitigate adverse impacts on achieving objectives.

Risk Management has two contexts. The first context is the identification and assessment of project risks during project planning and managing these risks throughout the project. You enter the second context after the selection of a supplier and award of the supplier agreement. The risk management processes must address the risks associated with the supplier’s role in the project. Throughout the life cycle of the project, you continue to manage the risks related to the supplier as well as managing project risks overall.

Because of the acquirer-supplier relationship, the need for early and aggressive detection of risk is compounded by the complexity of acquisition projects. For example, your capabilities, the supplier’s experience of working with you, the supplier’s financial stability, or the availability of well-defined dispute resolution processes influence the risk of a project. You should conduct a risk assessment before solicitation to evaluate whether the project can achieve the technical, schedule, and budget constraints. You should discuss technical, schedule, and cost risks with potential suppliers before the solicitation is released. In this way, you can identify and address inherent critical risks in the solicitation.

Both you and the supplier must understand the project risks and know how to modify the risk management strategy and plans as the project progresses through its life cycle. Managing a project’s risks requires a close partnership between you and the supplier. Both parties need to share appropriate risk management documentation, understand the risks, and develop and execute risk management efforts.

You initially identify and categorize risk sources and categories (e.g., schedule, cost, sourcing, contract management, supplier execution, technology readiness, human safety, reliability-related risks, and other issues outside your control) and refine them over time. You consider the risks associated with a supplier’s capability (e.g., meeting schedule and cost requirements), including the potential risks to your intellectual capital or security vulnerabilities introduced by using a supplier. Your risk categories typically include sourcing, contract management, and supplier execution, in addition to project management, technology, and requirements. Thresholds for supplier risks that affect the project (e.g., schedule, quality, or risk exposure due to supplier risks) are specified in the supplier agreement along with escalation actions if the thresholds are exceeded.

A risk management strategy must be developed early in the project so that relevant risks are identified and managed aggressively. The acquisition strategy evolves based on risk identification and analysis. The early identification and assessment of critical risks allow you to formulate approaches and streamline the project definition and the solicitation around critical risks. You identify some risks by using the categories and parameters in the risk management strategy to examine the supplier’s WBS, product, and processes. Risks can be identified in many areas, such as requirements, technology, design, testing, vulnerability to threats, and life-cycle costs. Examining the project in these areas can help you develop or refine the acquisition strategy and the risk-sharing structure between you and suppliers.

You share selected risks with the supplier. Risks associated specifically with the acquisition process are tracked, and then they are resolved or controlled until mitigated. This monitoring includes risks that may be escalated by the supplier. To examine risks such as potential failures in products or processes, you can use tools such as failure mode and effects analysis. These tools can be used to evaluate risk management priorities for mitigating known threat vulnerabilities.

The practices in Decision Analysis and Resolution help you analyze possible decisions by using a formal process to evaluate identified alternatives against established criteria. A repeatable criteria-based decision-making process is especially important, both while you’re making the critical decisions that define and guide the acquisition process and later, when you make critical decisions with the selected supplier. Having a formal process for decision making provides you with documentation of the decision rationale. Such documentation lets you revisit the criteria for critical decisions when you consider making changes or adopting technology that will affect requirements or other critical project parameters. A formal process also supports the communication of decisions between you and suppliers. Suppliers competing to develop a technical solution can be directly evaluated in a final competition that possibly involves performance or functional demonstration of proposed solutions.

Organizational Process Definition focuses on establishing and maintaining a usable set of organizational process assets and work environment standards. Your set of standard processes also describes standard interactions with suppliers. Supplier interactions are typically identified in terms of deliverables expected from suppliers, acceptance criteria applicable to those deliverables, standards (such as architecture and technology standards), and standard milestone and progress reviews.

Basing standard processes on industry standards and widely accepted models, with common terminology, enables seamless interactions between you and suppliers. In a multisupplier environment, this is most important for your standard processes that directly interface with the supplier processes. Also, you may gain cost and coordination benefits from having suppliers work together to develop or reconcile common support processes that are aligned with your processes.

The life-cycle models may include acquisition life cycles, depending on the specific acquisition strategy chosen. The acquisition life cycle typically begins with the pre-award phase of a supplier agreement, continues through the phases of awarding and managing the supplier agreement, and ends when the supplier agreement period of performance ends, usually with the acceptance and completion of the warranty for the product and its transition to the support organization. Your review of life-cycle models typically includes the participation of suppliers for those processes and process elements that define expectations and constraints for suppliers.

Tailoring is a critical activity that allows controlled changes to the processes to meet specific needs of a project or a part of the organization. Processes and process elements that are directly related to critical business goals and objectives should usually be defined as mandatory (allowing less variation), but those that are less critical or only indirectly affect business objectives may allow for more tailoring (and therefore more variation). Tailoring might also depend on the life-cycle model of the project, the supplier, or the acquirer-supplier relationship.

The supplier agreement defines how changes to organizational process assets that affect the supplier (e.g., standard supplier deliverables, acceptance criteria) must be deployed. You should encourage participation of suppliers in process improvement activities (Organizational Process Focus). Suppliers may be involved in developing the process action plans if the processes that define interfaces between you and suppliers are targeted for improvement.

The purpose of the Organizational Training processes is to develop people’s skills and knowledge so that they can perform their roles effectively and efficiently. When you identify training needs, you may also want to address some training needs of suppliers, especially in those process elements that define interfaces with and expectations for suppliers.

You control variation in your results by applying quantitative management. That is, you examine the business system being used to meet the needs of the end customer, identifying constraints that significantly impede overall business performance. You use statistical and other quantitative techniques to understand these constraints so that you can make the appropriate process refinements, including adjustments to your supplier interactions to better achieve business objectives. Focusing on these critical constraints, you can use process performance models to predict how to best maximize the flow of work through the project and the organization.

Defined processes are different from quantitatively managed processes in the predictability of process performance. The performance of quantitatively managed processes is controlled using statistical and other quantitative techniques and is quantitatively predictable. Typically, defined processes are only qualitatively predictable.

The purpose of the Quantitative Project Management process area is to quantitatively manage the project’s defined process to achieve the project’s established quality and process performance objectives. You use quantitative methods to manage your work and to gain insight into the supplier’s work and products. In addition to your own quantitative data, you use quantitative data provided by the supplier (as specified in the supplier agreement) to address the specific practices in this process area. For the successful implementation of this process area’s specific practices, you need to establish effective relationships with suppliers.

You establish the project’s quality and process performance objectives based on the objectives of the organization and the project. You can also establish quality performance objectives for supplier deliverables. These supplier objectives are documented in the supplier agreement. You may require the supplier to provide process performance measurements for its participation in the project’s processes or subprocesses (e.g., the estimating subprocess).

When you select the processes for analysis, it is critical to understand the relationships between the various processes and their impact on your and the supplier’s performance relative to delivering the product specified by the customer. Such an approach will help ensure that quantitative and statistical management is applied where it will have the most overall value to the business. Using data and measures submitted by the supplier, you analyze supplier process performance as it interfaces with your processes. Performance models are used to set performance objectives for the suppliers and to help them achieve these objectives.

You monitor the performance of selected subprocesses—including those that involve interaction with a supplier—as well as the quality performance of the supplier deliverables for adherence to the quality and performance objectives. This selective monitoring provides you with insight into project and supplier performance so that you can predict the likelihood of achieving the project’s objectives for quality and process performance. You use this information to manage the risks of the project and to initiate corrective actions in time to meet the project objectives.

The purpose of Organizational Process Performance is to establish and maintain a quantitative understanding of the performance of your set of standard processes in support of quality and process performance objectives, and to give you the process performance data, baselines, and models to quantitatively manage your projects. Process performance models are used to estimate or predict when to fund, hold, cancel, migrate, reengineer, or retire a project or program. Process performance models allow you to synchronize processes with the customer’s needs.

Your process performance baselines provide quantitative data on those aspects of the projects and organization that can approximate the throughput potential of its processes. Focusing on these critical constraints, process performance models allow you to predict how to best maximize the flow of work through the projects and the organization. Performance models are also used to set performance objectives for the suppliers and to provide data that can help suppliers achieve these objectives. The results of your process performance models are shared with the suppliers so that they can ensure synchronized delivery of products and services.

An acquirer continually improves its processes based on a quantitative understanding of the common causes of variation inherent in processes. To optimize your processes, you select and deploy incremental and innovative improvements that measurably improve your processes and technologies (see the processes in the Organizational Innovation and Deployment process area). The improvements enhance your and your suppliers’ ability to meet your quality and process performance objectives.

Your customers and suppliers are vital sources of innovative ideas. Interorganizational and organizational learning are therefore critical to actively identifying and analyzing innovations. Together with your suppliers, you can establish an innovation review program. This program can create time-boxed innovation solicitation, which is a well-communicated formal process for analysis and guaranteed response to innovative ideas proposed by customers, employees, and suppliers.

You establish quantitative process improvement objectives for the organization, and then you continually revise them to reflect changing business objectives, and you use them as criteria in managing process improvement. You must continuously improve your processes and your alignment with your suppliers. You can look for opportunities to maximize throughput based on identifying the most limiting resource and, as a result, create a more agile supply chain. Examples of such opportunities include proposals that promise to make the supply chain respond both quickly and cost-effectively.

Your plan for deploying improvements can include openly sharing most process know-how with your suppliers. Any process-related knowledge that you or one of your suppliers possesses is viewed as accessible to virtually any other supplier in your supply chain (perhaps with the exception of a direct competitor). In this case, you need to establish rules and norms that prevent suppliers from accessing your knowledge unless they first explicitly agree to openly share knowledge with your other suppliers. For example, you have the ability to impose economic sanctions (e.g., withdrawal of business) on a supplier that violates the rule.

The effects of deployed process improvements are measured and evaluated against the quantitative process improvement objectives. Both the defined processes and your set of standard processes are targets of measurable improvement activities. You and suppliers can share the costs and benefits of improvements. You can increase the incentive for suppliers to participate in improvement efforts across the supply chain by allowing suppliers to appropriate all the value derived from a contributed improvement in the short term (e.g., 6 to 18 months). Over time the supplier may be expected to share a proportion of those savings with you (e.g., through cost reductions).

You typically achieve your quality and performance objectives in partnership with your suppliers. You typically focus on differentiating your capabilities along with collaborative supplier management. Achieving these objectives also depends on your being able to effectively evaluate and deploy proposed improvements to the processes and technologies. All members of the acquirer-supplier network participate in your process improvement and technology improvement activities. This requires the supplier’s willingness to open its processes for inspection to you and your other suppliers. Suppliers’ process improvement proposals are systematically gathered and addressed.

A critical distinction between quantitatively managed processes and optimizing processes is the type of process variation addressed. An acquirer that uses quantitatively managed processes is concerned with addressing special causes of process variation and providing statistical predictability of the results. Although processes may produce predictable results, the results may be insufficient to achieve the established objectives. Acquirers that use optimizing processes are concerned with addressing common causes of process variation and with changing the process (to shift the mean of the process’s performance or to reduce the inherent process variation experienced) and thereby improve process performance and achieve the established quantitative process improvement objectives.

The purpose of Solicitation and Supplier Agreement Development (SSAD) is to prepare a solicitation package and to select one or more suppliers for delivering the product or service. The Solicitation and Supplier Agreement Development process area includes developing the acquisition strategy. The acquisition strategy is a guide to direct and control the project and a framework to integrate the activities essential to acquiring an operational product.

The Solicitation and Supplier Agreement Development process area provides a set of practices that enable the acquirer to initialize and formalize a relationship with the supplier for the successful execution of the project. A formal agreement is any legal agreement between the organization (representing the project) and the supplier. This agreement may be a contract, a license, or a memorandum of agreement. The acquired product is delivered to the project from the supplier according to this formal agreement (also known as the “supplier agreement”).

The supplier agreement created using these practices enables the acquirer to execute its monitoring and control of supplier activities using other process areas, such as Project Monitoring and Control and Acquisition Management.

The practices of this process area apply equally to initial supplier agreements and to subsequent change orders, task orders, or amendments related to those agreements.

The acquirer is responsible for establishing and maintaining the ground rules for supplier communication, documenting decisions, and conflict resolution through the life of the agreement. The acquirer facilitates these activities with relevant project stakeholders. Specific roles and responsibilities of relevant project stakeholders for interaction with or direction of the suppliers are defined, coordinated, and adhered to.

The specific goals and specific practices of this process area build on each other in the following way. The Prepare for Solicitation and Supplier Agreement Development specific goal and associated practices identify potential suppliers and develop the evaluation criteria and the solicitation package. The solicitation package is developed using work products from other process areas, e.g., requirements from Acquisition Requirements Development and design constraints from Acquisition Technical Solution. The Select Suppliers specific goal and associated specific practices use the work products from the preparation for solicitation to solicit responses from potential suppliers, evaluate these responses, and negotiate and select a supplier who can best deliver to the solicitation package. Subsequently, the Establish Supplier Agreement specific goal and associated practices are used to document the approved supplier agreement. In turn, the data provided by the supplier and documented in the supplier agreement (e.g., cost, schedule, risks) is used by Project Planning practices to update the project plan.

Although this process area describes acquisition practices for a project, an acquirer would use the same practices in establishing a supplier agreement for multiple projects. The requirements included in the solicitation package and the supplier agreement would reflect the broader scope, and the evaluation and selection process would require an appropriate level of review before a selection is made.

The purpose of Acquisition Management (AM) is to ensure that the supplier’s performance meets contractual requirements and that the acquirer performs according to the terms of the supplier agreement. The Acquisition Management process area involves the following:

The legal nature of the acquirer-supplier relationship makes it imperative that the project management team is acutely aware of the legal implications of actions taken when managing any acquisition of products or services.

The supplier agreement is the basis for managing the relationship with the supplier, including resolving issues and disputes. It defines the mechanisms to allow the acquirer to oversee the supplier’s activities and evolving products, and to verify compliance with supplier agreement requirements. It also provides the vehicle for mutual understanding between the acquirer and the supplier.

Deviations from the project plan may cause changes to the supplier agreement, and significant changes to the supplier agreement may require the project plan to be modified. When the supplier’s performance, processes, or products fail to satisfy established criteria as outlined in the supplier agreement, the acquirer may decide to apply legal remedies.

The purpose of Acquisition Requirements Development (ARD) is to produce and analyze customer and contractual requirements. Requirements are the basis for the selection and for the design or configuration of the acquired product. The development of requirements includes the following activities:

The requirements included in the solicitation package form the basis for evaluating alternative proposals by suppliers and for further negotiations with the suppliers and communication with the customer. The contractual requirements for the supplier are baselined in the supplier agreement.

Requirements are identified and refined throughout the project life cycle. Design decisions, subsequent corrective actions, and feedback during each phase of the project’s life cycle are analyzed for impact on contractual requirements.

Requirements analyses aid in understanding, defining, and selecting the requirements at all levels from competing alternatives. Analyses occur recursively at successively more detailed levels until sufficient detail is available to produce contractual requirements and to further refine these, if necessary, while the supplier builds or configures the product.

Involvement of relevant stakeholders in both requirements development and analyses gives them visibility into the evolution of requirements. Participation continually assures the stakeholders that the requirements are being properly defined.

The Acquisition Requirements Development process area includes three specific goals. The Develop Customer Requirements specific goal addresses eliciting and defining a set of customer requirements. The Develop Contractual Requirements specific goal addresses defining a set of contractual requirements that are based on customer requirements and included in the solicitation package and supplier agreement. The specific practices of the Analyze and Validate Requirements specific goal support the development of the requirements in both the Develop Customer Requirements specific goal and the Develop Contractual Requirements specific goal. The specific practices associated with this specific goal cover analyzing and validating the requirements with respect to the acquirer’s intended environment.

The processes associated with the Acquisition Requirements Development process area and those associated with the Acquisition Technical Solution process area may interact recursively with one another, for instance, to iteratively refine requirements.

The purpose of Acquisition Technical Solution (ATS) is to develop design constraints and to verify the technical solution of the supplier. The acquirer provides design constraints to the supplier. The product or service is designed and implemented by the supplier consistent with the acquirer’s design constraints. The Acquisition Technical Solution process area focuses on the following:

Typically, these activities interactively support each other. Some level of design, at times fairly detailed, may be needed for the acquirer to select solutions. Prototypes created by the supplier may be used as a means for the acquirer to gain sufficient knowledge to develop more comprehensive design constraints.

The purpose of Acquisition Validation (AVAL) is to demonstrate that an acquired product or service fulfills its intended use when placed in its intended environment. Validation demonstrates that the acquired product or service, as provided, will fulfill its intended use. In other words, validation ensures that the acquired product or service meets the stakeholders’ intentions and customer requirements.

Validation activities are performed early and incrementally throughout the project life cycle. They can be applied to all aspects of the product in any of its intended environments, such as operation, training, manufacturing, maintenance, and support services. The methods employed to accomplish validation can be applied to acquirer work products (such as customer requirements) and supplier deliverables (for example, prototypes developed by the supplier) as well as to the acquired product and service. The acquirer work products and supplier deliverables should be selected on the basis of which are the best predictors of how well the acquired product or service will satisfy stakeholder intentions.

Whenever possible, validation should be accomplished using the product operating in its intended environment. The entire environment can be used or only part of it. The validation environment therefore needs to represent the intended environment for the product or service as well as represent the intended environment suitable for validation activities with acquirer work products or supplier deliverables.

When validation issues are identified, they are referred to the processes associated with the Acquisition Requirements Development or Project Monitoring and Control process areas for resolution.

The specific practices of this process area build on each other in the following way:

The purpose of Acquisition Verification (AVER) is to ensure that selected work products meet their contractual requirements. Acquisition verification addresses whether the acquired product, intermediate acquirer work products, and supplier deliverables properly reflect the contractual requirements.

The Acquisition Verification process area involves the following: verification preparation, verification performance, and identification of corrective action.

Verification is inherently an incremental process because it occurs throughout the acquisition of the product or service, beginning with verification of the requirements and plans, progressing through the verification of the evolving work products such as design and test results, and culminating in the verification of the completed product.

The specific practices of this process area build on each other in the following way:

Peer reviews are an important method for verification of work products and are a proven mechanism for effective defect removal. An important corollary is to develop a better understanding of the work products and the processes that produced them so that defects can be prevented and process improvement opportunities can be identified.

Peer reviews involve a methodical examination of work products by the producers’ peers to identify defects and other changes that are needed.