Establish the Organization’s Process Asset Library

One major work in this process area is establish and maintain the organization's process asset library.

Examples of items to be stored in the organization’s process asset library include the following:

• Organizational policies
• Defined process descriptions
• Procedures (e.g., estimating procedure)
• Development plans
• Acquisition plans
• Quality assurance plans
• Training materials
• Process aids (e.g., checklists)
• Lessons-learned reports

Typical Work Products in this specific goal are:

1. Design of the organization’s process asset library
2. Organization's process asset library
3. Selected items to be included in the organization’s process asset library
4. Catalog of items in the organization’s process asset library

To implement this specific practices, simply follow subpractices below:

1. Design and implement the organization’s process asset library, including the library structure and support environment.
2. Specify the criteria for including items in the library. The items are selected based primarily on their relationship to the organization’s set of standard processes.
3. Specify the procedures for storing and retrieving items.
4. Enter the selected items into the library and catalog them for easy reference and retrieval.
5. Make the items available for use by the projects.
6. Periodically review the use of each item and use the results to maintain the library contents.
7. Revise the organization’s process asset library as necessary. Examples of when the library may need to be revised include the following:

• New items are added
• Items are retired
• Current versions of items are changed

Establish the Organization’s Measurement Repository

If you want to get more information about use of the organization’s measurement repository in planning project activities, please refer to the Use Organizational Process Assets for Planning Project Activities specific practice of the Integrated Project Management process area.

The repository contains both product and process measures that are related to the organization’s set of standard processes. It also contains or refers to the information needed to understand and interpret the measures and assess them for reasonableness and applicability. For example, the definitions of the measures are used to compare similar measures from different processes.

Typical Work Products in this process area are:

1. Definition of the common set of product and process measures for the organization’s set of standard processes
2. Design of the organization’s measurement repository
3. Organization's measurement repository (that is, the repository structure and support environment)
4. Organization’s measurement data

To implement this specific goal, simply follow subpractices below:

1. Determine the organization's needs for storing, retrieving, and analyzing measurements.
2. Define a common set of process and product measures for the organization's set of standard processes. Refer to the Measurement and Analysis process area for more information about defining measures.
3. Design and implement the measurement repository.
4. Specify the procedures for storing, updating, and retrieving measures.
5. Conduct peer reviews on the definitions of the common set of measures and the procedures for storing and retrieving measures. Refer to the Verification process area for more information about conducting peer reviews.
6. Enter the specified measures into the repository. Refer to the Measurement and Analysis process area for more information about collecting and analyzing data.
7. Make the contents of the measurement repository available for use by the organization and projects as appropriate.
8. Revise the measurement repository, common set of measures, and procedures as the organization’s needs change.

If you want to get more information about use of the organization’s measurement repository in planning project activities, please refer to the Use Organizational Process Assets for Planning Project Activities specific practice of the Integrated Project Management process area.

Establish Tailoring Criteria and Guidelines

This article talk about how to establish and maintain the tailoring criteria and guidelines for the organization's set of standard processes.

For IPPD Addition, in creating the tailoring criteria and guidelines, include considerations for concurrent development and operating with integrated teams. For example, how one tailors the manufacturing process will be different depending on whether it is developed serially after the product has been developed or in parallel with the development of the product, as in IPPD. Processes, such as resource allocation, will also be tailored differently if the project is operating with integrated teams.

The tailoring criteria and guidelines describe the following:

• How the organization’s set of standard processes and organizational process assets are used to create the defined processes
• Mandatory requirements that must be satisfied by the defined processes (e.g., the subset of the organizational process assets that are essential for any defined process)
• Options that can be exercised and criteria for selecting among the options
• Procedures that must be followed in performing and documenting process tailoring

Flexibility in tailoring and defining processes is balanced with ensuring appropriate consistency in the processes across the organization. Flexibility is needed to address contextual variables such as the domain; nature of the customer; cost, schedule, and quality tradeoffs; technical difficulty of the work; and experience of the people implementing the process. Consistency across the organization is needed so that organizational standards, objectives, and strategies are appropriately addressed, and process data and lessons learned can be shared.

Tailoring criteria and guidelines may allow for using a standard process “as is,” with no tailoring.

Typical Work Products in this specific practice is Tailoring guidelines for the organization's set of standard processes.

To implement this specific practice, simply follow sub-practices below:

1. Specify the selection criteria and procedures for tailoring the organization's set of standard processes.
Examples of criteria and procedures include the following:

• Criteria for selecting lifecycle models from those approved by the organization
• Criteria for selecting process elements from the organization’s set of standard processes
• Procedures for tailoring the selected lifecycle models and process elements to accommodate specific process characteristics and needs

Examples of tailoring actions include the following:

• Modifying a lifecycle model
• Combining elements of different lifecycle models
• Modifying process elements
• Replacing process elements
• Reordering process elements

2. Specify the standards for documenting the defined processes.

3. Specify the procedures for submitting and obtaining approval of waivers from the requirements of the organization’s set of standard processes.

4. Document the tailoring guidelines for the organization's set of standard processes.

