2.1.1.1 Capability Level 0: Incomplete

Incompletemeans that specific goals are not satisfied for the process area. Also, generic goals do not exist for this level.

2.1.1.2 Capability Level 1: Performed

Performedmeans that needed work is accomplished and that specific goals of the process area are satisfied. At capability level 1, process improvements need to be institutionalized and maintained, or they may be lost completely over a period of time.

2.1.1.3 Capability Level 2: Managed

Managedmeans that your process has been planned and executed, as defined by your organization:

• Includes a team of skilled people

• Produces outputs in a controlled manner

• Involves the stakeholders

• Your process is monitored, controlled, and reviewed

• Includes an evaluation of your process description for process adherence

Process adherence at capability level 2 ensures that your organization retains existing practices during crucial times.

2.1.1.4 Capability Level 3: Defined

Definedmeans that tailoring of processes from your defined processes is done in the organization by adhering to its tailoring guidelines. (You will learn about tailoring later in the book.)

At capability level 3, organizations also contribute experiences to the organizational process assets that are gained during the implementation of processes.

You might wonder how you distinguish between capability levels 2 and 3. Let’s look at the distinguishing factors:

• At capability level 2, either the complete process or some of its descriptions differ from one project to another. In other words, processes are not common throughout the organization.

• At capability level 3, standard processes are common throughout the organization. Processes are allowed to be tailored for a project or the organizational unit. Tailoring is done by following the defined tailoring guidelines for the organization.

At level 3, processes are written in a rigorous manner and are managed proactively. Processes are considered more consistent, and the only noticeable differences are allowed by the tailoring guidelines.

Once an organization achieves capability level 3 in the process areas that were considered for improvement, it can move ahead further on its process improvement path by focusing on implementing the high maturity process areas (i.e., Organizational Process Performance, Quantitative Project Management, Causal Analysis and Resolution, and Organizational Performance Management).

So far we have discussed the capability levels; now, let’s look at the maturity levels.

2.1.2.1 Maturity Level 1: Initial

Initialmeans the processes are ad hoc. Success is dependent on the capability of a few people in the organization who are seen as heroes and not based on the available processes; in the future, when these few heroic people leave the organization, the team is unable to repeat the success.

In a maturity level 1 organization, the products built and services provided work well most of the time; however, the budget and schedule always get impacted and deviate from their documented plans.

Also, it has been observed that level 1 teams overcommit to their clients/customers. This is because, at times of crisis (e.g., an event that impacts the schedule), the whole team abandons the process in order to deliver faster. Due to this, they are unable to repeat the success.

2.1.2.2 Maturity Level 2: Managed

Managedmeans that projects are adhering to organization-defined processes. Team/resources working on the project possess the right skill levels to produce controlled outputs:

• Projects and their work products are monitored, controlled, and reviewed

• Projects and their work products are evaluated for adherence to their process descriptions

• Management is aware of the status of the work products at defined intervals (e.g., at major milestones and at the completion of major tasks)

• Commitments among relevant stakeholders are visible

2.1.2.3 Maturity Level 3: Defined

Definedmeans that processes are well defined, documented, understood, and followed by various means (e.g., whether through procedures, methods or tools). Processes followed on a day-to-day basis are further improved over time at the organizational level:

• Processes at maturity level 3 help to establish a feeling among the team members that consistency is maintained in following the process across the organization or the business-unit level

• Projects perform tailoring on their defined processes as per the tailoring guidelines

Let’s examine the distinguishing factors between maturity level 2 and 3.

At maturity level 2, the complete process or its descriptions can differ from one project to another. In other words, processes are not common throughout the organization.

At maturity level 3, standard processes are common across the organization. Processes can be tailored for one project or organizational unit by referring to the organization’s defined tailoring guidelines.

Just as with capability level 3, the processes for maturity level 3 are written in a rigorous manner and managed proactively. Hence at level 3, processes are considered more consistent, and the only noticeable differences are allowed by the tailoring guidelines.

2.1.2.4 Maturity Level 4: Quantitatively Managed

Quantitatively managedmeans that an organization establishes objectives quantitatively for quality and process performance at both the organizational and project level. It then uses these quantitative objectives as criteria in managing projects:

• Quantitative objectives are defined by assessing the needs of the customer, end users, and organization and process implementers (Figure 2-3 shows an example of this where the measure schedule variance is -10% to 10%, and the measure effort variance is -15% to 15%)

  

  Figure 2-3. An example quantitative objective

• Quality and process performance objectives are viewed via statistical means and managed throughout the life of projects

• Process performance baselines and models are implemented that help to set the quality and process performance objectives; this will help an organization in achieving its business objectives

So, what is the critical distinguishing factor between maturity levels 3 and 4? At level 4, we can predict the process performance.

The project and selected subprocesses are controlled by using statistical and other quantitative techniques. Also, predictions are made by performing statistical analysis on the refined process data.

2.1.2.5 Maturity Level 5: Optimizing

Optimizingmeans that an organization focuses on improving its processes in a continuous manner by understanding its business objectives and performance needs (in quantitative terms).

Also, organizations use a quantitative approach to understand the variation inherent in the process and the causes of process outcomes:

• The goal is to improve the process performance by following an incremental and innovative approach

• Quality and process performance objectives are defined at the organizational level

• Defined processes and supporting technology combine to help organizations achieve the measurable improvements

Here are the critical distinguishing factors between maturity levels 4 and 5:

• At maturity level 4, the organizational and project teams understand and control performance at the subprocess level, and use these results to manage the projects

• At maturity level 5, the organization focuses on managing and improving organizational performance; this is ensured by collecting and analyzing the data from various projects

Let’s summarize the comparison between Capability and Maturity Levels as depicted in the Table 2-1.

2.1.3.1 What Is a Specific Goal?

A specific goal (SG) is unique and present in each process area.

Under each specific goal, there are certain “specific practices” (SP). When we implement the specific practices successfully, then we satisfy the specific goal. Once all the specific goals are satisfied, it means the process area is satisfied.

During CMMI appraisals, specific goals are evaluated to check whether the process area is satisfied.

2.1.3.2 What Is a Specific Practice?

A specific practice is the activity description; when a specific practice is implemented, it helps to achieve the associated specific goal (see Figure 2-7).

Figure 2-7. A specific goal and practice

2.1.3.3 What Is a Generic Goal?

Generic goals are called “generic” because they have the same goal statement, which is common across all 22 process areas.

Generic goals are used during the CMMI appraisals to evaluate whether a process area is satisfied or not satisfied.

