The purpose of Organizational Process Definition is to establish and maintain a usable set of organizational process assets and work environment standards.^[4] OPD also has an addition that addresses IPPD. OPD (see Figure 7-2) has one specific goal in the foundation: to create and maintain organizational process assets.^[5] OPD and OPF work together, in that the former provides guidance for an organization on creating processes and their supporting assets, while the latter provides guidance on identifying and planning process improvements.

Figure 7-2. Organizational Process Definition context diagram

The OPD goal—creating and maintaining organizational process assets—is approached through six specific practices. The first establishes the organization’s set of standard processes; typically, this set includes technical, management, administrative, support, and organizational processes. The second practice establishes descriptions of life-cycle models that may be used by each project. The third practice provides tailoring guidelines and criteria for the standard processes, which are in turn used by the projects during the planning phases of the project life cycle.

The fourth specific practice provides a repository for organizational process measurements. An organizational measurement repository supports process performance and quantitative process management as the organization’s capability and maturity improve. It also supports the use of historical data in establishing estimates.

The fifth specific practice establishes a library of process assets that are used by the projects. The process asset library supports projects in planning their project-unique processes through tailoring and implementation of the standard processes, with resultant cost savings. This library may contain document templates, example plans, work products, policies, and other process enablers.

The sixth specific practice provides work environment standards for the organization and projects. Work environment standards support the use of common tools, training, and maintenance when they are employed by the projects on a consistent basis.

The IPPD addition includes one specific goal and three specific practices. The goal provides rules and guidelines that govern the operation of integrated teams; the specific practices are used to satisfy this goal. The first of these specific practices establishes empowerment mechanisms to allow teams to make timely decisions. The second defines rules and guidelines for structuring and forming integrated teams. The third specific practice establishes guidelines to help teams balance their team and organizational responsibilities.

Note that the context diagram in Figure 7-2 (and the other context diagrams in this chapter) shows how typical work products of the practices may be used. Because our objective in this book is to introduce each process area, we won’t discuss every specific practice or every arrow to or from a typical work product in the context diagram. For further information, refer to the model itself or take a formal CMMI training course. Our objective here is simply to introduce each process area.

The purpose of Organizational Process Focus is to plan, implement, and deploy organizational process improvements based on a thorough understanding of the current strengths and weaknesses of the organization’s processes and process assets. OPF uses three specific goals to achieve this purpose: one for determining improvement opportunities, one for planning and implementing selected improvements, and one for deploying the process assets and incorporating lessons learned. The specific practices mapped to each of these goals are shown in the context diagram in Figure 7-3.

Figure 7-3. Organizational Process Focus context diagram

For the first goal (determining process improvement opportunities), the organization establishes and maintains its process needs and objectives. These considerations are based on information that is gathered as part of continuous business outcomes monitoring and process review (e.g., measurement, peer reviews, testing, process and product quality assurance, customer feedback, iteration retrospectives), through periodic appraisal activities (such as CMMI or ISO), and from special case reviews associated with causal analysis or improvement initiatives. The organization periodically reviews its objectives to select and prioritize which improvements to make.

The second goal (planning and implementing selected process improvement activities) is carried out with two specific practices. The organization establishes and then implements process action plans to carry out the selected improvements.

In the third goal (deploying the process assets and incorporating lessons learned), the organization’s set of standard processes and other process assets with changes to them are deployed to existing and new projects, and the assets are incorporated into the process asset library. The use of the standard process assets is monitored on all projects, measurements related to the use of process assets are analyzed, and lessons learned are identified.

The purpose of Organizational Process Performance is to establish and maintain a quantitative understanding of the performance of the organization’s set of standard processes, and to provide the process performance data, baselines, and models to quantitatively manage the organization’s projects. OPP (see Figure 7-4) has one specific goal to establish these performance baselines and models. This “advanced” process area builds on both OPD and OPF by establishing expectations and objectives for the quantitative management of quality and process performance. Selected processes or subprocesses are analyzed, perhaps by examining both performance measures and product measures (e.g., quality).^[6] Process-performance objectives, baselines, and models are then established. The baselines measure the performance of the organization’s standard processes at various levels of detail. Of course, tailoring and other factors (such as product line, complexity, application domain, or team size and experience) can significantly affect the baselines. As a result, the organization may need to establish several different performance baselines.

Figure 7-4. Organizational Process Performance context diagram

The specific practices in OPP are stated at a high level, and particular attention must be given to the informative materials to fully understand the intent of the process area.^[7]

The purpose of Organizational Innovation and Deployment is to select and deploy incremental and innovative improvements that measurably improve the organization’s processes and technologies. The improvements support the organization’s quality and process performance objectives, as derived from the organization’s business objectives. OID (see Figure 7-5) adds further capability to OPD, OPF, and OPP with its two goals: selecting process and technology improvements and systematically deploying those improvements.

Figure 7-5. Organizational Innovation and Deployment context diagram

The CMMI models include technology in the OID process area. Technology is also addressed, at least at the subprocess level and dealing with product technology, in the Technical Solution (TS) process area. In OID, both product- and process-related technologies are deployed to improve the organization.