5. Conduct peer reviews on the tailoring guidelines.

6. Revise the tailoring guidelines as necessary.

Establish Life-cycle Model Descriptions

To establish an organization's set of standard process, you need to establish and maintain descriptions of the life-cycle models approved for use in the organization.

Life-cycle models may be developed for a variety of customers or in a variety of situations, since one life-cycle model may not be appropriate for all situations. Life-cycle models are often used to define the phases of the project. Also, the organization may define different life-cycle models for each type of product and service it delivers.

Typical Work Products in this specific practice is descriptions of life-cycle models.

To implement this specific practices, simply follow sub-practices below:

1. Select lifecycle models based on the needs of projects and the organization. For example, project lifecycle models include the following:

• Waterfall
• Spiral
• Evolutionary
• Incremental
• Iterative

2. Document the descriptions of the lifecycle models. The lifecycle models may be documented as part of the organization’s standard process descriptions or they may be documented separately.

3. Conduct peer reviews on the lifecycle models.

4. Revise the descriptions of the lifecycle models as necessary.

Establish Standard Processes

Standard processes may be defined at multiple levels in an enterprise and they may be related in a hierarchical manner. For example, an enterprise may have a set of standard processes that is tailored by individual organizations (e.g., a division or site) in the enterprise to establish their set of standard processes. The set of standard processes may also be tailored for each of the organization’s business areas or product lines. Thus “the organization’s set of standard processes” can refer to the standard processes established at the organization level and standard processes that may be established at lower levels, although some organizations may only have a single level of standard processes.

Multiple standard processes may be needed to address the needs of different application domains, life-cycle models, methodologies, and tools. The organization’s set of standard processes contains process elements (e.g., a work product size-estimating element) that may be interconnected according to one or more process architectures that describe the relationships among these process elements.

The organization’s set of standard processes typically includes technical, management, administrative, support, and organizational processes. In an IPPD environment, the organization's set of standard processes includes a process that projects use to establish a shared vision.

The organization’s set of standard processes should collectively cover all processes needed by the organization and projects, including those processes addressed by the process areas at Maturity Level 2.

Typical Work Products in this specific practices is Organization's set of standard processes.

To implement this specific practices, simple refer to sub-practices below:

1. Decompose each standard process into constituent process elements to the detail needed to understand and describe the process. Examples of process elements include the following:

• Template for generating work product size estimates
• Description of work product design methodology
• Tailorable peer review methodology
• Template for conduct of management reviews

2. Specify the critical attributes of each process element. Examples of critical attributes include the following:

• Process roles
• Applicable standards
• Applicable procedures, methods, tools, and resources
• Process-performance objectives
• Entry criteria
• Inputs
• Product and process measures to be collected and used
• Verification points (e.g., peer reviews)
• Outputs
• Interfaces
• Exit criteria

3. Specify the relationships of the process elements. Examples of relationships include the following:

• Ordering of the process elements
• Interfaces among the process elements
• Interfaces with external processes
• Interdependencies among the process elements

4. Ensure that the organization's set of standard processes adheres to applicable policies, standards, and models.

5. Ensure that the organization’s set of standard processes satisfies the process needs and objectives of the organization.

6. Ensure that there is appropriate integration among the processes that are included in the organization’s set of standard processes.

7. Document the organization's set of standard processes.

8. Conduct peer reviews on the organization's set of standard processes.

9. Revise the organization's set of standard processes as necessary.

Organizational Process Definition (OPD)

Organizational Process Definition (OPD) is a Process Management Process Area at Maturity Level 3.

The purpose of Organizational Process Definition (OPD) is to establish and maintain a usable set of organizational process assets and work environment standards. For IPPD addition, this process area also covers the establishment of organizational rules and guidelines that enable conducting work using integrated teams.

The organization’s process asset library is a collection of items maintained by the organization for use by the people and projects of the organization. This collection of items includes descriptions of processes and process elements, descriptions of lifecycle models, process tailoring guidelines, process-related documentation, and data. The organization’s process asset library supports organizational learning and process improvement by allowing the sharing of best practices and lessons learned across the organization.

The organization’s set of standard processes is tailored by projects to create their defined processes. The other organizational process assets are used to support tailoring as well as the implementation of the defined processes. The work environment standards are used to guide creation of project work environments.

The organizational process assets may be organized in many ways, depending on the implementation of the Organizational Process Definition process area. Examples include the following:

• Descriptions of lifecycle models may be documented as part of the organization’s set of standard processes, or they may be documented separately.
• The organization’s set of standard processes may be stored in the organization’s process asset library, or they may be stored separately.
• A single repository may contain both the measurements and the process-related documentation, or they may be stored separately.

To find more information about this process area, please refer to the Organizational Process Focus process area for more information about organizational process-related matters.

Specific Goal and Practice Summary:

SG 1 Establish Organizational Process Assets

• SP 1.1 Establish Standard Processes
• SP 1.2 Establish Lifecycle Model Descriptions
• SP 1.3 Establish Tailoring Criteria and Guidelines
• SP 1.4 Establish the Organization’s Measurement Repository
• SP 1.5 Establish the Organization’s Process Asset Library
• SP 1.6 Establish Work Environment Standards