2.1.3.4 What Is a Generic Practice?

A generic practice is called such because it is the same practice that is used across all 22 process areas.

A generic practice is present under generic goals. A generic practice contains an activity description that, once implemented, helps in achieving the generic goal of a process area (see Figure 2-8).

Figure 2-8. A generic goal and practice

Visually, the structure of generic goals and generic practices looks like a grid, where the different levels are shown horizontally and the specific goals within that level are shown as a vertical list of boxes with incremented numbers (see Figure 2-9).

Figure 2-9. The structure of generic goals and generic practices

Table 2-2 describes the specific goals and practices for each level, interpreting what each means.

2.3.10.1 Requirements Development

The focus of the Requirements Development (RD) process area is to collect and analyze requirements. We can segregate requirements into three different types:

• Customer Requirements

• Product Requirements

• Product Component Requirements

RD covers the best practices related to developing customer requirements.

2.3.10.2 Developing the Customer Requirements

Here we need to elicit requirements from all the stakeholders’ points of view. It’s important to understand their needs and expectations. Also, we need to proactively identify those requirements which are not communicated or provided by the client/stakeholder, but are essential for the product or product component delivery.

We can use the following techniques to elicit the requirements:

• Interview sessions

• Prototypes

• Brainstorming

• Market surveys

• Use cases

Documents to be maintained include the following:

• Requirement Q&As

• Prototypes

• Survey results

• Meeting minutes

2.3.10.3 Transform the Stakeholder Needs into Customer Requirements

For building customer requirements, you need to consolidate all the inputs/information received from all stakeholders, but also do the following:

• Check whether any information is missing, and update the missing part

• Determine whether any conflicts exist in the requirements

In scenarios where the customer provides only the set of requirements, the customer requirements could conflict with the needs and expectations of the relevant stakeholders. Hence, it is important to resolve the conflict before treating customer requirements as a recognized set of requirements.

Documents to be maintained include documented customer requirements (i.e., a business requirements specification).

2.3.10.4 Develop the Product Requirements

You’ll need to analyze the customer requirements to arrive at detailed product requirements:

• Establish product and product component requirements

• Associate the requirements with product life cycle phases

In scenarios where we chose to follow an iterative or incremental development model, the requirements must be allocated to iterations or increments based on the following criteria:

• Customer priorities

• Technology related issues

• Project objectives

You will also need to document customer functional and quality attributes requirements. This will help when describing what the product will do. Functional requirements have to be described in technical terms, to create the product design.

Examples of quality attribute measures include the following:

• Production of a simple report shall take less than 20 seconds for 95% of the cases

• The system shall be able to process 100 payment transactions per second in peak load

Documents to be maintained include documented technical requirements (i.e., a software requirements specification)

2.3.10.5 Allocate the Product Component Requirements

Next, we will need to allocate the product component requirements; these include the following tasks:

• Allocate requirements to functions

• Allocate requirements to each product components

• Capture design constraints for the product and product components

• Allocate requirements to the delivery increments

2.3.10.6 Identify the Interface Requirements

We will also need to identify interfaces between the functions, as well as ensure that interfaces identified are both external and internal to the product. Also, we need to ensure that requirements are developed for the identified interfaces (e.g., the data characteristics of the software).

2.3.10.7 Analyze and Validate Requirements

We must also validate requirements to ensure that the product being produced will perform as intended in the environment it is supposed to perform in. As the name suggests, this is simply a matter of validating our requirements and helping us prevent the cost of failure.

2.3.10.8 Establish Operational Concepts and Scenarios