The first OID goal—selecting improvements—involves collecting and analyzing process and technology improvement proposals. These proposals may come from a variety of places; strategic and operating plans, program risk analyses, capability evaluation results, product defects and errors, industry trends, and customer and user needs and problems are all possibilities. The initiatives proposed may be either incremental or innovative in nature, and the second OID specific practice highlights innovative change.^[8] Once opportunities for change have been identified, they are evaluated through pilot projects (as needed) and then selected for deployment. When selecting opportunities to pursue, factors to consider include needed resources, anticipated benefits, risk analysis, schedule, effects on stakeholders, the approach and tools to be used, and the business case for the change.

The second OID goal—deploying improvements—includes planning and managing the deployment of changes, and then measuring the effectiveness of the new process or technology as well as its effects on other management objectives.^[9]

This process area reminds us that an improvement initiative is like a project and should be managed as such. As we noted with OPP, the practices in OID are stated at a high level, and particular attention must be given to the informative materials to fully understand the intent of the process area.

The purpose of Organizational Training is to develop the skills and knowledge of people so they can perform their roles effectively and efficiently. OT (see Figure 7-6) has two specific goals: one for establishing an organizational training capability and another for providing the necessary training. This process area does not build on the capability level of any other Process Management process area. Rather, OT supports the organization’s strategic and cross-project training needs and ensures that practitioners understand and can correctly use process assets, including organizational standard processes.

Figure 7-6. Organizational Training context diagram

The first goal (establishing an organizational training capability) includes four specific practices. First, strategic training needs are established to guide the overall organizational training. Second, responsibility for each need is assigned to either the organization or the project. Third, a tactical plan is established to ensure that training needs are met. This plan should address training topics, schedules, methods, standards for training materials, resources, roles and responsibilities; in short, it should explain how each of the organization’s training needs will be addressed. The fourth practice addresses the actual establishment of the organization’s training capability, such as developing or obtaining training materials, identifying instructors, and producing a description of the training curriculum.

Under the second goal (providing necessary training), the specific practices focus on delivery (following the tactical plan) of training to the target audiences, maintenance of training records, and assessment of the effectiveness of the organization’s training program.

The purpose of Project Planning is to establish and maintain plans that define project activities. PP (see Figure 7-8) has three specific goals: to establish estimates, to develop a project plan, and to obtain commitments to the plan. PP and PMC work together, in that the former involves the creation of the project plans, and the latter involves tracking progress against the plans. It is through PMC that corrective actions are managed to closure.

Figure 7-8. Project Planning context diagram

In the first goal, which consists of establishing estimates of project planning parameters for the project, the scope of the project is estimated based on a work breakdown structure, and project attributes for work products and tasks are estimated. To set the scope of the planning effort, a project life cycle is defined. Estimates of effort and cost for work products and tasks can then be developed. Subsequently, these estimates are used as the basis for developing the project plans in the second goal—budgets and schedules are established, risks are identified, and plans are created for data management, resources, knowledge and skills needed, and stakeholder involvement.

Obtaining commitments to the plan involves making sure that you understand all the project commitments, reconciling the project plan to reflect available and projected resources, and obtaining commitments from relevant stakeholders responsible for performing and supporting plan execution.

The purpose of Project Monitoring and Control is to provide an understanding of the project’s progress so that appropriate corrective actions can be taken when the project’s performance deviates significantly from the plan. PMC (see Figure 7-9) has two specific goals: one on monitoring actual performance against the plan, and another on managing corrective actions.

Figure 7-9. Project Monitoring and Control context diagram

The first goal—monitor the project against the plan—has five practices that identify what should be monitored and two practices that deal with reviews. The monitoring focuses on the following:

These monitoring efforts are reviewed at both progress reviews and milestone reviews.

Whenever these monitoring activities and reviews find anomalies and needed corrective actions, the second goal provides specific practices to analyze the issues, initiate the necessary corrective action, and manage the corrective action to closure. Note that other CMMI process areas (such as Verification, Supplier Agreement Management, and Configuration Management) refer to this PMC goal and its practices to provide information about managing corrective actions.

The purpose of Integrated Project Management is 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. IPM (see Figure 7-10) has two specific goals in the CMMI for Development constellation; adding IPPD provides another specific goal. The two basic goals relate to actually using the project’s defined process and to coordinating activities with relevant stakeholders. These goals build on the planning covered in PP, by ensuring that the appropriate organizations and people are involved in managing the project. The organization’s set of standard processes, which was developed in the OPD process area, is the basis for the project’s defined process.

Figure 7-10. Integrated Project Management (without IPPD) context diagram

The first IPM goal has six practices that address how the project follows a defined process tailored from the set of standard processes. Establishing and maintaining the project’s defined process is the first step, with the organization’s standard processes serving as a starting point. Next, the organizational process assets from the organizational process asset library are used for planning project activities, establishing the project’s work environment, integrating all plans to describe the defined process, and managing the project using the integrated plans. Finally, the project contributes its work products as appropriate (including measures and lessons learned) to the organization’s process assets for use by future projects and for process improvement activities.