IPPD Addition

SG 2 Enable IPPD Management

• SP 2.1 Establish Empowerment Mechanisms
• SP 2.2 Establish Rules and Guidelines for Integrated Teams
• SP 2.3 Balance Team and Home Organization Responsibilities

Establish Organizational Process Needs

The organization’s processes operate in a business context that must be understood. The organization’s business objectives, needs, and constraints determine the needs and objectives for the organization’s processes. Typically, the issues related to finance, technology, quality, human resources, and marketing are important process considerations.

The organization’s process needs and objectives cover aspects that include the following:

• Characteristics of the processes
• Process-performance objectives, such as time-to-market and delivered quality
• Process effectiveness, such as indicator of defect removal efficiency, process compliance index.

Typical Work Products in this process area is Organization’s process needs and objectives.

To implement this specific practice, simply follow practices below:

1. Identify the policies, standards, and business objectives that are applicable to the organization's processes.
2. Examine relevant process standards and models for best practices.
3. Determine the organization’s process-performance objectives, such as defect removal efficiency, process compliance index, etc.
4. Define the essential characteristics of the organization’s processes base on: Processes currently being used in the organization;Standards imposed by the organization; or Standards commonly imposed by customers of the organization.
5. Document the organization’s process needs and objectives.
6. Revise the organization’s process needs and objectives as needed.

Organizational Process Focus (OPF)

Organizational Process Focus (OPF) is a Process Management Process Area at Maturity Level 3.

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.

The organization's processes include all the processes used by the organization and its projects. Candidate improvements to the organization's processes and process assets are obtained from various sources, including measurement of the processes, lessons learned in implementing the processes, results of process appraisals, results of product evaluation activities, results of benchmarking against other organizations’ processes, and recommendations from other improvement initiatives in the organization.

Process improvement occurs within the context of the organization’s needs and is used to address the organization’s objectives. The organization encourages participation in process improvement activities by those who will perform the process. The responsibility for facilitating and managing the organization’s process improvement activities, including coordinating the participation of others, is typically assigned to a process group. The organization provides the long-term commitment and resources required to sponsor this group and to ensure the effective and timely deployment of the improvements.

Organizational process assets are used to describe, implement, and improve the organization's processes. Please refer to the Organizational Process Definition process area for more information about the organizational process assets.

Specific Goal and Practice Summary for this process area:

SG 1 Determine Process Improvement Opportunities

• SP 1.1 Establish Organizational Process Needs
• SP 1.2 Appraise the Organization’s Processes
• SP 1.3 Identify the Organization's Process Improvements

SG 2 Plan and Implement Process Improvements

• SP 2.1 Establish Process Action Plans
• SP 2.2 Implement Process Action Plans

SG 3 Deploy Organizational Process Assets and Incorporate Lessons Learned

• SP 3.1 Deploy Organizational Process Assets
• SP 3.2 Deploy Standard Processes
• SP 3.3 Monitor Implementation
• SP 3.4 Incorporate Process-Related Experiences into the Organizational Process Assets

Specify Measures

Measurement objectives are refined into precise, quantifiable measures.

Measures may be either “base” or “derived.” Data for base measures are obtained by direct measurement. Data for derived measures come from other data, typically by combining two or more base measures.

Examples of commonly used base measures include the following: Estimates and actual measures of work product size (e.g., number of pages, number of line of code, number of test case); Estimates and actual measures of effort and cost (e.g., number of person hours); Quality measures (e.g., number of defects by severity, number of defects by development phase, number of bugs by testing phase).

Examples of commonly used derived measures include the following: Earned Value (hour); Schedule Performance Index (numerical); Defect density (%); Peer review coverage (%); Test or verification coverage (%); Reliability measures (numerical); Quality measures (numerical).

Derived measures typically are expressed as ratios, composite indices, or other aggregate summary measures. They are often more quantitatively reliable and meaningfully interpretable than the base measures used to generate them.

Typical Work Product in this specific practices is Specifications of base and derived measures.

To implement this specific practices, simply follow practices below:

1. Identify candidate measures (name and unit) based on documented measurement objectives.

2. Identify existing measures that already address the measurement objectives.

3. Specify operational definitions for the measures.

• Communication: What has been measured, how was it measured, what are the units of measure, and what has been included or excluded?
• Repeatability: Can the measurement be repeated, given the same definition, to get the same results?

4. Prioritize, review, and update measures.

• Proposed specifications of the measures are reviewed for their appropriateness with potential end users and other relevant stakeholders. Priorities are set or changed, and specifications of the measures are updated as necessary.

Establish Measurement Objectives

Measurement objectives document the purposes for which measurement and analysis are done, and specify the kinds of actions that may be taken based on the results of data analyses.

The sources for measurement objectives may be management, technical, project, product, or process implementation needs.

Sources of information needs and objectives may include the following:

