Trimwell |

Critical Chain Project Management

Critical chain project management (CCPM) is a method of planning and managing projects that emphasizes the resources (people, equipment, physical space) required to execute project tasks. It was developed by Eliyahu M. Goldratt. It differs from more traditional methods that derive from critical path and PERT algorithms, which emphasize task order and rigid scheduling. A critical chain project network strives to keep resources levelled, and requires that they be flexible in start times.

Critical chain project management is based on methods and algorithms derived from Theory of Constraints. The idea of CCPM was introduced in 1997 in Eliyahu M. Goldratt’s book, Critical Chain. Application of CCPM has been credited with achieving projects 10% to 50% faster and/or cheaper than the traditional methods (i.e., CPM, PERT, Gantt, etc.) developed from 1910 to 1950s.

According to studies of traditional project management methods by Standish Group and others as of 1998, only 44% of projects typically finish on time. Projects typically complete at 222% of the duration originally planned, 189% of the original budgeted cost, 70% of projects fall short of their planned scope (technical content delivered), and 30% are cancelled before completion. CCPM tries to improve performance relative to these traditional statistics.

With traditional project management methods, 30% of lost time and resources are typically consumed by wasteful techniques such as bad multitasking (in particular task switching), student syndrome, Parkinson’s law, in-box delays, and lack of prioritization.

In a project plan, the critical chain is the sequence of both precedence- and resource-dependent tasks that prevents a project from being completed in a shorter time, given finite resources. If resources are always available in unlimited quantities, then a project’s critical chain is identical to its critical path method.

Critical chain is an alternative to critical path analysis. Main features that distinguish critical chain from critical path are:

CCPM planning aggregates the large amounts of safety time added to tasks within a project into the buffers—to protect due-date performance and avoid wasting this safety time through bad multitasking, student syndrome, Parkinson’s Law, and poorly synchronized integration.

Critical chain project management uses buffer management instead of earned value management to assess the performance of a project. Some project managers feel that the earned value management technique is misleading, because it does not distinguish progress on the project constraint (i.e., on the critical chain) from progress on non-constraints (i.e., on other paths). Event chain methodology can determine a size of project, feeding, and resource buffers.

A project plan or work breakdown structure (WBS) is created in much the same fashion as with critical path. The plan is worked backward from a completion date with each task starting as late as possible.

A duration is assigned to each task. Some software implementations add a second duration: one a “best guess,” or 50% probability duration, and a second “safe” duration, which should have higher probability of completion (perhaps 90% or 95%, depending on the amount of risk that the organization can accept). Other software implementations go through the duration estimate of every task and remove a fixed percentage to be aggregated into the buffers.

Resources are assigned to each task, and the plan is resource leveled, using the aggressive durations. The longest sequence of resource-leveled tasks that lead from beginning to end of the project is then identified as the critical chain. The justification for using the 50% estimates is that half of the tasks will finish early and half will finish late, so that the variance over the course of the project should be zero.

Recognizing that tasks are more likely to take more time than less time due to Parkinson’s law, Student syndrome, or other reasons, CCPM uses “buffers” to monitor project schedule and financial performance. The “extra” duration of each task on the critical chain—the difference between the “safe” durations and the 50% durations—is gathered in a buffer at the end of the project. In the same way, buffers are gathered at the end of each sequence of tasks that feed into the critical chain. The date at the end of the project buffer is given to external stakeholders as the delivery date. Finally, a baseline is established, which enables financial monitoring of the project.

An alternate duration-estimation methodology uses probability-based quantification of duration using Monte Carlo simulation. In 1999, a researcher[who?] applied simulation to assess the impact of risks associated with each component of project work breakdown structure on project duration, cost and performance. Using Monte Carlo simulation, the project manager can apply different probabilities for various risk factors that affect a project component. The probability of occurrence can vary from 0% to 100% chance of occurrence. The impact of risk is entered into the simulation model along with the probability of occurrence. The number of iterations of Monte Carlo simulation depend on the tolerance level of error and provide a density graph illustrating the overall probability of risk impact on project outcome.