The second basic goal—coordination and collaboration with relevant stakeholders—has three practices, which focus on managing the involvement of stakeholders to satisfy commitments and resolve misunderstandings, tracking critical project dependencies, and resolving outstanding coordination issues.

The addition of IPPD adds one more specific goal: manage the project using IPPD principles (see Figure 7-11). This goal, which is dubbed SG 3, creates an environment for integrated teams to be effective. The first specific practice establishes and maintains a shared vision for the project, together with a strategy for the communication of that vision, including published statements. The subsequent practices focus on organizing integrated teams by determining the appropriate team structure for the project; allocating requirements, responsibilities, and tasks to the teams; establishing the teams; and ensuring that the teams collaborate as appropriate.

Figure 7-11. Integrated Project Management for IPPD context diagram

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. QPM (see Figure 7-12) has two specific goals that build on the goals of PP, PMC, and IPM: using performance objectives to quantitatively manage the project and statistically managing selected subprocesses. The first goal includes specific practices that establish quality and process-performance objectives, compose the project’s defined process based on historical data, select candidate subprocesses that are to be statistically managed, and monitor the project’s performance objectives to determine whether they have been satisfied (with corrective actions identified as needed). The specific practices associated with the second goal define statistical management in CMMI. Measures and analytical techniques are selected, statistical methods are applied to understand the natural bounds of variation for subprocess performance, and selected subprocesses are monitored, so that action can be taken to address any deficiencies in process capability. Finally, the resulting data is maintained in a measurement repository for later use throughout the organization. In this way, QPM expands an existing measurement program (following PMC) with the addition of statistical management techniques.

Figure 7-12. Quantitative Project Management context diagram

The purpose of Risk Management is to identify potential problems before they occur, so that risk-handling activities may be planned and invoked as needed across the life cycle to mitigate adverse impacts on achieving objectives.^[10] RSKM (see Figure 7-13) actually builds on part of the PP process area; that is, a specific practice in PP identifies and analyzes project risks, and the project plan should document those risks. Nevertheless, PP is less systematic and less proactive than the requirements noted in RSKM. Often RSKM is applied outside the project context to manage organizational risks. Several other process areas also reference RSKM.

Figure 7-13. Risk Management context diagram

RSKM has three specific goals that focus on preparation for risk management, identification and analysis of the risks, and handling and mitigation of risks as appropriate. The preparation steps include determining risk sources and the categories used for organizing risks by “bins,” establishing the parameters used to analyze and categorize risks, and developing a risk strategy. The identification and analysis steps focus on identifying risks, and then ranking them based on the analysis parameters. The handling and mitigation of the risks involves developing, implementing and updating risk mitigation plans.

The purpose of Requirements Management is to manage the requirements of the project’s products and product components and to identify inconsistencies between those requirements and the project’s plans and work products. REQM (see Figure 7-14) has one specific goal: to manage requirements and identify inconsistencies with plans and work products. It is the only Engineering process area that is staged at ML 2; all other process areas are staged at ML 3.^[12]

Figure 7-14. Requirements Management context diagram

REQM has five specific practices. To manage requirements, the person or team that receives them needs to develop an understanding with the requirement providers of what those requirements mean before doing anything with them. The manager or team should also obtain a commitment from the people who will implement the requirements. Once the requirements are received and understood, and a commitment is obtained, all changes to the requirements should be managed, including recording change histories and evaluating change impacts. The project should provide for bidirectional traceability of the requirement and the associated work products. Tracing the requirements provides a better basis for determining the ramifications of changes; it also ensures that all requirements have a parent and that the product design covers all high-level requirements. Finally, the project should identify inconsistencies between the requirements and work products. Any corrective action required to fix inconsistencies is accomplished in the requirements development process, the project planning process, or possibly other processes.

The purpose of Configuration Management is to establish and maintain the integrity of work products using configuration identification, configuration control, configuration status accounting, and configuration audits. CM (see Figure 7-15) includes three specific goals that address establishing baselines, tracking and controlling changes, and establishing the integrity of baselines. It is assumed that configuration management can occur at multiple levels of granularity and formality. This process area is closely connected with the CL 2 generic practice to manage configurations; it provides the process to be used when applying that generic practice.

Figure 7-15. Configuration Management context diagram

The first goal—establishing baselines for work products—has three specific practices: identifying the items to be placed under configuration management, establishing a configuration management and change management system, and creating and releasing the baselines. Once baselines are established using a configuration management system, all changes are tracked and controlled in the second goal with two specific practices: The first tracks the requests for changes and the second tracks content changes to the configuration items. The third goal—establishing the integrity of the baselines—has two specific practices: one for keeping records on the configuration items, and another for performing configuration audits to ensure that the baselines are correct.

The purpose of Process and Product Quality Assurance is to provide staff and management with objective insight into the processes and associated work products. PPQA (see Figure 7-16) has two specific goals: objectively evaluating adherence to process descriptions, standards, and procedures; and tracking, communicating, and resolving noncompliance issues. To achieve objective evaluation, some organizations may strive for independent oversight of the processes and work products, perhaps via a quality assurance department. Other organizations may embed the quality assurance function within the process, thus placing greater emphasis on evaluation by peers. CMMI supports both options. This process area is closely connected with the generic practice at CL 2 to objectively evaluate adherence; it provides the process to be used when applying that generic practice.