• Project plans (PJ schedule, WBS)
• Monitoring of project performance (to know project is delayed or not)
• Interviews with managers and others who have information needs (to know whether issue raised in project)
• Established management objectives (project metrics which set in planning phase)
• Strategic plans (implementation is in the right strategy or not)
• Formal requirements or contractual obligations
• Recurring or other troublesome management or technical problems
• Experiences of other projects or organizational entities
• External industry benchmarks
• Process improvement plans

The measurement objectives may be constrained by existing processes, available resources, or other measurement considerations. Judgements may need to be made about whether the value of the results will be commensurate with the resources devoted to doing the work.

Example measurement objectives include the following: Reduce time to delivery; Reduce total life-cycle cost; Deliver specified functionality completely; Improve prior levels of quality etc.

Typical Work Product in this specific practice is Measurement objectives.

To implement this specific practices, simply follow practices below:

1. Document information needs and objectives (which will be measure).
2. Prioritize information needs and objectives (which has higher priority in measurement).
3. Document, review, and update measurement objectives.
4. Provide feedback for refining and clarifying information needs and objectives as necessary.
5. Maintain traceability of the measurement objectives to the identified information needs and objectives.

There must always be a good answer to the question, “Why are we measuring this?”.
Of course, the measurement objectives may also change to reflect evolving information needs and objectives.

Measurement and Analysis (MA)

Measurement and Analysis (MA) process is a Support Process Area at Maturity Level 2. The purpose of Measurement and Analysis (MA) is to develop and sustain a measurement capability that is used to support management information needs.

This process area involves the following:

• Specifying the objectives (such as schedule variances, effort variances, cost variances, or productivity, defect density, etc) of measurement and analysis such that they are aligned with identified information needs and objectives
• Specifying the measures, analysis techniques (how), and mechanism for data collection (when, who), data storage (where), reporting (form, template), and feedback (to whom)
• Implementing the collection, storage, analysis, and reporting of the data
• Providing objective results that can be used in making informed decisions (improvement opportunities), and taking appropriate corrective actions

The integration of measurement and analysis activities into the processes of the project supports the following:

• Objective planning and estimating
• Tracking actual performance against established plans and objectives
• Identifying and resolving process-related issues, support taking corrective action in time
• Providing a basis for incorporating measurement into additional processes in the future, point out improvement opportunities to organizational process assets

To understand more clearly about this process area, please refer to other process areas in CMMI model:

• Refer to the Project Planning process area for more information about estimating project attributes and other planning information needs.
• Refer to the Project Monitoring and Control process area for more information about monitoring project performance information needs.
• Refer to the Configuration Management process area for more information about managing measurement work products.
• Refer to the Requirements Development process area for more information about meeting customer requirements and related information needs.
• Refer to the Requirements Management process area for more information about maintaining requirements traceability and related information needs.
• Refer to the Organizational Process Definition process area for more information about establishing the organization’s measurement repository.
• Refer to the Quantitative Project Management process area for more information about understanding variation and the appropriate use of statistical analysis techniques.

Specific Goal and Practice Summary:

SG 1 Align Measurement and Analysis Activities

• SP 1.1 Establish Measurement Objectives
• SP 1.2 Specify Measures
• SP 1.3 Specify Data Collection and Storage Procedures
• SP 1.4 Specify Analysis Procedures

SG 2 Provide Measurement Results

• SP 2.1 Collect Measurement Data
• SP 2.2 Analyze Measurement Data
• SP 2.3 Store Data and Results
• SP 2.4 Communicate Results

Monitor Commitments

One of specific goals in generic goal “Monitor Project against Plan” is monitor commitments against those identified in the project plan.

Basically, a plan that provides the basis for performing and controlling the project’s activities, which addresses the commitments to the project’s customer.

Project planning includes estimating the attributes of the work products and tasks, determining the resources needed, negotiating commitments, producing a schedule, and identifying and analysing project risks. Iterating through these activities may be necessary to establish the project plan.

Typical work product in this goal is “Records of commitment reviews”.

To implement this specific goal, simply follow practices below:

• Regularly review commitments (both external and internal) by holding review meetings.
• Identify commitments that have not been satisfied or that are at significant risk of not being satisfied.
• Document the results of the commitment reviews.

Monitor Project Planning Parameters

This article describe about monitoring the actual values of the project planning parameters against the project plan.

Project planning parameters constitute typical indicators of project progress and performance and include attributes of work products and tasks, cost, effort, and schedule. Attributes of the work products and tasks include such items as size, complexity, weight, form, fit, or function.

Monitoring typically involves measuring the actual values of project planning parameters, comparing actual values to the estimates in the plan, and identifying significant deviations. Recording actual values of the project planning parameters includes recording associated contextual information to help understand the measures. An analysis of the impact that significant deviations have on determining what corrective actions to take is handled in the second specific goal and its specific practices in this process area.

Typical Work Products in this process area are:

• Records of project performance
• Records of significant deviations

To implement this process, simple follow practices below:

1. Monitor progress against the schedule.

• Periodically measuring the actual completion of activities and milestones
• Comparing actual completion of activities and milestones against the schedule documented in the project plan
• Identifying significant deviations from the schedule estimates in the project plan