When the plan is complete and the project is ready to start, the project network is fixed and the buffers’ sizes are “locked” (i.e., their planned duration may not be altered during the project), because they are used to monitor project schedule and financial performance.

With no slack in the duration of individual tasks, resources are encouraged to focus on the task at hand to complete it and hand it off to the next person or group. The objective here is to eliminate bad multitasking. This is done by providing priority information to all resources. The literature draws an analogy with a relay race. Each element on the project is encouraged to move as quickly as they can: when they are running their “leg” of the project, they should be focused on completing the assigned task as quickly as possible, with minimization of distractions and multitasking. In some case studies, actual batons are reportedly hung by the desks of people when they are working on critical chain tasks so that others know not to interrupt. The goal, here, is to overcome the tendency to delay work or to do extra work when there seems to be time. The CCPM literature contrasts this with “traditional” project management that monitors task start and completion dates. CCPM encourages people to move as quickly as possible, regardless of dates.

Because task duration has been planned at the 50% probability duration, there is pressure on resources to complete critical chain tasks as quickly as possible, overcoming student’s syndrome and Parkinson’s Law.

According to proponents, monitoring is, in some ways, the greatest advantage of the Critical Chain method. Because individual tasks vary in duration from the 50% estimate, there is no point in trying to force every task to complete “on time;” estimates can never be perfect. Instead, we monitor the buffers created during the planning stage. A fever chart or similar graph can be created and posted to show the consumption of buffer as a function of project completion. If the rate of buffer consumption is low, the project is on target. If the rate of consumption is such that there is likely to be little or no buffer at the end of the project, then corrective actions or recovery plans must be developed to recover the loss. When the buffer consumption rate exceeds some critical value (roughly: the rate where all of the buffer may be expected to be consumed before the end of the project, resulting in late completion), then those alternative plans need to be implemented.

Critical sequence was originally identified in the 1960s.

Tzvi Raz, Robert Barnes and Dov Dvir, Project Management Journal, December 2003.

Get More PRINCE2 Information by Clicking HERE

Project Engineering

Project engineering includes all parts of the design of manufacturing or processing facilities, either new or modifications to and expansions of existing facilities. A “project” consists of a coordinated series of activities or tasks performed by engineers, designers, drafters and others from one or more engineering disciplines or departments. Project tasks consist of such things as performing calculations, writing specifications, preparing bids, reviewing equipment proposals and evaluating or selecting equipment and preparing various lists, such as equipment and materials lists, and creating drawings such as electrical, piping and instrumentation diagrams, physical layouts and other drawings used in design and construction. A small project may be under the direction of a project engineer. Large projects are typically under the direction of a project manager or management team. Some facilities have in house staff to handle small projects, while some major companies have a department that does internal project engineering. Large projects are typically contracted out to engineering companies. Staffing at engineering companies varies according to the work load and duration of employment may only last until an individual’s tasks are completed.

The role of the project engineer can often be described as that of a liaison between the project manager and the technical disciplines involved in a project. The distribution of “liaising” and performing tasks within the technical disciplines can vary wildly from project to project; this often depends on the type of product, its maturity, and the size of the company, to name a few. It is important for a project engineer to understand that balance. The project engineer should be knowledgeable enough to be able to speak intelligently within the various disciplines, and not purely be a liaison. The project engineer is also often the primary technical point of contact for the consumer.

A project engineer’s responsibilities include schedule preparation, pre-planning and resource forecasting for engineering and other technical activities relating to the project. They may also be in charge of performance management of vendors. They assure the accuracy of financial forecasts, which tie-in to project schedules. They ensure projects are completed according to project plans. Project engineers manage project team resources and training and develop extensive project management experience and expertise.