Figure 7-16. Process and Product Quality Assurance context diagram

The first goal—objectively evaluating adherence of the performed process and associated work products and services to applicable process descriptions, standards, and procedures—is addressed with two specific practices. One conducts an objective evaluation of the performed process against the defined process, and the other performs an objective evaluation of designated work products and services. The second goal—tracking, communicating, and resolving noncompliance issues—is also addressed by two specific practices. The first communicates noncompliance issues with relevant stakeholders and ensures their resolution by progressive escalation, and the second establishes and maintains records of quality assurance activities.

The purpose of Measurement and Analysis is to develop and sustain a measurement capability that is used to support management information needs. MA (see Figure 7-17) has two specific goals: one for aligning measurement activities with information needs, and one for providing measurement results that satisfy those needs. This process area is loosely connected with two generic practices at CL 2. That is, planning the process includes defining measurement objectives, and monitoring and controlling the process encompasses measuring performance against the plan. MA is most successful when the information needs are tied to the organization’s business goals and objectives.

Figure 7-17. Measurement and Analysis context diagram

The practices of the two MA goals provide an eight-step measurement process, in which four specific practices are mapped to each of the two goals. For the first goal, personnel define the objectives to meet the information needs, specify the measures that will be needed to meet the objectives, indicate how the data will be obtained and stored, and determine how the data will be analyzed and reported. For the second goal, they collect the data, analyze and interpret the data, manage and store both the data and the analysis results, and communicate the results to the stakeholders.^[13]

The purpose of Decision Analysis and Resolution is to analyze possible decisions using a formal evaluation process that evaluates identified alternatives against established criteria. DAR (see Figure 7-18) has one specific goal, related to evaluating alternatives using established criteria. Only the key issues for a project would warrant the structured decision-making process of DAR. Possible examples include architectural or design alternatives, make-versus-buy decisions, supplier selection, and tool selection.

Figure 7-18. Decision Analysis and Resolution context diagram

The practices of this process area identify a six-step process for making decisions in a structured manner:

An organization may use DAR for any significant decision that needs to be made. Typically, this occurs in the following circumstances: (1) a customer requires it; (2) the decision relates to a high-risk item or would have a significant effect on costs or schedule; (3) a contract modification might result from the decision; (4) there is substantial stakeholder disagreement on the issue; or (5) the decision may be the subject of a future audit. As a part of the decision-making process, stakeholders can provide much of the needed information. A trade study for making important technical decisions is an example of a formal DAR process. Because following a DAR process expends resources, it should not be used for making decisions with little project impact or little associated risk. In reality, some process is used even in low-level decisions; such a process just isn’t required or expected by the CMMI models.^[15]

The purpose of Causal Analysis and Resolution is to identify causes of defects and other problems and take action to prevent them from occurring in the future. CAR (see Figure 7-19) has two specific goals: one for determining the root causes of defects, and another for addressing these causes to prevent their future occurrence. This process area is closely related to the CL 5 generic practice concerning the root causes of defects and other process-related problems; the processes of CAR should be used when applying that generic practice.^[16]

Figure 7-19. Causal Analysis and Resolution context diagram

For the first goal (determining root causes), two specific practices exist: select the defects for analysis, and perform causal analysis and propose actions to address these problems. For the second goal (addressing the root causes of defects and other problems), three specific practices are provided: implement the action proposals, evaluate the effects of the changes on process performance, and record the data from the CAR activities for subsequent use by other projects in the organization.

The purpose of Requirements Development is to produce and analyze customer, product, and product component requirements. RD (see Figure 7-20) has three specific goals: developing customer requirements, developing product requirements, and analyzing and validating requirements to produce a definition of the required functionality. This process area contains all of the practices related to generating product and product component requirements. It is recursive relative to TS, with alternative solutions being developed to help determine lower-level product requirements.

Figure 7-20. Requirements Development context diagram

Figure 7-20 shows a simplified context diagram for RD, because this process area contains too many specific practices to include in one diagram. Furthermore, Figure 7-20 does not really illustrate how the requirements are developed. The analysis tasks are performed concurrently with the development tasks. Processes developed from RD practices should be designed to meet the needs of the organization, and can represent several different product life-cycle models, such as waterfall, iterative, incremental, and multilevel models.

The development process needs a starting point, and RD’s first goal provides it by developing customer requirements. The first specific practice calls for the elicitation of stakeholder needs, expectations, constraints, and interfaces. Providing information about needs allows the customer (and other stakeholders) to describe the product’s desired function, performance, appearance, and other characteristics. In the second specific practice, the stakeholders’ needs, expectations, constraints, and interfaces are translated into customer requirements.

RD’s second goal addresses the use of customer requirements to develop the product-level and product-component-level requirements. In some cases, these requirements may consist of a system and its subsystems, boxes, boards, software configuration items, software components, and modules. In other cases, they may include processes, subprocesses, or service-related products. The three specific practices for this goal focus on translating the customer requirements into the more technical form of product requirements, allocating the requirements to each component of the product, and identifying interface requirements. One way of handling interfaces is to treat them as if they were the same as the other requirements. Note, however, that a lack of attention to the interfaces often results in defects, which can ultimately lead to rework, cost overruns, and schedule slips.^[18]