We need to document operational concepts and scenarios (i.e., the sequence of events that might occur during product development, deployment, delivery, support (including maintenance and sustainment), training, and disposal.

This means we need to define the environment in which the product or product component will operate, including its boundaries and constraints. One aspect of this is creating use cases.

We also need to establish a definition of required functionality and quality attributes. A functional definition can include actions, sequence, inputs, outputs, or other information that communicates the manner in which the product will be used. Quality attributes can also be important from business needs perspective, and they serve as an input to the design process.

Documents to be maintained include the following:

• Definitions of the required functionality and quality attributes (document these in the SRS)

• Activity diagrams and use cases (document these in the SRS)

2.3.10.9 Analyze the Requirements

Review that the requirements are complete, feasible, realizable, and verifiable. Ensure that any risk assessment conducted with respect to the requirements is documented.

Documents to be maintained include the following:

• A requirements review defects report

• A requirements clarification report

• A risk register

• A risk section could also be added in the SRS

2.3.10.10 Validate the Requirements

You also need to ensure that the requirements are validated by the client/end user before initiating the design/development work. It is important to instill confidence in the client that the requirements collected/defined will be delivered as required in the product.

Examples of validation techniques include prototypes, demonstration/product presentation, simulations, and so on.

The documents to be maintained include the following:

• Documented prototypes

• Presentations

• Meeting minutes

2.3.10.11 Technical Solution

The focus of the technical solution is to design and implement solutions according to the requirements. The Technical Solution (TS) process area covers the best practices related to selecting component solutions, which includes the following tasks:

• Develop solutions for design alternatives that feature current vs. new technologies, COTS products, tools and so on, as required to implement the requirements (there will always be more than one possible solution to implement a requirement)

• Develop the criteria to select the best solution from the multiple alternatives available (i.e., criteria examples are cost, time, product performance, etc.)

• Document the selection criteria for selecting the best/final option among the available alternatives list (i.e., the reasons for selecting a particular option/solution)

Documents to be maintained include reports that evaluate the design, new technology, COTS products, tools, and so on.

Here are a couple things to keep in mind when developing the design:

• Employ techniques and methods known for producing effective design (e.g., prototypes, structural models, object oriented design, and entity relationship models)

• Ensure that design standards are adhered to while preparing the design

Documents to be maintained include the following:

• Product architecture

• Design standards

To establish a technical data package, you need to document the required product components levels:

• The subsystem

• Hardware configuration items

• Computer software configuration items

• Computer software product components

Documents to be maintained include those related to developing high- and low-level design.

Follow these criteria when designing interfaces:

• Define the interface criteria

• Identify the interfaces associated with other product components and external items

• Apply the interface criteria to the design alternatives

• Document the selected interface designs and the rationale for the selection

Documents to be maintained include the following:

• The interfaces in high- and low-level design

• The interfaces evaluation report (i.e., the DAR record)

2.3.10.12 Perform Make, Buy, or Reuse Analyses

Make, buy or reuse analysis is done to determine which product or product component needs to be acquired as part of the project/product delivery. The purpose of this analysis is to understand which product or product component cannot or should not be developed in-house, whether due to its high complexity, the lack of skills of your team members, or any other reasons.

It is also possible that some product or product component is already available as part of the delivery of past projects, and that it could be reused in the current product development.

Hence, by acquiring or reusing product components, you can save time and effort developing the current product or component.

In that vein, we need to do the following:

• Define criteria for when to reuse a product component

• Analyze designs to determine if a product or component should be developed, reused, or purchased

Documents to be maintained include a make, buy, or reuse analysis report. This document should describe how to implement a product design to develop software code. Examples of software coding methods include the following:

• Structured programming

• Object oriented programming

• Automatic code generation

• Software code reuse

During the software code development, the organization needs to adhere to the appropriate coding standards (e.g., language standards like .net and Java) and take these steps to ensure quality control:

• Plan and perform software code peer reviews

• Perform unit testing

Documents to be maintained include the following:

• Source code

• Coding methods

• Coding standards

• Peer review reports

• Unit test cases

• Results

2.3.10.13 Develop Product Support Documentation

To install, operate, and maintain the product, you’ll also need to provide support documentation to the client.

Documents to be maintained include the following:

• User manual

• Maintenance manual

• End user training material

• Online help

2.3.10.14 Product Integration

The purpose of product integration (PI) is to assemble and integrate the product from the product components. We need to ensure that the integrated product behaves properly before we deliver it to the client. Product integration can be done in two ways:

• All the product components can be integrated, tested, and delivered to the client

• The components can be integrated in incremental stages (e.g., if an iterative model is used for product development, then the continuous integration path could be followed to assemble the product components)

The Product Integration process area covers the best practices related to preparing for PI:

• Prepare and maintain an integration strategy

• Product components are available to facilitate product integration

  • Integration has to be conducted in a single build or in incremental builds

  • An integration procedure is defined

  • Features need to be tested in each iteration/build when using iterative development

  • Interfaces need to be managed

  • An integration environment needs to be created

  • Testing tools/equipment need to be created

  • Test results/reports need to be created and evaluated

• Evaluate and select the best integration strategy to be adopted

  • Evaluate and choose the best integration strategy method from the options available (use the DAR method for evaluation)

  • Upon selection of the best option according to you, document the reasons for selecting the option

Documents to be maintained include the following:

• The product integration strategy

• The DAR record (for evaluating the options for the integration method)

Follow these steps to create the product integration environment:

• Assess the requirements for creating the environment

• Enumerate all the procedures required to verify the environment

• Conduct a make or buy analysis (whether to create or buy the environment from outside

• Create your own environment if the environment cannot be acquired from an outside source

Documents to be maintained include anything that supports the fact that the integration environment is available and has been verified.

To that end, you’ll want to create a verification checklist:

• Create the procedures and criteria for product integration

• Create procedures to conduct the integration in a planned manner

  • Indicate the number of iterations to be performed

  • Define the integration sequence

  • Specify the level of testing to be conducted

  • Spell out the defined threshold for performance deviation

  • Indicate the interfaces to be verified (e.g., human-machine interfaces, message interfaces, electrical interfaces, or climatic interfaces)

  • Specify the resources required (i.e., testing tools, staff, environment availability, etc.)

Documents to be maintained include the integration procedure (describing your integration criteria).

This will help you ensure that your interfaces are compatible. You’ll also need to review all interfaces to ensure they are correctly identified and that their coverage is complete.

Documents to be maintained include the review report or record (all identified issues should be closed).

Take these steps to manage the interfaces:

• Ensure that interfaces remain compatible with each other for the entire product life cycle

• Resolve any identified issues

Documents to be maintained include those that cover the relationship tables that describe the relationship of product components with each other and the external environment.

Here’s an agreed upon list of application program interfaces (APIs) that cover when product components are assembled and delivered:

• Perform checks to determine whether the product components delivered are ready for integration (i.e., a readiness checklist to provide the component acceptance)

• Perform checks to ensure whether integration environment is ready and available

• Assemble the product and product components by following the defined procedures and criteria

• Change/revise the integration procedure if the criteria in the defined procedure does not work

Documents to be maintained include the following:

• A readiness checklist to provide the component acceptance

• Sanity verification/tests

• Created builds

• A revised integration procedure (if required)

You will need to take the following steps to evaluate the assembled product:

• Ensure that the assembled product (e.g., software build, the laptop, and the charger) will work in its intended or end-user environment

• Perform checks/tests to evaluate the assembled product in the end-user environment or in a simulation environment

• Record the test results

• Analyze and correct interface errors, if any

Documents to be maintained include the integration/interface test reports.

Take the following steps to package and deliver the product or product component:

• Once the software build or hardware components are ready, deliver the same to the client as a package (e.g., deliver the software build package in a CD or online file transfer, and provide the hardware package in suitable packaging material)

• Provide the user/client appropriate and sufficient information to take advantage of the delivered material

• Explain what the software build contains (e.g., what modules, patches, and open bugs, if any)

• Provide an installation guide that covers the steps for the user to download and install the delivered software build

• Explain what the hardware package box contains (e.g., servers, laptops, or desktops)

• Provide an installation guide for the user to install the delivered hardware

Documents to be maintained include the following:

• A software build note

• An installation/user guide

• A delivery note that covers software modules, software patches, bugs, hardware, and so on)

• A confirmation receipt for the delivery note

2.3.10.15 Validation

Validation (VAL) is performed along with the client or by the client. The Validation process area covers the following best practices related to preparing for validation:

• Select the product or product components to be validated/tested

  • Product and components include several types of items, like software modules and hardware

  • Technical documents like requirement specifications (i.e., business requirements, software/system requirements, etc.)

  • Design documents (i.e., high and low level)

  • User interfaces (i.e., product integration)

  • User manuals

• Select a validation method for validating the product or product components; there are several possible validation methods

  • A prototype demonstration

  • Tests of products and product components by end users and other relevant stakeholders

  • Formal reviews of technical documents

• Create an environment for performing validation

  • Identify requirements for creating an environment for validation

  • Identify test equipment and tools for performing validation

• Create procedures and criteria for performing validation

  • Create testing procedures

  • Create evaluation procedures

• Perform validation

  • Perform tests on the product or its components as per the defined validation procedure

  • Perform technical documents validation with client

  • Collect validation/test/evaluation results

Documents to be maintained include the following:

• A validation procedure

• Test reports

• Analysis of validation results

• Comparisons of planned vs. actual results

• Analysis of defect data

• Analysis of product or product components which are not working

2.3.10.16 Verification (VER)

Verification is performed internally by the project team members, without involving the client. The Verification process area covers the best practices related to preparing for verification:

• Performing verification requires using various methods

  • Use peer reviews, walkthroughs, simulations, testing, and demonstrations

  • Identify work products to be verified

  • Identify or define a verification method

  • Create an environment for performing verification

  • Identify requirements for creating a verification environment

  • Identify test equipment and tools for performing verification

  • Create procedures and criteria for performing verification

• Performing peer reviews and preparing for peer review

  • Identify members to perform the peer reviews

  • Identify peer review method to be used

  • Create the peer review checklist to be used during the peer review

  • Ensure that entry and exit criteria for the peer review is defined

Documents to be maintained include a peer review checklist.

You can conduct peer reviews using the following methods:

• Review work products and identify defects/other issues

• Document review comments/defects/other issues

• Identify action items resulting from peer reviews

• Communicate action items or any issues to relevant stakeholders

• Ensure that the defined exit criteria for the peer review is met

• If the criteria isn’t met, then perform one more round of peer review to meet the exit criteria

Documents to be maintained include a peer review comments/defects report.

The peer review data describes the preparation, conduct, and results. You need to analyze the data in terms of the types of defects:

• Types of defects

• Peer review data analysis report

• Verify selected work products

  • Perform verification of work products (e.g., unit tests and system tests)

  • Record results of verification/tests

  • Identify action items for closure of identified issues

Documents to be maintained include the following:

• Test reports

• Action item log/register

Take these steps to analyze the results of the verification activities:

• Analyze the planned vs. actual result

• Analyze defects data

You’ll need to maintain an analysis report with the following information:

• An organizational performance management (OPM)

• An organizational process definition (OPD)

• An organizational process focus (OPF)

• An organizational process performance (OPP)

• An organizational training (OT)

2.3.11.1 Organizational Performance Management (OPM)

The Organizational Performance Management (OPM) process area helps you manage business performance and maintain business objectives.

The purpose of OPM is to periodically review and revise the business objectives, along with quality and process performance objectives. It is important to evaluate the business objectives to ensure they are relevant as of today and aligned with the business strategies. For example, you might compare the current business objectives with their actual performance results:

• Ensure that revised business objectives are reviewed and approved by the senior management

• Ensure that revised business objectives are communicated to all

Documents to be maintained include the following:

• A revised business objectives sheet

• A revised quality and process performance objectives sheet

• An analysis of process performance data

On a periodic basis, we need to review the quality and process performance objectives to determine whether the organization is able to meet the current defined business objectives.

For example, if cycle time is one of the critical business objectives, then we need to collect the data from different cycle times and analyze the overall cycle time data with the defined value. If the value matches or is around the defined value, then the organization has the capability to achieve the business objective; otherwise, the organization should revise the business objective value/threshold:

• Identify gaps in the quality and process performance

• Identify if there is any associated risk due to not being able to meet a given business objective

• Communicate the results of process performance and risk analysis to senior management

Documents to be maintained include a report that captures the following:

• Current performance capability vs. defined business objectives

• Identified gaps in process performance

• Identified risks, if any

• Identified potential areas for improvement

• Documented rationale for selecting the improvement area

• Analyzed benefits for implementing the improvement area

You need to communicate to all the relevant stakeholders about implementing the improvement area. In that vein, you’ll need to maintain a report that captures the potential areas of improvement:

• Select improvements for implementation

• Elicit improvements from the suggested list (sources could be business objectives, processes, defect causes, etc.)

• Identify improvements as incremental or innovative

  • Incremental improvements are simple and inexpensive to deploy, and may not require rigorous validation (e.g., adding one checkpoint in peer review checklist or a minor update in the tool)

  • Innovative improvements take a more transformational approach to performance improvements

Incremental and innovative improvements are identified by experienced people who have spent a long time in process and technology, or they are identified by a team of experts whose job is to find innovative improvements. These experts can take the following steps:

• Investigate and analyze improvements which may improve process and technologies within the organization

• Perform analysis in terms of improvement benefits (i.e., quantifiable improvement benefits)

• Evaluate the implementation cost, effort, and resources required

• Analyze and document the implementation risks or barriers, if any

• Identify and document the validation method for the deployment of improvements

Documents to be maintained include the following:

• Selected improvement proposals

• Your improvement validation procedure

You must also validate any improvements made:

• Develop a plan for validation (e.g., target projects, a schedule tracker to report results, and measurement activities)

• Review the plan with relevant stakeholders and get agreement on the plan

• Perform validation in an environment similar to the real deployment environment

• Track the validation plan

  • Review and document validation results

  • Must meet the quantitative criteria defined for the improvement

Documents to be maintained include the following:

• A validation plan

• A validation plan tracker

• A validation results report

Once you validate the plan and have a system in place for tracking and reporting on it, you’ll need to take steps to select and implement the improvements for deployment:

• Select and prioritize improvement for deployment

• Update the organization process assets

Documents to be maintained include the following:

• Selected improvements deployment list

• Updated organization process documentation

And the next step is to deploy the improvements:

• Plan the deployment for each improvement

• Determine the target population for deployment

• Establish measures and objectives for each deployment to determine the success of the deployment

• Review and agree upon the deployment plan with the stakeholders

Documents to be maintained include a deployment plan for managing development.

Follow these steps to monitor your deployment:

• Use training materials to train the people during the deployment

• Ensure that deployment is completed in accordance with the deployment plan

• Document and review deployment results

You will also need to maintain the following documents related to your deployment activities:

• Documented results of deployment activities

• Training material

Finally, you will need to evaluate the effect of your improvements:

• Measure each improvement’s defined achievement criteria against the objective

• Measure and analyze the progress of achieving the organization quality and process performance objective

Documents to be maintained include those that measure the effects of each deployment.

2.3.11.2 Organizational Process Definition

The purpose of the Organizational Process Definition (OPD) process area is to define and maintain process assets to be used in the organization by the staff and management. This is also where you define and maintain work environment standards, along with the rules and guidelines for teams.

Follow these steps to establish organizational process assets:

• Establish standard processes

• Define the policies, procedures, templates, guidelines, checklists, and so on to be used in the daily work

• Ensure that critical attributes are present in each process (e.g., the process role, entry criteria, inputs, verification points, outputs, and process and product measures)

• Specify the relationship among process elements (e.g., the order and interface among the process elements)

• Ensure that peer reviews are done on the standard processes

• Revise the standard processes when and as needed (e.g., any improvements are identified in the standard processes)

Documents to be maintained include the following:

• Documented policies

• Procedures

• Templates

• Guidelines

• Checklists

Define and maintain various life-cycle model descriptions

• Select life cycle models based on the project needs of the organization (e.g., waterfall, iterative, spiral, and incremental)

• Describe and document the life-cycle models

• Perform peer review on the life-cycle models

• Revise the life-cycle models when and as needed

Documents to be maintained include documented life-cycle models.

Next, you need to define the tailoring criteria and guidelines:

• Define the criteria and procedure for tailoring the organization standard processes (e.g., modifying a life-cycle model and modifying or replacing process elements)

• Define the process for submission and obtaining the waiver approval from the organizational standard processes

  • Document the tailoring guideline

  • Peer review the tailoring guideline

  • Revise the tailoring guideline when and as needed

Documents to be maintained include the documented tailoring guidelines.

Follow these steps to form the organization measurement repository:

• Identify the organization or senior management needs for storing, retrieving, and analyzing the measurements

• Identify measures which are common for the standard processes (e.g., the work product size, effort and cost, and test coverage)

• Create and update the measurement repository regularly

The measurement repository comprises the following functions:

• Analyze and interpret the measurement data among projects

• Help new projects to quickly identify and access data from the repository by providing meaningful context

• Help improve the accuracy of project estimates by using a project’s own historical data (and the historical data of other, similar projects)

• Define procedures for how to store, update, and retrieve measures

• Update the relevant measure’s information in the measurement repository

• Ensure that the contents of the measurement repository are available to the relevant/authorized stakeholders

• At regular intervals, revisit the measurement repository, measures list, and procedures when and as needed

Documents to be maintained include documented and analyzed measurement data.

You will need to form the organizational process asset library. This involves first designing the process asset library, and then deciding which items to be included in the asset library (e.g., policies, procedures, templates, guidelines, checklists, training materials, and lessons learned). Follow these steps:

• Define the criteria for including the items in the library

• Document the procedures for storing, updating, and retrieving the items

• Add the items into the library and list them for easy access by the project and various other teams

• On a periodic basis, review the use of each item

Documents to be maintained include a documented process asset–master list (i.e., a list of items in the process asset library).

Follow these steps to define the work-environment standards:

• Identify and follow the work-environment standards that are appropriate for use in the organization

• Revise the work environment-standards on a periodic basis and fill the gaps wherever necessary

Documents to be maintained include documented work-environment standards.

Following these steps will help you establish rules and guidelines for teams:

• For timely decision making, empower the teams by documenting and deploying organizational guidelines

• Define the rules and guidelines for structuring and forming teams

• Define the rules and guidelines for how teams will work in a collective manner (e.g., how the work will be accomplished, who will perform reviews and approve the work, and how the resources and inputs will be accessed)

Documents to be maintained include documented rules and guidelines for your teams.

2.3.11.3 Organizational Process Focus

The Organizational Process Focus process area (OPF) enables you to plan, implement, and deploy organizational process improvements by following these steps:

• Determine process improvement opportunities

• Determine strengths, weaknesses, and improvement opportunities by following a standard or model (i.e., the ISO 9001 or CMMI model)

• Establish organizational process needs

  • Identify and examine the process model or standards that are applicable to the organization (e.g., CMMI or ISO 9001)

  • Document the organization’s process needs and objectives

Documents to be maintained include those that document the organization’s process needs and objectives.

Here is how you appraise the organization’s processes:

• Perform appraisals to identify processes which need improvement and to satisfy the needs of a customer-supplier relationship

• Obtain buy-in from the senior management for the appraisal sponsorship

• Define the scope of the appraisal (e.g., a single business unit, a site, or the whole organization) for selected projects and functions

• Determine the method for the process appraisal (i.e., the appraisal method is different for CMMI and ISO 9001, so it’s necessary to know the need of each appraisal type)

  • Plan, schedule, and conduct the process appraisal

  • Document and deliver the appraisal results or findings

Documents to be maintained include the following:

• A plan for organization process appraisal

• An appraisal for findings results/recommendations

At this stage, you need to identify the organization’s process improvements:

• Determine the improvements for the candidate process

• Review and use appropriate techniques to identify candidate process improvements

  • Customer satisfaction survey results

  • Processes

  • Lessons learned from implementing processes using inputs from senior management and by conducting the process appraisals

• Prioritize the candidate process improvements

  • Perform the cost-benefit analysis

  • Identify and document each process improvement with a priority

Documents to be maintained include those that document the process improvements to be implemented.

The next step is to plan and implement your process actions; here’s how you define process actions plans:

• Process improvements to be addressed

• Process improvement infrastructure

• Process improvement objectives

  • Any piloting that needs to be done

  • Resources and schedules

  • Any identified risks to be tracked

• Set the process action teams to implement actions

Documents to be maintained include those related to your approved process action plans.

Follow these steps to implement process actions plans:

• Negotiate and document commitments among the process action teams

• Track progress and commitments, and conduct joint reviews with the relevant stakeholders

• Plan pilots, if needed

• Identify and track issues to closure

• Ensure that the implemented process-improvement plan has resulted in the achievement of the process-improvement objectives

You will need to maintain the following documents:

• The documented commitment of the process action teams

• A progress report for the improvement plan

Follow these steps to create plans for pilots:

• Deploy organizational process assets and incorporate appropriate experiences

• Deploy organizational process assets throughout the organization or the business unit

  • Identify how organizational process assets will be made available to the teams (e.g., via a web site)

  • Ensure that process training is delivered to all the teams

  • Identifying how changes to organizational-process assets are communicated

• Deploy standard processes

  • Identify projects in the organization which are starting up

  • Identify current active projects which could benefit from the deployment of standard processes

  • Set the plans to implement the deployment of standard processes

  • Assist projects in identifying and adapting the tailoring on the standard processes

  • Maintain the tailoring records

  • Whenever standard processes are improved, identify the projects which should implement the changes as per the improved processes

Documents to be maintained include the following:

• The organization’s list of projects and the status of process deployment for each

• Guidelines to deploy the standard processes on new projects

• Tailoring records

Once you decide how to deploy your process assets, you will need to monitor the implementation:

• Monitor projects in which standard processes are deployed

• Review process artifacts created during the life of each project to ensure that all projects are making appropriate use of the organization’s set of standard processes

• Conduct process compliance checks to gauge how well standard processes have been deployed

• Identify and track any deployment issues to closure

Documents to be maintained include the following:

• Reports of process implementation monitoring on projects

• Process compliance audit reports

• Results of reviews of selected process artifacts; these get created as part of process tailoring and implementation

Next, you’ll need to follow these steps to incorporate experiences into the organizational process assets:

• Conduct periodic reviews to check the effectiveness and suitability of the organization’s set of standard processes

• Obtain feedback from the staff members of the organization who are using the standard processes

• Identify the lessons learned when defining, piloting, implementing, and deploying organizational processes

• Analyze measurement data obtained by using the common set of measures

• Appraise processes, methods, and tools to develop recommendations for improving organizational process

• Establish and maintain records of the process-improvement activities conducted across the organization

Documents to be maintained include the following:

• Process-improvement proposals

• Process lessons learned

• Records of the organization’s process-improvement activities

2.3.11.4 Organizational Process Performance (OPP)

The Organizational Process Performance (OPP) process area defines organizational quantitative objectives and establishes the process performance baseline and models to quantitatively manage the projects.

Follow these steps to establish performance baselines and models:

• Define the quantitative objectives for quality and process performance at the organizational level

• Set quantitative objectives for process and subprocess measurements (e.g., effort, cycle time, and defect density)

Documents to be maintained include those related to the organization’s quality and process performance objectives.

Actually selecting processes or subprocesses requires following these steps:

• Define the criteria for the selection of a process or subprocess, including examples like the following:

  • The process or subprocess is strongly related to key business objectives

  • The availability of historical data is relevant to the process or subprocess

  • The process or subprocess will generate data to enable statistical management

• Select the subprocesses and document the rationale for their selection

• Establish and maintain traceability between the selected subprocesses, quality and process performance objectives, and business objectives, including examples like the following:

  • Subprocess mapping with quality and process performance objectives

  • Subprocess mapping with the business objectives

Documents to be maintained include a list of processes or subprocesses identified for process-performance analyses.

Follow these steps to establish process-performance measures:

• Establish measures for both product and process attributes, based on the selected process or subprocess

• Possible criteria for selecting such measures can include the following:

  • The relationship of measures to the organization’s quality and process performance objectives

  • Coverage that measures provide over the life of the product or service

  • The frequency at which observations of measures can be collected

• The operational definitions for the selected measures from the organization’s set of common measures

2.3.11.5 Establish Process Performance Models

Process-performance models can help an organization to estimate or predict the value of a process-performance measure. Projects can use them for estimating, analyzing, and predicting the process performance of their defined processes.

Examples of process-performance models include the following:

• Regression models

• Monte Carlo simulation models

You can create process performance models by referring to the organization’s standard processes and process performance baselines. Follow these steps to do so:

• Review process-performance models with relevant stakeholders and get their agreement on the same

• Revise process-performance models whenever required (e.g., when processes are improved/updated)

Documents to be maintained include the process-performance models.

2.3.11.6 Organizational Training

The purpose of the Organizational Training (OT) process area is to provide skills and enhance the knowledge of the staff, in order to help them perform their roles in an efficient manner. Follow these steps to establish an organizational training capability, which will help ensure that the organization’s strategic training needs are identified.

Sources of strategic training needs include the following:

• An organization’s standard processes

• An organization’s strategic business plan

• An organization’s process improvement plan

You will also need to perform regular skill assessments. Categories of training needs include the following:

• Engineering (e.g., requirements analysis, design, testing, configuration management, and quality assurance)

• Team building

• Leadership

One of the most important aspects of training a staff is to perform ongoing needs analysis:

• Identify which training which will be the responsibility of the organization and which will be left to the individual project or support group

• Analyze and negotiate how training needs identified by projects and support groups will be met

• Document commitments from the staff for providing training support to projects and support groups

You need to maintain documents that cover common project and support group training needs.

Outlining training commitments involves creating and maintaining an annual training plan. Setting the content of the plan includes spelling out the following:

• Training topics

• Methods used for training

• Training tasks

• Roles and responsibilities

• Schedules based on training activities

• Required resources (e.g., tools, facilities, environments, staffing, skills, and knowledge)

You’ll need to document the commitments from those who are responsible for implementing and supporting the plan, and then revisit the plan and documented commitments whenever necessary.

You’ll need to maintain an annual training plan for the organization.

2.3.11.7 Establish a Training Capability

You’ll need to select the appropriate method to satisfy organizational training needs. Examples of possible training approaches include the following:

• Classroom training

• Self-study

• Formal apprenticeship

• Mentoring programs

• Structured on-the-job training

Following these steps will also help you to establish an appropriate training plan:

• Assess the need to develop training materials internally or to acquire them externally

• Develop or obtain qualified instructors or mentors

• Maintain the training calendar (e.g., topics to be covered, training objectives, and intended audience)

• Revise training materials and supporting artifacts, as necessary

Documents to be maintained include your training materials and supporting artifacts.

Follow these steps to provide training for your organization:

• Identify those staff members who need to attend trainings and are necessary to execute their roles effectively

• Schedule trainings, including any resources, as necessary (e.g., facilities and instructors)

• Track the training delivery against the plan

Documents to be maintained include the delivered training course.

You’ll need to establish and maintain records of your organizational training, including the following:

• Keep records of participants who successfully completed training courses, as well as those who were unsuccessful

• Keep records of all staff waiver requests

• Make training records available to the appropriate people

Documents to be maintained include the training records.

You’ll need to assess the effectiveness of the organization’s training program and build a mechanism to assess the effectiveness of each training course, as per the defined objectives.

Here are some methods you can use to assess training effectiveness:

• The post-training feedback of participants

• Surveys of manager satisfaction, including ratings

• Assessment through courseware provided

Documents to be maintained include the following:

• Training effectiveness surveys

• Instructor evaluation forms

• Training examinations

2.3.12.1 Causal Analysis and Resolution

The Causal Analysis and Resolution process area helps you analyze causes and problems in both negative and positive ways. If there is a negative impact, this process area can help you prevent the causes or problems from reoccurring.

If a cause has a positive impact, this process area can help you incorporate the cause into processes in a way that contributes to more successful outcomes in your organization. This will help in improving/repeating the performance of the process.

To begin, you need to figure out the causes of selected outcomes. You might be wondering why you are interested only in selected outcomes. This is because not all outcomes have an equal impact, and only some impacts require an action.

The next step is to select outcomes for performing the analysis. We can initiate/plan analysis in two ways:

1. Trigger an event

2. Execute a periodic/planned activity at the beginning of a phase or task

You’ll need to gather data for analysis (real time/current data would be best for this analysis). Types of data to gather for this include the following:

• Customer or end user reported defects

• Peer review comments/defects

• Test defects

• Process capability problems

• Customer feedback points/low ratings

After the selecting the type of data to analyze, you need to select the outcomes to analyze further. Methods which could be used to select outcomes include the following:

• Pareto analysis

• Histograms

During the selection of outcomes, focus on their source, impact, frequency of occurrence, the cost of performing the analysis, the required time and resources needed, and so on.

Also, clearly define the scope of analysis, improvement expected, the stakeholders that will be affected, and so on.

At this point, you’re ready to analyze the causes:

• Perform root cause analysis with members who are responsible for performing the task

• Identify root causes using appropriate methods

  • Cause and effect (fishbone) diagram

  • Check sheets

• Group the causes based on their identified root causes

  • Inadequate training and skills

  • Making mistakes in procedures

• Create an action plan

  • Address negative causes and prevent them from reoccurring

  • Incorporate best practices into the processes

Examples of preventive actions include the following:

• Training

• Tools

• Methods

Examples of best practices include the following:

• Create an activity checklist to avoid common problems

• Update the process to remove error-prone steps

• Automate part or all of a process

Documents to be maintained include an action plan. This means you’ll need to analyze and select an action plan for implementation.

It is important to analyze and select a variety of factors are when implementing your plan. Factors to analyze might include timelines, cost, stakeholders involved, benefits expected, and so on.

Implement an action plan to accomplish the following:

• Track the plan (i.e. tasks, people, etc.)

• Review results

• Track action items to closure

Let’s walk through what an improvement action plan might look like when using a new tool. Following these steps will help you evaluate the effect of implemented actions:

• Measure and analyze the change in performance of affected processes

• Review the before and after analysis of the performance

• Determine whether the change in performance has brought a positive impact (i.e., does it help you meet project quality and process performance objectives?)

• Plan an appropriate action if the change in performance does not help you achieve the expected project quality benefits

Documents to be maintained include the following:

• An updated plan

• An updated action item log/register

• A before-and-after process performance analysis report

Be sure to record your causal analysis data:

• The purpose of this is to make the data available to other projects, so that they can use/refer to the data in order to achieve similar results

• Once the implemented action plan is found to be effective, submit the information to the organization for inclusion in the organizational processes

Documents to be maintained include the following:

• Causal analysis data

• An improvement proposal

2.3.12.2 Configuration Management

The Configuration Management (CM) process area helps you accomplish several tasks:

• Identify configurable items

• Perform configuration control

• Maintain the integrity of baselines

• Maintain configuration status accounting

• Conduct configuration audits

• Establish baselines for work products

• Identify configurable items

  • Configuration items could be hardware and equipment, as well as software and documentation

  • The criteria for selecting a configurable item are based on whether a work product is expected to change over time (e.g., is there a change in the requirements?)

Examples of configurable items include the following:

• A requirement specification

• Design

• Source code

• Test plans and procedures

• Tools

For each configurable item, assign a unique identification mark (e.g., Design_<client name>_1.0.doc). You’ll need to decide when to place each configuration item under a configuration management. Here are some examples:

• Work product test readiness

• A project-lifecycle phase

• The degree of control analyzed on each work product

• An owner assigned for each configuration item

Documents to be maintained include a configuration-management plan.

2.3.12.3 Create a Configuration-Management System

You’ll need to manage multiple levels of control for the work product. Examples of this include the following:

• Uncontrolled: Changes can be done by any staff member

• Work in progress: The author is controlling the changes

• Released: Changes are controlled by authorized personnel only; when any changes are made, the relevant stakeholders are updated

Following these steps will help you build an effective configuration-management system:

• Manage access control for each project member; the goal is to ensure that only authorized people have access to the relevant project folders or configuration management system (i.e., CVS, VSS, etc.)

• Store, update, and retrieve configuration management records

• Create release baselines for internal use, as well as for delivery to the customer

  • A software baseline might include requirements, design, source code files, build files, and user documentation

• Obtain approval from the change control board (CCB) for the creation and release of baselines for configuration items

• Track the configuration items which are in a baseline state

You will also need to track and control changes:

• Track change requests for configuration items

• Track the change requests received in a change request tracker sheet/tool

• Perform impact analysis based on the received change request

• Set the priority for each received change request

• Review change requests in the CCB meeting and get approval from relevant stakeholders

• Track the status of each change request until closure

You will also need to track change requests for configuration items:

• For each configuration item, control the changes throughout the project or service life cycle

• Obtain approval from CCB members before updating a configuration item and placing it in the configuration management system

• All check in and check out should be done properly, without losing the previous versions

• Document the reasons for making the changes to a configuration item

• Following these steps will help you establish the integrity of a baseline:

  • Ensure that each configuration item status is known, and that recovery of previous versions is possible

  • Ensure that relevant stakeholders are aware of the configuration status of configuration items

  • Ensure that the difference between the previous and the current baseline is known

  • Ensure that you are using the latest version of the baseline

Documents to be maintained include the following:

• A change log

• Change requests

You can track configuration status by performing configuration audits:

• Check and ensure that configuration items are complete and correct in the configuration-management system

• Check and ensure that configuration management standards and procedures are followed

• Ensure that all configuration audit findings are closed

Documents to be maintained include a configuration audit report that shows the status of your findings.

2.3.12.4 Decision Analysis and Resolution

The Decision Analysis and Resolution (DAR) process area enables us to analyze possible decisions during the project by using formal evaluation techniques/methods. The evaluation method will help us evaluate the alternatives identified, and then complete the process by choosing the best alternative available. We will need to do the following:

• Evaluate alternatives

• Create guidelines for decision-making analysis

Creating the guidelines is important, as it will help us to decide which decisions need to be evaluated using the formal evaluation technique/method. Only some decisions require evaluation because not every decision is significant enough to be evaluated through the formal evaluation process.

Here are some sample points that might be mentioned in the guidelines; these can help in determining which decisions to be put under the formal evaluation process:

• Issues which can lead to medium- to high-impact risk

• Decisions required for changing the work products placed under configuration management

• Decisions which could lead to delays over a certain amount of time

• Decisions which can affect achieving the objectives of the project

Here are some activities for which the formal evaluation process could be used:

• To procure material

• To design alternative decisions

• To make decisions on the cycle time or response time of a process

Documents to be maintained include a guideline document, which covers when to use the formal evaluation process.

2.3.12.5 Establish Evaluation Criteria

The guideline document is the basis for evaluating alternative solutions. Each defined criteria will be given a ranking, and the highest ranked criteria get more weight in the selection process:

• Define the criteria for evaluating alternative solutions

• Rank the criteria and define the range and scale

• Rank and assess each selected criterion during the evaluation

• Document the rationale/reasons for choosing the selected criteria

Documents to be maintained include a guideline document that covers the criteria, with rankings that you can use to identify alternative solutions.

You can search the alternative solutions both within and outside the organization. Within the organization, you can determine whether any other business unit or department has already worked on the solution. And outside the organization, you can determine if you can procure a ready-made solution which can be plugged into the existing, running system. Brainstorm with a technical and/or experienced member of your teams to identify suitable alternatives:

• Document the final alternatives list

• Select from among the several evaluation methods

  • Surveys

  • Engineering studies

  • Field experience and prototypes

  • Expert judgment (i.e., the Delphi method)

Also, measures need to be identified to support the evaluation method (e.g., the impact on cost, schedule, performance, and risk).

Choose the evaluation method which is most relevant to support the evaluation process:

• Evaluate alternative solutions

• Evaluate alternatives based on the defined criteria and the selected evaluation method

• Evaluate uncertainty in the values for alternative solutions (e.g., if the score varies between two values, then you need to assess whether there is a significant difference and whether it will affect the selection of the final solution)

• Address the uncertainty by taking appropriate actions

  • Perform simulations

  • Build prototypes

  • Run pilots

• Select the best solution from the alternatives evaluated

  • Assess the risk, if any, associated with the solution selected from the alternatives

  • Document the rationale for selecting the final solution and communicate the results to the relevant stakeholders

2.3.12.6 Measurement and Analysis

The purpose of the Measurement and Analysis (MA) process area is to establish a measurement system in the organization or the software unit group of the organization. The measurement system will help in measuring and assessing the project objectives, which in turn will help in achieving the business/organization objective.

Follow these steps to align the measurement and analysis activities:

• Establish the measurement objectives

• Document the measurement objectives

The measurement objectives enable you to perform measurement and analysis activities in the organization. Sources for the information needs and objectives can include the following:

• Project plans

• Business plans

• Interviews with managers

• Industry benchmarks

• Experience of other objects in the organization

You will want to review and update measurement objectives with management and other relevant stakeholders.

Documents to be maintained include your measurement objectives, which specify your organization’s measures.

Here, measurement objectives are converted into quantifiable measures. Examples of measures include the following:

• Effort variance

• Schedule variance

• Defect density

• Defects measure (i.e., the number of defects by severity and the total number of defects)

• Customer satisfaction ratings and trends

You will also need to document the operational definitions of measures. For example, you will need to state what to measure, how to measure it, the unit of measurement for each measure, as well as what has been included or excluded. Be sure to prioritize, review, and update measures with the relevant end users and stakeholders.

Documents to be maintained include the measurement guidelines. In these guidelines, you specify the process, including how measurement data will be obtained and stored:

• Identify measures for which existing sources of data are available

• Identify those measures for which data is needed, but which is currently not available

• Identify for each measure how to collect and store that data

• Work on the data-collection mechanism and procedures

• Update the measures and measurement objectives, as needed

You will also need to specify how measurement data is analyzed and communicated:

• Identify each type of data analysis to be conducted and the reports to be generated

• Select the appropriate data analysis methods and tools

  • Pie charts

  • Bar charts

  • Histograms

  • Line charts

• Review the measurement report with relevant stakeholders, end users, data providers, and so on

• Define the criteria for evaluating the measurement analysis results (e.g., determine whether the data is reliable, understandable, and can be used for decision making)

You will use the measurement guidelines to accomplish the following:

• Provide measurement results

  • Collect measurement data

  • Perform data calculations

  • Perform data integrity checks (i.e., errors in data, unusual patterns, etc.)

• Analyze measurement data

  • Perform analysis and interpret results to draw conclusions

  • Review the results with the relevant stakeholders before releasing it to all the stakeholders

  • Refine the measurement process based on the lessons learned during the reviews

Documents to be maintained include a draft of the measurement reports.

You will want to follow these guidelines to store data and results:

• Store data as per the defined data-storage procedures

• Ensure data is available to only authorized groups

• Prevent information from being used inappropriately

Documents to be maintained include the measurement data inventory.

Follow these steps to communicate the results:

• In a timely manner, regularly update the relevant stakeholders about the measurement results

• Help the relevant stakeholders to understand the results

Documents to be maintained include the measurement analysis report; this report needs to include read me guidelines for understanding the report.

2.3.12.7 Process and Product Quality Assurance (PPQA)

The Process and Product Quality Assurance (PPQA) process area helps you to accomplish the following:

• Objectively evaluate the process actions and work products against the defined processes and standards in the organization QMS

• Identify process noncompliance issues

• Communicate feedback to project teams on the quality assurance activities

• Ensure that the process noncompliance issues are closed

Examples of objective evaluations include the following:

• Internal quality audits conducted by the audit group

• A review of work products

• Performance reviews at the work places (i.e., desk audits)

These steps can help you objectively evaluate processes:

• Define clear criteria for evaluating the processes

• Evaluate the selected processes

• Identify noncompliance issues

• Identify lessons learned for process improvement

Follow these steps to objectively evaluate work products:

• Define clear criteria for evaluating the work products

• Evaluate the selected work products based on the sampling criteria

• Identify noncompliance issues

• Identify the lessons learned for process improvement

Documents to be maintained include the following:

• Evaluation reports

• Quality assurance reports

Follow these steps to track noncompliance issues and ensure resolution:

• Resolve the noncompliance issue with the relevant project members

• Document the noncompliance issues when they are not resolved in the project

• Escalate to senior management when noncompliance issues are not resolved in the project, so that appropriate actions can be taken

• Analyze noncompliance issues to see whether there are any formation trends regarding a particular category, so that appropriate action can be taken

• Ensure that you communicate the evaluation results to relevant stakeholders

You will also want to establish and maintain records of the quality-assurance activities:

• Document the result and status of quality-assurance activities performed

• Revise the status of quality-assurance activities performed

Documents to be maintained include the following:

• Quality-assurance reports

• Status reports

Hopefully we have covered all the process areas and their mapping. Although space prohibits explaining every point in-depth, we hope you will find the material in this chapter easy-to-follow and simple-to-understand.