When use, an engineering company is generally contracted to conduct a study (capital cost estimate or technical assessment) or to design a project. Projects are designed to achieve some specific objective, ranging in scope from simple modifications to new factories or expansions costing hundreds of millions or even billions of dollars. The client usually provides the engineering company with a scoping document listing the details of the objective in terms of such things as production rate and product specifications and general to specific information about processes and equipment to be used and the expected deliverables, such as calculations, drawings, lists, specifications, schedules, etc. The client is typically involved in the entire design process and makes decisions throughout, including the technology, type of equipment to use, bid evaluation and supplier selection, the layout of equipment and operational considerations. Depending on the project the engineering company may perform material and energy balances to size equipment and to quantify inputs of materials and energy (steam, electric power, fuel). This information is used to write specifications for the equipment. The equipment specifications are sent out for bids. The client, the engineering company or both select the equipment. The equipment suppliers provide drawings of the equipment, which are used by the engineering company’s mechanical engineers, and drafters to make general arrangement drawings, which show how the pieces of equipment are located in relation to other equipment. Layout drawings show specific information about the equipment, electric motors powering the equipment and such things as auxiliary equipment (pumps, fans, air compressors), piping and buildings. The engineering company maintains an equipment list with major equipment, auxiliary equipment, motors, etc. Electrical engineers are involved with power supply to motors and equipment. Process engineers perform material and energy balances and design the piping and instrumentation diagrams to show how equipment is supplied with process fluids, water, air, gases, etc. and the type of control loops used. The instrumentation and controls engineers specify the instrumentation and controls and handle any computer controls and control rooms. Civil and structural engineers deal with site layout and engineering, building design and structural concerns like foundations, pads, structures, supports and bracing for equipment. Environmental engineers deal with any air emissions and treatment of liquid effluent.

The various fields and topics that projects engineers are involved with include:

Project engineers are often project managers with qualifications in engineering or construction management. Other titles include field engineer, construction engineer, or construction project engineer. In smaller projects, this person may also be responsible for contracts and will be called an assistant project manager. A similar role is undertaken by a client’s engineer or owner’s engineer, but by inference, these often act more in the interests of the commissioning company.

Project engineers do not necessarily do design work, but instead represent the contractor or client out in the field, help tradespeople interpret the job’s designs, ensure the job is constructed according to the project plans, and assist project controls, including budgeting, scheduling, and planning. In some cases a project engineer is responsible for assisting the assigned project manager with regard to design and a project and with the execution of one or more simultaneous projects in accordance with a valid, executed contract, per company policies and procedures and work instructions for customized and standardized plants.

Typical responsibilities may include: daily operations of field work activities and organization of subcontractors; coordination of the implementation of a project, ensuring it is being built correctly; project schedules and forecasts; interpretation of drawings for tradesmen; review of engineering deliverables; redlining drawings; regular project status reports; budget monitoring and trend tracking; bill of materials creation and maintenance; effective communications between engineering, technical, construction, and project controls groups; and assistance to the project manager.

Get More PRINCE2 Information by Clicking HERE

Organizational Project Management

The term Organizational Project Management (OPM) was coined by John Schlichter in May 1998 in a meeting of the Standards Committee of the Project Management Institute. OPM was defined as the execution of an organization’s strategies through projects by combining the systems of portfolio management, program management, and project management. This definition was approved by a team of hundreds of professionals from 35 countries and was published as part of PMI’s Organizational Project Management Maturity Model standard in 2003 and updated later to a second edition in 2008 when it also became an ANSI standard. The standard was updated to a third edition in 2013. The term “Organizational Project Management” should be capitalized because the term is a conventional designation for exactly the systems of processes elaborated in ANSI/PMI 08-004-2008, because it is a proper name for that system and that system is definitive and regimented in its application, and because it does not denote generically any project management that is done in organizations.

According to PMI (2003, 2008, 2013)

Organizational Project Management is the systematic management of projects, programs, and portfolios in alignment with the achievement of strategic goals. The concept of organizational project management is based on the idea that there is a correlation between an organization’s capabilities in project management, program management, and portfolio management and the organization’s effectiveness in implementing strategy.

Get More PRINCE2 Information by Clicking HERE

Tasks in Project Management

In project management, a task is an activity that needs to be accomplished within a defined period of time or by a deadline to work towards work-related goals. It is a small essential piece of a job that serves as a means to differentiate various components of a project. A task can be broken down into assignments which should also have a defined start and end date or a deadline for completion. One or more assignments on a task puts the task under execution. Completion of all assignments on a specific task normally renders the task completed. Tasks can be linked together to create dependencies.