In RD’s third goal, the requirements are analyzed and validated as they are developed; this step is critical for the success of a product. The five specific practices that map to this goal involve preparation, analysis, and validation. The specific practices begin with the development of operational concepts and scenarios that detail the way the product will be used, stored, transported, and so forth. These operational concepts then help define the requirements from a broad, in-use point of view, and they establish a definition of the required functionality. Analysis of the requirements ensures that they are necessary and sufficient to meet the objectives of the higher-level requirements and that they are feasible to achieve. In addition, requirements are analyzed to balance stakeholder needs and constraints. The last specific practice addresses requirements validation, which ensures that the resulting product will perform appropriately in its intended use environment.

The purpose of Technical Solution is to develop, design, and implement solutions to requirements. Solutions, designs, and implementations encompass products, product components, and product-related life-cycle processes, either singly or in combinations as appropriate. TS (see Figure 7-21) has three specific goals that address selecting product component solutions, developing the design, and implementing the design. The high-level context diagram in Figure 7-21 shows only the goals for this process area. In the first goal, alternative solutions are developed and analyzed, and the one that best satisfies the criteria is selected. The selected alternative may be used to develop more detailed requirements in the RD process area or designed in the second goal of TS. After the product components are designed, they are implemented together with support documentation in the third goal of TS.

Figure 7-21. Technical Solution context diagram

The first TS goal includes two specific practices. First, the project must develop alternative solutions, as well as criteria for their evaluation. Alternatives are explored to determine the best solution for the product or product component. In some cases, this investigation may result in additional requirements or lead to modification of existing requirements. This activity is usually recursive with the requirements development processes. In the second specific practice, the engineer or team selects the solution that best satisfies the established criteria.

Four specific practices are associated with the second TS goal (developing the product or product component designs). The first practice develops an architecture and a design for the product or product components. These are characterized (in the second specific practice) by means of a technical data package. The third specific practice establishes product component interface solutions, and does so in terms of established criteria. In the fourth specific practice, the project evaluates whether the product components should be developed, purchased, or reused. If the decision is made to purchase a component, the SAM process area establishes the agreement and manages it.

The third TS goal (implementing the product components and generating associated support documentation) has two specific practices. For the first, the project implements the designs for all types of product components—software, hardware, and so on. For the second, it develops and maintains the end-use support documentation that describes how to install, operate, and maintain the product.

The purpose of Product Integration is to assemble the product from the product components; ensure that the product, as integrated, functions properly; and deliver the product. PI (see Figure 7-22) has three specific goals that address preparing for integration, ensuring interface compatibility, and assembling the product components for delivery.

Figure 7-22. Product Integration context diagram

The first goal—preparing for integration—includes three specific practices. First, the project develops the sequence for integration, which assists in the overall planning effort. Second, it establishes the environment for integration. Finally, it defines the procedures and criteria for integration.

The second goal—ensuring that the interfaces (both internal and external) are compatible—has two specific practices. First, the project reviews the interface descriptions for coverage and completeness. Note that interfaces to the environment are included in this practice. Then, the project manages the interface definitions, designs, and changes for the product and product components to maintain consistency and resolve issues.

Four specific practices exist for the third goal—verifying that product components are assembled and that the integrated, verified, and validated product is delivered. After the product components are implemented and unit testing is complete, the integration process begins. The lowest levels of the product are usually integrated first, with the product being assembled in successive stages. In the CMMI, the delivery of the product occurs in the PI process area. First, the project confirms that each component has been properly identified and functions according to its description and that the interfaces comply with their descriptions. This step helps the engineering team avoid problems during assembly of the product components, which occurs in the second specific practice. In the third specific practice, personnel evaluate the assembly according to the procedures, focusing on interface compatibility. Finally, they package the product and deliver it to the appropriate customer.^[19]

The purpose of Verification is to assure that selected work products meet their specified requirements. VER (see Figure 7-23) has three specific goals that address preparing for verification, performing peer reviews on selected work products, and verifying selected work products.

Figure 7-23. Verification context diagram

The three specific practices for the first goal regarding verification preparation resemble the specific practices of PI: select the work products to be verified and the verification methods early in the project, establish and maintain the environment for verification, and define the verification procedures and criteria for selected work products. Verification planning is performed early in the project, because many of the activities associated with requirements development and design (such as analyses, reviews, and demonstrations) involve ensuring that the requirements are, in fact, verifiable.

Three practices are included for the peer review goal. Peer reviews are a specialized verification activity intended to reduce defects in selected work products. Among software developers, they have proven to be a highly valuable technique, and interest in their use by other engineering disciplines seems to be growing. For the specific practices, the project first prepares for the peer reviews (what gets reviewed, by whom, when, and using which review criteria), then conducts those reviews, and finally analyzes the results. Selecting what gets reviewed is a critical step in the preparation stage; the resources needed for conducting the reviews mean that they should remain limited to key work products.^[20]