2. Monitor the project's cost and expended effort.

• Periodically measuring the actual effort and cost expended and staff assigned
• Comparing actual effort, costs, staffing, and training to the estimates and budget documented in the project plan
• Identifying significant deviations from the budget in the project plan

3. Monitor the attributes of the work products and tasks.

• Periodically measuring the actual attributes of the work products and tasks, such as size or complexity (and the changes to the attributes)
• Comparing the actual attributes of the work products and tasks (and the changes to the attributes) to the estimates documented in the project plan
• Identifying significant deviations from the estimates in the project plan

Refer to the Project Planning process area for information about the attributes of work products and tasks.

4. Monitor resources provided and used.

Refer to the Project Planning process area for information about planned resources.
Example of resources include: Computers, peripherals, and software used in design, manufacturing, testing, and operation; Physical facilities; Project staff; Processes; Networks

5. Monitor the knowledge and skills of project personnel.

• Periodically measuring the acquisition of knowledge and skills by project personnel
• Comparing actual training obtained to that documented in the project plan
• Identifying significant deviations from estimates in the project plan

Refer to the Project Planning process area for information about planning for knowledge and skills needed to perform the project.

6. Document the significant deviations in the project planning parameters.

Project Monitoring and Control (PMC)

Project Monitoring and Control (PMC) is a Project Management Process Area at Maturity Level 2.

The purpose of Project Monitoring and Control is to provide an visualization of the project’s progress so that appropriate corrective actions can be taken when the project’s performance deviates significantly from the plan.

Monitoring activities, communication status, and corrective actions are based on project plan. The project progress is primarily determined by comparing actual work products and task attributes, cost, effort and schedule to the plan at each milestones within the project schedule or work breakdown structure (WBS). Timely corrective actions is taken according to appropriate visibility of significantly deviations between project performance and plan. A deviation is significant if, when left unresolved, it precludes the project from meeting its objectives.

The term “project plan” is used to refer to the overall plan for controlling the project.

When actual status deviates significantly from the expected values, corrective actions are taken as appropriate. These actions may require re-planning, which may include revising the original plan, establishing new agreements, or including additional mitigation activities within the current plan.

To understand more about this process area:

- Refer to the Project Planning process area for more information about the project plan, including how it specifies the appropriate level of project monitoring, the measures used to monitor progress, and known risks.

- Refer to the Measurement and Analysis process area for information about the process of measuring, analyzing, and recording information.

Specific Goal and Practice Summary for this process area:

SG 1 Monitor Project Against Plan

• SP 1.1 Monitor Project Planning Parameters
• SP 1.2 Monitor Commitments
• SP 1.3 Monitor Project Risks
• SP 1.4 Monitor Data Management
• SP 1.5 Monitor Stakeholder Involvement
• SP 1.6 Conduct Progress Reviews
• SP 1.7 Conduct Milestone Reviews

SG 2 Manage Corrective Action to Closure

• SP 2.1 Analyze Issues
• SP 2.2 Take Corrective Action
• SP 2.3 Manage Corrective Action

Estimate the Scope of the Project

Establish a top-level work breakdown structure (WBS) to estimate the scope of the project.

The WBS evolves with the project. Typically, the WBS is a product oriented structure that provides a scheme for identifying and organizing the logical units of work to be managed, which are called “work packages”. The WBS provides a reference and organizational mechanism for assigning effort, schedule, and responsibility and is used as the underlying framework to plan, organize, and control the work done on the project.
Typical Work Products in this step are:

• Task descriptions
• Work package descriptions
• WBS

To develop a high-level WBS, project team can base on practices below:

1. Identify the product architecture.

• Identified risks and their mitigation tasks
• Tasks for deliverables and supporting activities (supporting activities can be review activities, co-operate with other group in company)
• Tasks for skill and knowledge acquisition (this can be training activities)
• Tasks for development of needed support plans, such as configuration management, quality assurance, and verification plansTasks for integration and management of non-developmental items (such as making project plan, monitoring project progress, controlling project issues etc)

2. Identify the work packages in sufficient detail to specify estimates of project tasks, responsibilities, and schedule. The top-level WBS is intended to help in gauging the project work effort in terms of tasks and organizational roles and responsibilities. The amount of detail in the WBS at this more detailed level helps in developing realistic schedules, thereby minimizing the need for management reserve.

3. Identify product or product components that will be externally acquired.

4. Identify work products that will be reused.

Example work product in this step:

Establish Estimates

The first step in implementing project planning is establish and maintain project planning parameters.

Project planning parameters include all information needed by the project to perform the necessary planning, organizing, staffing, directing, coordinating, reporting, and budgeting. Estimates of planning parameters should have a sound basis to instill confidence that any plans based on these estimates are capable of supporting project objectives.

Factors that are typically considered when estimating these parameters include the following:

• Project requirements, including the product requirements (functional and non-functional requirements), the requirements imposed by the organization, the requirements imposed by the customer, and other requirements that impact the project
• Scope of the project (What project will do ?)
• Identified tasks and work products
• Technical approach
• Selected project life-cycle model (e.g., waterfall, incremental, spiral, or prototyping etc)
• Attributes of the work products and tasks (e.g., size, complexity, or difficulty)
• Schedule
• Models or historical data for converting the attributes of the work products and tasks into labour hours and cost
• Methodology (e.g., models, data, algorithms) used to determine needed material, skills, labour hours, and cost

Documentation of the estimating rationale and supporting data is needed for stakeholders’ review and commitment to the plan and for maintenance of the plan during project development time.

Project Planning

Project planning is a Project Management Process Area at Maturity Level 2.

The purpose of Project Planning (PP) is to establish and maintain plans that define project activities.

The Project Planning process area involves the following:

• Developing the project plan
• Interacting with stakeholders appropriately
• Getting commitment to the plan
• Maintaining the plan

Planning begins with requirements that define the product and project. Planning includes estimating the attributes of the work products and tasks, determining the resources needed, negotiating commitments, producing a schedule, and identifying and analysing project risks. Iterating through these activities may be necessary to establish the project plan. The project plan provides the basis for performing and controlling the project’s activities that address the commitments with the project’s customer.

The project plan will usually need to be revised as the project progresses to address changes in requirements and commitments, inaccurate estimates, corrective actions, and process changes. Specific practices describing both planning and re-planning are contained in this process area.
The term “project plan” is used throughout the generic and specific practices in this process area to refer to the overall plan for controlling the project.

To make the best project plan:
- Refer to the Requirements Development process area for more information about developing requirements that define the product and product components. Product and product component requirements and changes to those requirements serve as a basis for planning and re-planning.
- Refer to the Requirements Management process area for more information about managing requirements needed for planning and re-planning.
- Refer to the Risk Management process area for more information about identifying and managing risks.
- Refer to the Technical Solution process area for more information about transforming requirements into product and product component solutions.

Specific Goal and Practice Summary for Project Planning process area

SG 1 Establish Estimates

• SP 1.1 Estimate the Scope of the Project
• SP 1.2 Establish Estimates of Work Product and Task Attributes
• SP 1.3 Define Project Lifecycle
• SP 1.4 Determine Estimates of Effort and Cost

SG 2 Develop a Project Plan

• SP 2.1 Establish the Budget and Schedule
• SP 2.2 Identify Project Risks
• SP 2.3 Plan for Data Management
• SP 2.4 Plan for Project Resources
• SP 2.5 Plan for Needed Knowledge and Skills
• SP 2.6 Plan Stakeholder Involvement
• SP 2.7 Establish the Project Plan

SG 3 Obtain Commitment to the Plan

• SP 3.1 Review Plans That Affect the Project
• SP 3.2 Reconcile Work and Resource Levels
• SP 3.3 Obtain Plan Commitment

Capability Levels/Maturity Levels presentation

Process areas are viewed differently in the two representations: continuous representation and the staged representation. Continuous representation describes the Capability Levels, and staged representation describes the Maturity Levels of process areas in CMMI model. You can see the figures below for these representations.

Continuous representation:

Staged representation:

Process areas according to Maturity Levels:

What is Maturity Levels ?

To support those using the staged representation, all CMMI models reflect maturity levels in their design and content. A maturity level consists of related specific and generic practices for a predefined set of process areas that improve the organization’s overall performance. The maturity level of an organization provides a way to predict an organization’s performance in a given discipline or set of disciplines.

A maturity level is a defined evolutionary plateau for organizational process improvement. Each maturity level matures an important subset of the organization’s processes, preparing it to move to the next maturity level. The maturity levels are measured by the achievement of the specific and generic goals associated with each predefined set of process areas.

There are five maturity levels, each a layer in the foundation for ongoing process improvement, designated by the numbers 1 through 5:

1. Initial

2. Managed

3. Defined

4. Quantitatively Managed

5. Optimizing

Maturity Level 1: Initial

At maturity level 1, processes are usually ad hoc and chaotic. The organization usually does not provide a stable environment to support the processes. Success in these organizations depends on the competence and heroics of the people in the organization and not on the use of proven processes. Maturity level 1 organizations are characterized by a tendency to over commit, abandonment of processes in a time of crisis, and an inability to repeat their successes.

Maturity Level 2: Managed

At maturity level 2, the projects of the organization have ensured that processes are planned and executed in accordance with policy; the projects employ skilled people who have adequate resources to produce controlled outputs; involve relevant stakeholders; are monitored, controlled, and reviewed; and are evaluated for adherence to their process descriptions. The process discipline reflected by maturity level 2 helps to ensure that existing practices are retained during times of stress. When these practices are in place, projects are performed and managed according to their documented plans.

Maturity Level 3: Defined

At maturity level 3, processes are well characterized and understood, and are described in standards, procedures, tools, and methods. The organization’s set of standard processes, which is the basis for maturity level 3, is established and improved over time. These standard processes are used to establish consistency across the organization. Projects establish their defined processes by tailoring the organization’s set of standard processes according to tailoring guidelines. (See the glossary for a definition of “organization’s set of standard processes.”)