Tasks completion generally requires the coordination of others. Coordinated human interaction takes on the role of combining the integration of time, energy, effort, ability, and resources of multiple individuals to meet a common goal. Coordination can also be thought of as the critical mechanism that links or ties together the efforts on the singular level to that of the larger task being completed by multiple members. Coordination allows for the successful completion of the otherwise larger tasks that one might encounter.

Get More PRINCE2 Information by Clicking HERE

Project Sponsorship

Project sponsorship is the ownership of projects on behalf of the client organization.

There are two main differences between project sponsorship and project management. Firstly project sponsorship includes the identification and definition of the project whereas project management is concerned with delivering a project that is already defined, if only quite loosely.
Secondly the project sponsor is responsible for the project’s business case and should not hesitate to recommend cancellation of the project if the business case no longer justifies the project.

Project sponsors can encourage separation of decision making responsibilities between project manager and project sponsor, accountability for the realisation of project benefits, oversight of the project management function and can carry out senior stakeholder management.

The project sponsor or executive sponsor needs a range of skill sets, or at least access to skill sets which include appreciation of corporate strategy; ability to prepare a business case and profound knowledge of the organization’s operations. The project sponsor also needs to know his or her way around the organization and command respect within it. The project sponsor and project manager should form an effective partnership with the project manager orchestrating all players involved in delivering the project e.g. designers, manufacturers and contractors, whilst the project sponsor coordinates all departments of the client organization and associated stakeholders so as to integrate the delivered project into the client organization and take full benefits from it such that the business case is fulfilled.

Because the project sponsor is the ‘owner’ of the project from conception to commissioning and operation it is particularly important to achieve continuity of sponsor throughout the project yet correspondingly difficult to achieve because of the extended duration of sponsorship compared to project management.

Get More PRINCE2 Information by Clicking HERE

Change Control

15Change control within quality management systems (QMS) and information technology (IT) systems is a process—either formal or informal—used to ensure that changes to a product or system are introduced in a controlled and coordinated manner. It reduces the possibility that unnecessary changes will be introduced to a system without forethought, introducing faults into the system or undoing changes made by other users of software. The goals of a change control procedure usually include minimal disruption to services, reduction in back-out activities, and cost-effective utilization of resources involved in implementing change.

Change control is used in various industries, including in IT, software development, the pharmaceutical industry, the medical device industry, and other engineering/manufacturing industries. For the IT and software industries, change control is a major aspect of the broader discipline of change management. Typical examples from the computer and network environments are patches to software products, installation of new operating systems, upgrades to network routing tables, or changes to the electrical power systems supporting such infrastructure.

Certain portions of the Information Technology Infrastructure Library cover change control.

There is considerable overlap and confusion between change management, configuration management and change control. The definition below is not yet integrated with definitions of the others.

Change control can be described as a set of six steps:

Consider the primary and ancillary details of the proposed change. Should include aspects such as identifying the change, its owner(s), how it will be communicated and executed, how success will be verified, the change’s estimate of importance, its added value, its conformity to business and industry standards, and its target date for completion.

Impact and risk assessment is the next vital step. When executed, will the proposed plan cause something to go wrong? Will related systems be impacted by the proposed change? Even minor details should be considered during this phase. Afterwards, a risk category should ideally be assigned to the proposed change: high-, moderate-, or low-risk. High-risk change requires many additional steps such as management approval and stakeholder notification, whereas low-risk change may only require project manager approval and minimal documentation. If not addressed in the plan/scope, the desire for a backout plan should be expressed, particularly for high-risk changes that have significant worst-case scenarios.

Whether it’s a change controller, change control board, steering committee, or project manager, a review and approval process is typically required. The plan/scope and impact/risk assessments are considered in the context of business goals, requirements, and resources. If, for example, the change request is deemed to address a low severity, low impact issue that requires significant resources to correct, the request may be made low priority or shelved altogether. In cases where a high-impact change is requested but without a strong plan, the review/approval entity may request a full business case may be requested for further analysis.