For the third goal of verifying selected work products, two specific practices exist. First, personnel perform verification according to the verification procedures, capturing results and associated action items. Then, they analyze the results and identify any needed corrective actions based on established verification criteria.

The purpose of Validation is to demonstrate that a product or product component fulfills its intended use when placed in its intended environment. VAL (see Figure 7-24) has two specific goals that address preparing for validation, and then validating the product or product components. Although the validation practices are similar to those used in verification, the two process areas focus on importantly different topics. Validation addresses those activities needed to show that a product fulfills its intended use in its intended environment; verification ensures the work products meet their specified requirements.^[21] An examination of the product in use may show that some of the requirements were not adequately captured.

Figure 7-24. Validation context diagram

The goal of preparing for validation has three specific practices, which mirror those in PI and VER. First, the project selects the products and product components for validation, together with the validation methods. Next, it establishes the environment for validation. Finally, personnel define the procedures and criteria for validation.

The goal of actually performing the validation has two specific practices. First, workers perform the validation according to the procedures to show that the product or product component performs as intended. Then, they capture and analyze the validation results, identifying any problems or unresolved issues regarding intended use or operational need.

The purpose of Supplier Agreement Management is to manage the acquisition of products from suppliers. SAM (see Figure 7-25) has two specific goals: one for establishing supplier agreements, and another for satisfying those agreements. This process area works in cooperation with the TS process area, in which the organization faces the make-versus-buy decision. Once a decision to buy is made, SAM creates the agreement and then manages it from the viewpoint of the developer who is acquiring the component. Product component requirements for the items being acquired are developed in the Requirements Development process area.^[22]

Figure 7-25. Supplier Agreement Management context diagram

To establish supplier agreements (the first SAM goal), the project analyzes and selects the acquisition options to be followed. These could include an external contract, an internal vendor, a customer-supplied item, or use of commercial-off-the-shelf products. Suppliers are then identified and selected, based on project-related criteria. A DAR process may be followed when there are multiple potential suppliers. Once the selection is made, an agreement is established.

To satisfy those supplier agreements (the second SAM goal), the project (as the acquirer) performs the activities specified in the supplier agreements. These include monitoring supplier progress and performance, conducting reviews, and monitoring risks. To make potential issues visible as early as possible, the project selects and monitors critical supplier processes, especially ones that relate to components with key interfaces.^[23] The project evaluates any custom-made work products from the supplier, and conducts acceptance reviews, tests, and configuration audits. Finally, to ensure an easy transition into the project integration effort, appropriate steps are followed to receive, store, and maintain the acquired products.

The purpose of Agreement Management is to ensure that the supplier and the acquirer perform according to the terms of the supplier agreement. AM (see Figure 7-26) has one specific goal, dealing with having the agreement met by both the acquirer and the supplier. AM works in cooperation with other project management process areas to ensure that the project is managed such that suppliers are considered a key part of the overall project.

Figure 7-26. Agreement Management context diagram

Managing supplier agreements includes four specific practices. The first specific practice has the acquirer doing the things that it signed up for in the supplier agreement, including monitoring the project progress of the supplier and any subsequent corrective actions. The second specific practice addresses managing selected critical supplier processes with an eye toward achieving early awareness of potential problems and preventing interface problems. The acceptance by the acquirer of the acquired product or service is the third specific practice, ensuring (in conjunction with stakeholders) that all of the requirements have been met. The last specific practice involves managing invoices to ensure that all payment terms have been satisfied.

The purpose of Acquisition Requirements Development is to develop and analyze customer and contractual requirements. ARD (see Figure 7-27) has three specific goals: developing customer requirements, developing contractual requirements, and analyzing and validating the requirements. ARD works in cooperation with AVER and AVAL to engineer the product being acquired. A close relationship also exists between ARD and SSAD, thereby ensuring that the requirements defined in the solicitation and specified in the agreement are correct.

Figure 7-27. Acquisition Requirements Development context diagram

Developing customer requirements includes the elicitation of stakeholder needs, expectations, constraints, and interfaces, plus their subsequent transformation into customer requirements. Developing contractual requirements in the supplier agreement includes establishing and maintaining contractual requirements based on the customer requirements, and allocating contractual requirements for each supplier deliverable. The analysis and validation activities include establishing and maintaining operational concepts and scenarios, ensuring that the contractual requirements are necessary and sufficient, analyzing risks so as to balance stakeholder needs and constraints, and validating contractual requirements to confirm that the resulting product will perform as intended in the user’s environment.

The purpose of Acquisition Technical Management is to evaluate the supplier’s technical solution and to manage selected interfaces of that solution. ATM (see Figure 7-28) has two specific goals: one to address the evaluation of technical solutions developed by the supplier, and one to perform interface management. This process area works in cooperation with ARD, AVER, and AVAL to manage the product being acquired.

Figure 7-28. Acquisition Technical Management context diagram

The goal for evaluating technical solutions has three specific practices. The first specific practice selects supplier technical solutions for analysis and the methods to be used; the second performs the analysis, holding technical interchange meetings as needed; and the third conducts technical reviews to confirm that products and services will meet user needs and requirements. These reviews, which are defined in the supplier agreement and are intended to improve the supplier’s technical solution, are event-driven milestones in the development process.