A critical distinction between maturity levels 2 and 3 is the scope of standards, process descriptions, and procedures. At maturity level 2, the standards, process descriptions, and procedures may be quite different in each specific instance of the process (e.g., on a particular project). At maturity level 3, the standards, process descriptions, and procedures for a project are tailored from the organization’s set of standard processes to suit a particular project or organizational unit and therefore are more consistent, except for the differences allowed by the tailoring guidelines.

Maturity Level 4: Quantitatively Managed

At maturity level 4, the organization and projects establish quantitative objectives for quality and process performance and use them as criteria in managing processes. Quantitative objectives are based on the needs of the customer, end users, organization, and process implementers. Quality and process performance is understood in statistical terms and is managed throughout the life of the processes.

A critical distinction between maturity levels 3 and 4 is the predictability of process performance. At maturity level 4, the performance of processes is controlled using statistical and other quantitative techniques, and is quantitatively predictable. At maturity level 3, processes are typically only qualitatively predictable.

Maturity Level 5: Optimizing

At maturity level 5, an organization continually improves its processes based on a quantitative understanding of the common causes of variation inherent in processes. Maturity level 5 focuses on continually improving process performance through incremental and innovative process and technological improvements. Quantitative process improvement objectives for the organization are established, continually revised to reflect changing business objectives, and used as criteria in managing process improvement.

What is Capability Levels ?

To support those using the continuous representation, all CMMI models reflect capability levels in their design and content. A capability level consists of a generic goal and its related generic practices as they relate to a process area, which can improve the organization’s processes associated with that process area.

The six capability levels, designated by the numbers 0 through 5, are as follows:

0. Incomplete

1. Performed

2. Managed

3. Defined

4. Quantitatively Managed

5. Optimizing

Capability Level 0: Incomplete

An “incomplete process” is a process that either is not performed or partially performed. One or more of the specific goals of the process area are not satisfied, and no generic goals exist for this level since there is no reason to institutionalize a partially performed process.

Capability Level 1: Performed

A capability level 1 process is characterized as a “performed process.” A performed process is a process that satisfies the specific goals of the process area. It supports and enables the work needed to produce work products.

Capability Level 2: Managed

A capability level 2 process is characterized as a “managed process.” A managed process is a performed (capability level 1) process that has the basic infrastructure in place to support the process. It is planned and executed in accordance with policy; employs skilled people who have adequate resources to produce controlled outputs; involves relevant stakeholders; is monitored, controlled, and reviewed; and is evaluated for adherence to its process description. The process discipline reflected by capability level 2 helps to ensure that existing practices are retained during times of stress.

Capability Level 3: Defined

A capability level 3 process is characterized as a “defined process.” A defined process is a managed (capability level 2) process that is tailored from the organization’s set of standard processes according to the organization’s tailoring guidelines, and contributes work products, measures, and other process improvement information to the organizational process assets.

A critical distinction between capability levels 2 and 3 is the scope of standards, process descriptions, and procedures. At capability level 2, the standards, process descriptions, and procedures may be quite different in each specific instance of the process (e.g., on a particular project). At capability level 3, the standards, process descriptions, and procedures for a project are tailored from the organization’s set of standard processes to suit a particular project or organizational unit and therefore are more consistent, except for the differences allowed by the tailoring guidelines.

Capability Level 4: Quantitatively Managed

A capability level 4 process is characterized as a “quantitatively managed process.” A quantitatively managed process is a defined (capability level 3) process that is controlled using statistical and other quantitative techniques. Quantitative objectives for quality and process performance are established and used as criteria in managing the process. Quality and process performance is understood in statistical terms and is managed throughout the life of the process.

Capability Level 5: Optimizing

A capability level 5 process is characterized as an “optimizing process.” An optimizing process is a quantitatively managed (capability level 4) process that is improved based on an understanding of the common causes of variation inherent in the process. The focus of an optimizing process is on continually improving the range of process performance through both incremental and innovative improvements.

Process Areas

A process area is a cluster of related practices in an area that, when implemented collectively, satisfy a set of goals considered important for making improvement in that area.

There are 22 process areas, presented here in alphabetical order by acronym:

• Causal Analysis and Resolution (CAR)
• Configuration Management (CM)
• Decision Analysis and Resolution (DAR)
• Integrated Project Management +IPPD (IPM+IPPD)(*)
• Measurement and Analysis (MA)
• Organizational Innovation and Deployment (OID)
• Organizational Process Definition +IPPD (OPD+IPPD)⁶
• Organizational Process Focus (OPF)
• Organizational Process Performance (OPP)
• Organizational Training (OT)
• Product Integration (PI)
• Project Monitoring and Control (PMC)
• Project Planning (PP)
• Process and Product Quality Assurance (PPQA)
• Quantitative Project Management (QPM)
• Requirements Development (RD)
• Requirements Management (REQM)
• Risk Management (RSKM)
• Supplier Agreement Management (SAM)
• Technical Solution (TS)
• Validation (VAL)
• Verification (VER)