If the change control request is approved to move forward, the delivery team will execute the solution through a small-scale development process in test or development environments. This allows the delivery team an opportunity to design and make incremental changes, with unit and/or regression testing. Little in the way of testing and validation may occur for low-risk changes, though major changes will require significant testing before implementation. They will then seek approval and request a time and date to carry out the implementation phase. In rare cases where the solution can’t be tested, special consideration should be made towards the change/implementation window.

In most cases a special implementation team with the technical expertise to quickly move a change along is used to implement the change. The team should also be implementing the change not only according to the approved plan but also according to organizational standards, industry standards, and quality management standards. The implementation process may also require additional staff responsibilities outside the implementation team, including stakeholders who may be asked to assist with troubleshooting. Following implementation, the team may also carry out a post-implementation review, which would take place at another stakeholder meeting or during project closing procedures.

The closing process can be one of the more difficult and important phases of change control. Three primary tasks at this end phase include determining that the project is actually complete, evaluating “the project plan in the context of project completion,” and providing tangible proof of project success. If despite best efforts something went wrong during the change control process, a post-mortem on what happened will need to be run, with the intent of applying lessons learned to future changes.

In a Good Manufacturing Practice regulated industry, the topic is frequently encountered by its users. Various industrial guidances and commentaries are available for people to comprehend this concept. As a common practice, the activity is usually directed by one or more SOPs. From the information technology perspective for clinical trials, it has been guided by another U.S. Food and Drug Administration document.

Get More PRINCE2 Information by Clicking HERE

Project Plan Document

The Project Management Plan Document also known as Project Plan Document or simply Project Plan is a document that contains the strategy for managing the project and the processes related to all areas of the project (scope, cost, schedule, quality, etc.) which are known as Knowledge Areas according to PMI. There are lots of project management processes mentioned in PMBOK® Guide, but determining what processes need to be used based on the needs of the project which is called Tailoring is part of developing the project management plan

The project plan document may include the following sections:

A High level overview of the project

The roles and authority of team members. It represents the executive summary of the Project Management Plan

The scope statement from the Project charter should be used as a starting point with more details about what the project includes and what it does not include (In-Scope and Out-Of-Scope)

A list of the project Milestones (the stop points that helps evaluating the progress of the project). This list includes the milestone name, a description about the milestone, and the date expected.

WBS which consists of Work Packages and WBS Dictionary, which defines these work packages, as well as Schedule Baseline, which is the reference point for managing project progress, are included here.

This section contains all management plans of all project aspects

Identify key resources needed for the project and their times and durations of need.

This section includes the budgeted total of each phase of the project and comments about the cost.

Acceptable levels of quality.

Some space for the project sponsor to sign off the document

Get More PRINCE2 Information by Clicking HERE

Work Project Management

Image by/from WikiMedia Commons

Work more precise the “joint” or the “council” (3 in to 12 elements) for an “administration in project management” is the amount of effort applied to produce a deliverable or to accomplish a task (a terminal element) or a group of related tasks defined at the same level in the WBS.

Get More PRINCE2 Information by Clicking HERE

Project Risk Management

Image by/from Kokcharov

Project risk management is an important aspect of project management. Project risk is defined by PMI as, “an uncertain event or condition that, if it occurs, has a positive or negative effect on a project’s objectives.”

Project risk management remains a relatively undeveloped discipline, distinct from the risk management used by Operational, Financial and Underwriters’ risk management. This gulf is due to several factors: Risk Aversion, especially public understanding and risk in social activities, confusion in the application of risk management to projects, and the additional sophistication of probability mechanics above those of accounting, finance and engineering.

With the above disciplines of Operational, Financial and Underwriting risk management, the concepts of risk, risk management and individual risks are nearly interchangeable; being either personnel or monetary impacts respectively. Impacts in project risk management are more diverse, overlapping monetary, schedule, capability, quality and engineering disciplines. For this reason, in project risk management, it is necessary to specify the differences (paraphrased from the “Department of Defense Risk, Issue, and Opportunity Management Guide for Defense Acquisition Programs”):