The second goal for ATM has two specific practices: one selects the interfaces that will be managed, and the other performs the interface management. By focusing on the interfaces, transition and integration problems may be avoided.

The purpose of Acquisition Validation is to demonstrate that an acquired product or service fulfills its intended use when placed in its intended environment. AVAL (see Figure 7-29) has two specific goals: to prepare for validation, and to validate the products or services. This process area works in cooperation with ARD and AVER to develop the product being acquired.

Figure 7-29. Acquisition Validation context diagram

The goal of preparing for validation has three specific practices, which mirror those in AVER. First, the project selects the products and product components for validation and identifies the validation methods. Next, it establishes and maintains the environment for validation, addressing resources and their availability. Finally, it defines the procedures and criteria for validation, keeping them current as the product or service matures.

The goal of actually performing the validation has two specific practices. First, workers perform the validation according to the procedures to show that the product or product component performs as intended. Then, they capture and analyze the validation results, identifying any problems or unresolved issues. Note that this process area closely mirrors the VAL process area within CMMI-DEV (see Section 7.2.1.5).

The purpose of Acquisition Verification is to assure that selected work products meet their specified requirements. AVER (see Figure 7-30) has three specific goals that address preparing for verification, performing peer reviews, and verifying selected work products.

Figure 7-30. Acquisition Verification context diagram

The three specific practices for the first goal (preparing for verification) resemble the AVAL specific practices: select the acquirer work products and the verification methods early in the project, establish and maintain the environment for verification, and define the procedures and criteria for selected acquirer work products. Verification planning is performed early in the project, as many of the activities associated with requirements development and design (such as conducting analyses, reviews, and demonstrations) focus on ensuring that the requirements are, in fact, verifiable.

The three practices included in the second goal (performing peer reviews) are almost identical to those in the CMMI-DEV version of VER. See Section 7.2.1.4 for a description of these practices.

For the third goal (verifying selected work products), two specific practices exist. First, personnel perform verification according to the verification procedures, capturing results and associated action items. Then, they analyze the results and identify corrective actions based on established verification criteria. As was the case with AVAL, AVER closely mirrors the VER process area within CMMI-DEV.

The purpose of Solicitation and Supplier Agreement Development is to prepare a solicitation package, select one or more suppliers to deliver the product or service, and establish and maintain the supplier agreement. SSAD (see Figure 7-31) has three specific goals that exactly mirror this purpose statement: to prepare for the solicitation and supplier agreement development, to select suppliers, and to establish and maintain the supplier agreements.

Figure 7-31. Solicitation and Supplier Agreement Development context diagram

To prepare for solicitation and supplier agreement development there are four specific practices: potential suppliers are identified, a solicitation package is developed, that package is reviewed to ensure realism, and finally it is distributed and maintained throughout the solicitation. To select suppliers using a formal evaluation, the acquirer selection policies and procedures are followed: proposals from suppliers are evaluated, negotiation plans are developed for each supplier, and after negotiations the suppliers are selected with the results documented. Finally, the supplier agreements are established and maintained by creating a mutual understanding of the agreement between the suppliers and the acquirer, and then documenting and maintaining the agreement.

The purpose of Organizational Service Management is to establish and maintain standard services that ensure the satisfaction of the organization’s customer base. OSM has two specific goals: one to address long-term customer satisfaction, and one to establish and maintain standard services for the organization. Note that OSM is an optional process area in the Services constellation.

To address long-term customer satisfaction, data is gathered about customer satisfaction and the alignment between customer needs and standard services. Subsequently, this data is analyzed to identify opportunities for improvements to the standard services. The needs of the organization’s customers are translated into decisions about which services will be developed.

To establish and maintain the organization’s standard services, the organization defines the set of services and service levels that will be used, approves descriptions of the services that are approved for use, and establishes and maintains both tailoring guidelines and a service repository. In addition to housing services, levels, descriptions, and tailoring guidelines, the service repository may contain related information, such as sales instructions, and lists of proposal authors and contract specialists.

This process area is similar in concept to the OPM process area. Some of the successful practices for these two process areas may be combined within the organization.

The purpose of Capacity and Availability Management is to plan and monitor the effective provision of resources to support service requirements. CAM has two specific goals: preparing for capability and availability management, and analyzing and monitoring both capacity and availability to manage resources and demand. This process area promotes the proactive management of current and future capacity. The first goal prepares for capacity and availability management by establishing and maintaining a strategy regarding the short-term and long-term use of resources; selecting measures, tools, and analytic techniques to support the management objectives; and collecting data to establish the service’s baselines and models. The second goal analyzes and monitors both capacity and availability by looking to the use of resources and services on an ongoing basis, monitoring availability against agreed-upon targets, and reporting relevant data to stakeholders.

The purpose of Service Continuity is to establish and maintain contingency plans for continuity of agreed services during and following any significant disruption of normal operations. SCON has three specific goals: to identify and prioritize essential functions, to establish and maintain the service continuity plan, and to validate the effectiveness of the service continuity plan. This process area addresses practices that help an organization continue to deliver services when its normal operations are interrupted. Note that SCON is an optional process area in the Services constellation.