(*)This process area has "+IPPD" after its name because it contains a goal and practices that are specific to IPPD. The material specific to IPPD is called an "IPPD addition." All process areas with IPPD additions have "+IPPD" after their name.

The continuous approach to Process Improvement

In this approach to Process improvement, you select the processes that are important to your business objectives. Since there are 22 process areas to choose from, this is usually too many to focus on when starting out. You may need to narrow your focus. For example, you may find that your competitor always releases its product before yours. You may choose to focus on improving your engineering and project management processes.

Building on this decision, you select all the Engineering process areas as a starting point: Product Integration, Requirements Development, Requirements Management, Technical Solution, Validation, and Verification. You also select Project Planning and Project Monitoring and Control.

You may at this point decide that eight process areas are still too many to focus on initially, and you decide that the requirements process is really where the problems are. Consequently, you select the Requirements Development and Requirements Management process areas to begin your improvement efforts.

Next you decide how much improvement is needed in the requirements area. Do you have any processes in place already? If you do not, your process improvement objective may be to get to capability level 1.

Do you have your requirements development and management processes in place for each project, but they are not managed processes? For example, policies, training, and tools are not implemented to support the processes. If your requirements processes are in place but there is no supporting infrastructure, your process improvement objective may be to get to capability level 2.

Do you have all your requirements development and management processes and their management in place, but each project performs these processes differently? For example, your requirements elicitation process is not performed consistently across the organization. If this is the case, your process improvement objective may be to get to capability level 3.

Do you consistently manage and perform your requirements development and management processes but do not have an objective way to control and improve these processes? If this is the case, your process improvement objective may be to get to capability level 4.

Do you want to ensure that you are selecting the right subprocesses to improve based on quantitative objectives to maximize your business? If so, your process improvement objective may be to get to capability level 5 for selected processes. In the description of each process area, remember to look for amplifications introduced by the phrases “For Hardware Engineering,” “For Systems Engineering,” and “For Software Engineering.” Use all information that has no specific markings and the material in the boxes labeled “Continuous Only.”

As you can see from this scenario, you need to understand which processes need improvement and how much you want to mature each process. This way of proceeding reflects the fundamental principle behind the continuous representation.

CMMI for Software Development

The CMMI for Development constellation consists of two models: CMMI for Development +IPPD (Integrated Product and Process Development) and CMMI for Development (without IPPD). Both models share much of their material and are identical in these shared areas. However, CMMI for Development +IPPD contains additional goals and practices that cover IPPD.

Currently, only one model is published since the CMMI for Development +IPPD model contains the full complement of practices available in this constellation, and you can derive the other model from this material. If you are not using IPPD, ignore the information that is marked “IPPD Addition,” and you will be using the CMMI for Development model. If the need arises or the development constellation is expanded, the architecture will allow other models to be generated and published.

CMMI for Development is the designated successor of the three source models. The SEI has retired the Software CMM and the IPD-CMM. EIA has retired the SECM. All three of these models are succeeded by CMMI for Development.

The best practices in the CMMI models have gone through an extensive review process. CMMI version 0.2 was publicly reviewed and used in pilot activities.

The CMMI Product Team evaluated more than 3,000 change requests to create CMMI version 1.0. Shortly thereafter, version 1.02 was released, which incorporated several minor improvements.

Version 1.1 incorporated improvements guided by feedback from early use, with more than 1,500 change requests submitted as part of the public review, and hundreds of comments as part of the change control process.

CMMI version 1.2 was developed using input from nearly 2,000 change requests submitted by CMMI users. More than 750 of those requests were directed at CMMI model content. As you can see, not only is CMMI widely adopted, but it is improved based on the feedback received from the community.

How CMMI was born ?

Since 1991, CMMs have been developed for myriad disciplines. Some of the most notable include models for systems engineering, software engineering, software acquisition, workforce management and development, and integrated product and process development (IPPD).

Although these models have proven useful to many organizations in different industries, the use of multiple models has been problematic. Many organizations would like their improvement efforts to span different groups in their organizations. However, the differences among the discipline-specific models used by each group, including their architecture, content, and approach, have limited these organizations’ capabilities to broaden their improvements successfully. Further, applying multiple models that are not integrated within and across an organization is costly in terms of training, appraisals, and improvement activities.

The CMM Integration^SM project was formed to sort out the problem of using multiple CMMs. Using information from these popular and well-regarded models as source material, the CMMI Product Team created a cohesive set of integrated models that can be adopted by those currently using the source models, as well as by those new to the CMM concept. Hence, CMMI is a result of the evolution of the SW-CMM, the SECM, and the IPD-CMM.

Recently, the CMMI model architecture was improved to support multiple constellations and the sharing of best practices among constellations and their member models. Work has begun on two new constellations: one for services (CMMI for Services) and the other for acquisition (CMMI for Acquisition). Although CMMI for Development incorporates the development of services, including the combination of components, consumables, and people intended to meet service requirements, it differs from the planned CMMI for Services (CMMI-SVC), which focuses on the delivery of services. The CMMI models that have been available in the community prior to 2006 are now considered part of the CMMI for Development constellation.