An improvement on the PMBOK definition of risk management is to add a future date to the definition of a risk. Mathematically, this is expressed as a probability multiplied by an impact, with the inclusion of a future impact date and critical dates. This addition of future dates allows predictive approaches.

Good Project Risk Management depends on supporting organizational factors, having clear roles and responsibilities, and technical analysis.

Chronologically, Project Risk Management may begin in recognizing a threat, or by examining an opportunity. For example, these may be competitor developments or novel products. Due to lack of definition, this is frequently performed qualitatively, or semi-quantitatively, using product or averaging models. This approach is used to prioritize possible solutions, where necessary.

In some instances it is possible to begin an analysis of alternatives, generating cost and development estimates for potential solutions.

Once an approach is selected, more familiar risk management tools and a general project risk management process may be used for the new projects:

Finally, risks must be integrated to provide a complete picture, so projects should be integrated into enterprise wide risk management, to seize opportunities related to the achievement of their objectives.

In order to make project management effective, the managers use risk management tools. It is necessary to assume the measures referring to the same risk of the project and accomplishing its objectives.

The project risk management (PRM) system should be based on the competences of the employees willing to use them to achieve the project’s goal. The system should track down all the processes and their exposure which occur in the project, as well as the circumstances that generate risk and determine their effects. Nowadays, the Big Data (BD) analysis appears an emerging method to create knowledge from the data being generated by different sources in production processes. According to Gorecki, the BD seems to be the adequate tool for PRM.

Get More PRINCE2 Information by Clicking HERE

Process Area Capability Maturity Model Integration (CMMI)

The Capability Maturity Model Integration (CMMI) defines a Process Area as, “A cluster of related practices in an area that, when implemented collectively, satisfies a set of goals considered important for making improvement in that area.” Both CMMI for Development v1.3 and CMMI for Acquisition v1.3 identify 22 process areas, whereas CMMI for Services v1.3 identifies 24 process areas. Many of the process areas are the same in these three models.

In CMMI models, the process areas are organized in alphabetical order according to their acronym. However, process areas can be grouped according to maturity levels or process area categories.

There are Five maturity levels. However, maturity level ratings are awarded for levels 2 through 5. The process areas below and their maturity levels are listed for the CMMI for Development model:

Maturity Level 2 – Managed

Maturity Level 3 – Defined

Maturity Level 4 – Quantitatively Managed

Maturity Level 5 – Optimizing

The process areas below and their maturity levels are listed for the CMMI for Services model:

Maturity Level 2 – Managed

Maturity Level 3 – Defined (this includes the process areas that make up the previous levels; Maturity Level 3 is made up of the process areas in Level 2 and Level 3)

Maturity Level 4 – Quantitatively Managed

Maturity Level 5 – Optimizing

The process areas below and their maturity levels are listed for the CMMI for Acquisition model:

Maturity Level 2 – Managed

Maturity Level 3 – Defined

Maturity Level 4 – Quantitatively Managed

Maturity Level 5 – Optimizing

There are two categories of goals and practices: generic and specific. Specific goals and practices are specific to a process area. Generic goals and practices are a part of every process area. A process area is satisfied when organizational processes cover all of the generic and specific goals and practices for that process area.

Generic goals and practices are a part of every process area.

Each process area is defined by a set of goals and practices. These goals and practices appear only in that process area.

CMMI for Development, Version 1.2 contains 22 process areas indicating the aspects of product and service development that are to be covered by organizational processes. For a summary of process areas for each model, see these quick reference documents available on the SEI website:

Purpose

The purpose of Agreement Management (AM) is to ensure that the supplier and the acquirer perform according to the terms of the supplier agreement.

Specific Practices by Goal

Purpose

The purpose of Capacity and Availability Management (CAM) is to ensure effective service system performance and
ensure that resources are provided and used effectively to support service requirements.

Specific Practices by Goal

Purpose

The purpose of Causal Analysis and Resolution (CAR) is to identify causes of selected outcomes and take action to improve process performance.

Specific Practices by Goal

Purpose

The purpose of Configuration Management (CM) is to establish and maintain the integrity of work products using configuration identification, configuration control, configuration status accounting, and configuration audits.