The specific practices for the first goal (identify and prioritize essential functions) are identifying the organization’s essential functions to ensure service continuity, identifying internal and external dependencies and interdependencies that the organization relies on to provide services, and identifying vital records and databases, key personnel, responsibilities, and needed protections for the service.

The specific practices for the second goal (establish and maintain the service continuity plan) are developing a plan that (if needed) would enable the organization to continue to provide agreed-to services in the face of threats and vulnerabilities, documenting the tests used to validate the effectiveness of this plan, developing training materials and delivery methods in consultation with stakeholders, and maintaining the plan to address changing needs.

The specific practices for the third goal (to validate the effectiveness of the service continuity plan) are training personnel on the service continuity plan, preparing and conducting validation tests, and, based on an evaluation of testing results, identifying areas for corrective action.

The purpose of Requirements Management +SVC is the same as the foundation process area’s purpose, with an additional purpose statement for services: REQM also establishes and maintains written agreements between service providers and customers on service requirements and service levels. (See Section 7.1.3.1 for REQM as a foundation process area.) REQM +SVC has one additional specific goal: establish and maintain service requirements agreements. To achieve this goal, the specific practices have members of the organization analyzing and comparing existing agreements and service data against the requested requirements, and then establishing and maintaining the service requirements agreement, making it available to service providers and customers, and reviewing it as appropriate to create a revised agreement as needed.

The purpose of Problem Management is to prevent incidents from recurring by identifying and addressing underlying causes of incidents. PM has two specific goals: conducting preparation for problem management and identifying and addressing problems.

The goal of preparation for problem management includes specific practices on establishing and maintaining both a strategy and a system for recording problem information. A strategy is not a detailed plan to address an individual problem; rather, the strategy for problem management addresses at—a high level of responsibility—problem reporting, as well as the methods and tools to be used for problem management.

The goal of addressing problems includes specific practices on identifying and recording problems; analyzing, reviewing, and addressing those problems; monitoring problem resolution and (if needed) escalating a problem for increased attention; and communicating problem status, thereby validating that all problems have been resolved.

The purpose of Incident and Request Management is to ensure the timely resolution of requests for service and incidents that occur during service delivery. IRM has two specific goals: preparation for and management of incidents and requests. Incidents are defined as interruptions of the agreed-upon level of service. Requests come from customers, who ask the organization to deliver part of a previously agreed-upon service. This definition includes on-demand requests, such as a query for information or data at any point in time.

Preparation for incidents and requests is addressed by creating and maintaining a strategy and a management system for incidents and requests. This sets the stage for managing them in the next goal.

Management of incidents and requests is addressed by identifying and recording them in the management system; analyzing, reviewing, and managing them; monitoring their resolution; and communicating their status with the submitters.

The purpose of Service Delivery is to deliver services in accordance with service agreements. SD has two specific goals: prepare for service delivery and deliver the services.

Preparation for service delivery is accomplished by preparing a service delivery operational plan and preparing the service systems for delivery. Service systems are developed in the SSD process area (an optional process area discussed in Section 7.4.5.3).

Services are delivered by confirming that the appropriate service systems operate as intended in the environment, consumables as needed to provide the service are acquired, services are delivered in accordance with the delivery plan and are monitored, and the service systems are maintained to ensure continuing service delivery.

The purpose of Service System Development is to analyze, design, develop, integrate, and test service systems to satisfy existing or anticipated service agreements. SSD has three specific goals: develop and analyze service requirements, develop service systems, and test service systems. Note that SSD is an optional process area in the Services constellation. This process area is similar in nature to the Engineering process areas in the CMMI-DEV model.

The first goal (develop and analyze service requirements) is accomplished by developing stakeholder requirements from needs, expectations, and constraints; refining and elaborating those stakeholder requirements so as to develop service and service system requirements; and developing the service system functionality based on the validated requirements.

The second goal (develop service systems) is accomplished by selecting service system solutions from alternatives, developing the designs for service system components, managing internal and external interface definitions and designs, implementing the designs (including the development of end-user documentation), and assembling and integrating the components into the service system.

The third goal (test service systems) is accomplished by establishing and maintaining an approach and an environment for verification and validation, performing peer reviews on selected components, verifying components against their requirements, and validating the service delivery capabilities to ensure that they will meet stakeholder expectations.

The purpose of Service Transition is to deploy new or significantly changed service systems while managing their effect on ongoing service delivery. ST has three specific goals: preparing for service system transition, deploying the service system, and retiring the service system.

Preparing for service system transition includes practices for ensuring the operational functionality and compatibility of the service system in the current operating environment, establishing and maintaining a transition plan, and reviewing that plan with stakeholders to obtain commitments.

Deploying service systems includes practices for establishing and maintaining a baseline, installing the service system in the operational environment, testing the system against operational scenarios, preparing users and service provider personnel for changes in services and the planned service availability, and assessing the effects on stakeholders and delivered services after the system is deployed, including taking corrective action as needed. Installing the service system includes packaging, distribution, integration, and installation of service system components within the operational environment.

Retiring the service system includes practices for planning the removal of the service system from the operational environment, archiving the service system work products as required, and removing the service system from the operational environment.