Specific Practices by Goal

Purpose

The purpose of Decision Analysis and Resolution (DAR) is to analyze possible decisions using a formal evaluation process that evaluates identified alternatives against established criteria.

Specific Practices by Goal

Purpose

The purpose of Integrated Project Management (IPM) is to establish and manage the project and the involvement of relevant stakeholders according to an integrated and defined process that is tailored from the organization’s set of standard processes.

Specific Practices by Goal

Purpose

The purpose of Measurement and Analysis (MA) is to develop and sustain a measurement capability used to support management information needs.

Specific Practices by Goal

Purpose

The purpose of Organizational Process Definition (OPD) is to establish and maintain a usable set of organizational process assets, work environment standards, and rules and guidelines for teams.

Specific Practices by Goal

Purpose

The purpose of Organizational Process Focus (OPF) is to plan, implement, and deploy organizational process improvements based on a thorough understanding of current strengths and weaknesses of the organization’s processes and process assets.

Specific Practices by Goal

Purpose

The purpose of Organizational Performance Management (OPM) is to proactively manage the organization’s performance to meet its business objectives.

Specific Practices by Goal

Purpose

The purpose of Organizational Process Performance (OPP) is to establish and maintain a quantitative understanding of the performance of selected processes in the organization’s set of standard processes in support of achieving quality and process performance objectives, and to provide process performance data, baselines, and models to quantitatively manage the organization’s projects.

Specific Practices by Goal

Purpose

The purpose of Organizational Training (OT) is to develop skills and knowledge of people so they can perform their roles effectively and efficiently.

Specific Practices by Goal

Purpose

The purpose of Product Integration (PI) is to assemble the product from the product components, ensure that the product, as integrated, behaves properly (i.e., possesses the required functionality and quality attributes), and deliver the product.

Specific Practices by Goal

Purpose

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

Specific Practices by Goal

Purpose

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

Specific Practices by Goal

Purpose

The purpose of Process and Product Quality Assurance (PPQA) is to provide staff and management with objective insight into processes and associated work products.

Specific Practices by Goal

Purpose

The purpose of the Quantitative Project Management (QPM) process area is to quantitatively manage the project to achieve the project’s established quality and process performance objectives.

Specific Practices by Goal

Purpose

The purpose of Requirements Development (RD) is to elicit, analyze, and establish customer, product, and product component requirements.

Specific Practices by Goal

Purpose

The purpose of Requirements Management (REQM) is to manage requirements of the project’s products and product components and to ensure alignment between those requirements and the project’s plans and work products.

Specific Practices by Goal

Purpose

The purpose of Risk Management (RSKM) is to identify potential problems before they occur so that risk handling activities can be planned and invoked as needed across the life of the product or project to mitigate adverse impacts on achieving objectives.

Specific Practices by Goal

Purpose

The purpose of Supplier Agreement Management (SAM) is to manage the acquisition of products from suppliers.

Specific Practices by Goal

Purpose

The purpose of Technical Solution (TS) is to select design and implement solutions to requirements. Solutions, designs, and implementations encompass products, product components, and product related lifecycle processes either singly or in combination as appropriate.

Specific Practices by Goal

Purpose

The purpose of Validation (VAL) is to demonstrate that a product or product component fulfills its intended use when placed in its intended environment.

Specific Practices by Goal

Purpose

The purpose of Verification (VER) is to ensure that selected work products meet their specified requirements.

Specific Practices by Goal

Only changes made to the set of Process Areas are considered here. For more information about the changes made to Version 1.2, see the Version 1.2 Release Notes or for the definitive list of changes, take the CMMI Version 1.2 Upgrade Training.

Some significant improvements in CMMI-DEV, V1.3 include the following:

For a more complete and detailed list of improvements, see http://www.sei.cmu.edu/cmmi/tools/cmmiv1-3/comparison.cfm. An overview of the changes is described in http://www.benlinders.com/2011/cmmi-v1-3-summing-up/.

Table: Process Areas, Categories, and Maturity Levels

Get More PRINCE2 Information by Clicking HERE