CMMI - Introduction

This blog is intended to develop an understanding of CMMI so that process improvements can be better applied by its reader to their projects.

• What is CMMI?
• Why CMMI?
• What are it's characteristics?
• What are the CMMI levels?
• What are Process areas?
• What are the benefits of being at Level 5?

These are some of the things we will look at in this blog various posts. This is the first in the series of posts that will explore CMMI.

In first post - What is CMMI and Why CMMI?

WHAT?

There are lot's of definitions for CMM. One good one is this:

It defines how software organizations mature or improve in their ability to develop software.

The model was developed by Software Engineering Institute (SEI) of Carnegie Mellon University in late 80s. This model provides a structured view in a five-layer model of increasingly sophisticated practices for those working in software.

Each level (except Level 1) has certain Key Process Areas associated with it. Each level addresses levels of maturity exhibited by the project. The first version of CMM came in early 90s.

Around 1999, SEI took up an integration project. There were multiple CMM models in place - one for software development, one for Integrated process and product development, one for systems engineering etc.

Organizations (and SEI!) found it difficult to live with multiple models. Hence this project integrated the different CMM models into one and thus CMM - Integrated , CMMI came into being.

The structure of CMMI is similar to CMM.

WHY?

CMMI describes how software organizations can take the path of continuous improvement which is so required in this highly competitive world. Moreover, it is a model that can be tailored to suit the organization. "Keep Improving" - is the CMMI key message.

CMMI also creates brand value and many clients are demanding it.

SEI website - www.sei.cmu.edu

Any questions/comments/feedback, please mail to - know.cmmi@gmail.com or leave a comment here.

Next is - CMMI - Overview and 5 Levels

Read more...

CMMI - Overview and 5 Levels

This post will have an overview of CMMI and its Levels.

CMMI was formed by merging multiple CMM models like CMM for software, CMM for Systems Engineering, CMM for Integrated process and product development etc.

As managing multiple CMM models is difficult, SEI integrated all CMM models into one - CMM Integrated. The structure and essence of CMMI is same as that of CMM. As in CMM, in CMMI also there are 5 levels of maturity:

Level 1 : Initial or Ad-hoc. There are no PAs (Process Areas) in this level

Level 2 : Managed. There are 7 PAs. PAs at this level look at project planning and execution (Basic project management)

Level 3 : Defined. There are 13 PAs here. Life cycle processes and Organizational processes are the focus areas here.

Level 4 : Quantitatively Managed. There are 2 PAs that deal with project management with quantitative data and statistical process control. (SPC)

Level 5 : Optimizing. There are 2 PAs. The focus is on continuous improvement.

* PA - Process Area

What is PA?

PAs are activities where Software organizations and Projects have to focus in the path towards excellence and maturity.

There are total 24 PAs in all.

Characteristics of a Mature Organization

A mature software organization possesses an organization-wide ability for managing software development and maintenance processes. The software process is accurately communicated to both existing staff and new employees, and work activities are carried out according to the planned process. The processes mandated are fit for use and consistent with the way the work actually gets done. These defined processes are updated when necessary, and improvements are developed through controlled pilot-tests and/or cost benefit analyses. Roles and responsibilities within the defined process are clear throughout the project and across the organization.

The CMM / CMMI model was designed to guide software organizations in selecting process improvement strategies by determining current process maturity and identifying the few issues most critical to software quality and process improvement.

As we move from Level 1 to 5, the project risk decreases & Quality and Productivity increases.

Previous - CMMI - Introduction
Next - Level 1: Initial of CMMI

Read more...

CMMI - Level 1 - INITIAL

Level 1 is called the Initial or Ad-Hoc Level.

Level 1 is an immature state. The software process is characterized as ad hoc, and occasionally even chaotic. Few processes are defined, and success depends on individual effort. Here there is no objective basis for judging product quality or for solving product or process problems. Therefore product quality is difficult to predict. Activities intended to enhance quality such as reviews and testing are often curtailed or eliminated when projects fall behind schedule.

Below points are the characteristics of this level:

- The processes within the organization are highly unstable and unpredictable
- During crisis, all the processes and procedures are either abandoned or skipped
- The projects are purely person dependant. i.e., when the persons involved leave the project or the company, things come to a halt. Also, the performance depends on the capabilities of the individuals rather then the organizational capability.
- Even if some processes remain, they are constantly changed or modified as the work progresses. (i.e.., the process is ad hoc).

There are NO process areas at Level 1. Level 1 is just a denotation of ad-hoc behaviour.

Previous - CMMI Overview and 5 Levels

Next - CMMI - Level 2 - Managed

For questions/comment, write to know.cmmi@gmail.com or leave a comment here.

Read more...

CMMI - Level 2 - Managed

Managed, as the word means, the project management is defined at this level. Basic project management principles are established to track cost, schedule and functionality. The necessary process discipline is in place to repeat earlier success on projects.

An effective process can be characterized as practiced, documented, enforced, trained, measured, and able to improve.

Projects in Level 2 organizations have installed basic software management controls. Some of the important points are:

1. Realistic project commitments are based on the results observed on previous projects and on the requirements of the current project.

2. The project managers for a project track software costs, schedules, defects and functionality; problems in meeting commitments are identified when they arise.

3. The project's process is under the effective control of a project management system, following realistic plans based on the performance of previous projects.

Level 2 has got 7 Process Areas. And they are:

1. Requirements Management
2. Project Planning
3. Project Monitoring and Control
4. Configuration Management
5. Measurement and Analysis
6. Process and Product quality assurance
7. Supplier agreement management

Each process area has certain goals which needs to be met by the organization. From tomorrow, we shall start looking at each process area at level 2 and their goals in detail.

Previous - CMMI - Level 1 - Initial

Next - CMMI - L 2- Managed - Requirements Management

For question, write to know.cmmi@gmail.com or leave a comment here.

Read more...

CMMI - L 2 - Manage - Requirements Management

This is first Process Area (PA) of Level 2.

As we know each PA has set of goals and so the Requirement Management has one GOAL - Manage Requirement.

Manage Requirements

Requirements are managed and inconsistencies with project plans and work products are identified.

The purpose of Requirements Management is to establish a common understanding between the customer and the project team. This would also involve identifying inconsistencies between the requirements and project's plan and work products.

Requirements Management involves establishing and maintaining an agreement with the customer on the requirements for the software project. The requirements would include both technical and non technical requirements like performance. This agreement is referred to as the "system requirements allocated to the software."

To achieve this control, the project team reviews the initial and revised system requirements allocated to software to resolve issues before they are incorporated into the software project.

Whenever the system requirements allocated to software are changed, the affected software plans, work products, and activities are adjusted to remain consistent with the updated requirements. For this to happen, requirements and requirement changes are managed by documenting them, and maintaining traceability between requirements and all work products like design, test plans etc.

Apart from specific goals, each PA will have a set of generic goals on how the process area is institutionalized across the organization.

If we look at the various activities that are performed, the summary is as below:

- The software requirements are reviewed by the team, and the requirements are used as the basis for further planning.
- Traceability is established between requirements and other life cycles. Any changes to the requirements are reviewed. (Impact analysis, Change management process).

Impact of Requirement Change on the schedule and plan must be comprehended and managed.

"Please note that this process area does not talk about how requirements are gathered. This comes at Level 3 only."

Previous - CMMI - Level 2 - Manage

Next - CMMI - L2 - Manage - Project Planning

Read more...

CMMI - L 2 - Manage - Project Planning

The second PA in Level 2 is Project Planning.

As the name suggests, this involves establishing reasonable plans for performing the software engineering and for managing the software project. Software Project Planning involves developing estimates for the work to be performed, establishing the necessary commitments, and defining the plan to perform the work.

Some of the goals are :

Goal 1: Establish Estimates - Software estimates are prepared for use in planning and tracking the software project

Goal 2: Develop a project plan

Goal 3: Obtain commitment to the plan - Commitments are obtained from all stake holders.

Some of the activities performed are :

- The software engineering group(i.e project team) participates on the project proposal Software project planning is initiated in the early stages of, and in parallel with, the overall project planning

- The project team participates with other affected groups in the overall project planning throughout the project's life

- A software life cycle with predefined stages of manageable size is identified or defined.

- The project's software development plan is developed according to a documented procedure.

- Estimates for the size of the software work products (or changes to the size of software work products) are derived according to a standard procedure

- Estimates for the software project's effort and costs are derived according to a documented procedure. Similarly the project risks, schedule etc are derived according to a defined procedure.

Project plan and schedule are revised as and when project scope is increased or any other threshold limits are reached.


Previous - CMMI - L2 - Manage - Requirement Management

Next - CMMI - L2 - Manage - Project Monitoring and Control

For question, write to know.cmmi@gmail.com or leave a comment here.

Read more...

CMMI - L 2 - Manage - Monitoring and Control

The purpose of Project Monitoring and Control is to provide adequate visibility into actual progress, so that team as well as management can take effective actions when the software project's performance deviates significantly from the software plans.

Software Project monitoring and control involves tracking and reviewing the software accomplishments and results against documented estimates, commitments, and plans, and adjusting these plans based on the actual accomplishments and results.

There are 2 goals in this process area.

Goal 1: Monitor Project against plan

Goal 2: Manage corrective action against closure

A documented Plan (Project Management Plan) is used for tracking. Some of the items that are tracked are:

- Effort (through TimeSheets)
- Size
- Schedule (Microsoft project or similar tools)
- Defects (RADAR)
- Risks

The data thus captured helps not only the project in tracking, but also the organization. The data is collated at organization level to see what is the average level of performance of projects. This happens at Level 4.

In general, Milestone reports and Metrics reports are prepared.

Apart from these, projects generally tracked throug weekly and/or monthly status reports.


Previous - CMMI - L2 - Manage - Project Planning

Next - CMMI - L2 - Manage - Configuration Management

For questions, writes to know.cmmi@gmail.com or leave a comment here.

Read more...

CMMI - L 2 - Manage - Configuration Control

The purpose of Configuration Management is to establish and maintain the integrity of the products of the software project throughout the project's software life cycle.

These are ensured using identifying configuration products, controlling them, status accounting (is the status of an item clear?) and configuration audits.

A software baseline library is established containing the software baselines as they are developed. Changes to baselines and the release of software products built from the software baseline library are systematically controlled via the change control and configuration auditing functions. Tools, as required are used for the same.

Examples: Visual Source Safe (VSS), PVCS, Endevor etc.

The Goals at this level are :

1. Establish Baselines -Baselines of identified work products are established

2. Track and control changes - Changes to the work products are tracked and controlled

3. Establish Integrity - Integrity of baselines is established. Integrity here refers to correctness. These are ensured by maintaining proper records and doing audits.

Some of the activities performed at this level include : Preparation of Configuration Management Plan, following it and doing audits.


Previous -

Next -

For questions, write to know.cmmi@gmail.com or leave a comment here.

Read more...

CMMI - L 2 - Manage - Measurement & Analysis

The objective of this PA is to develop and sustain a measurement capability that is used to support project and management information needs.

It involves specifying the objectives of measurement and analysis such that they are aligned with the identified information needs and objectives.

Exp - Think Size, Effort, Defects, Schedule and other parameters like SLA, Response time, System availability etc

Then the data collection and storage mechanism are identified.

Exp - Timesheets, Defect Reports

Implementing the collection, storage, analysis and reporting of data

Exp - Think Milestones, Metric reports, Status reports

Providing objective results that can be used in making informed decisions

Exp - Think actions that come of out milestone/metrics analysis

The goals for this PA are:

1. Align measurement and analysis activities2. Provide measurement results

The goals translate into - Identifying proper measurements and then collecting the same. The next step is to analyze the collected data to take decisions as necessary. By having this PA at Level 2, CMMI reinforces the fact that measurement and project management of data is very critical to project success.

What data need to be collected depends on project objectives. Apart from the 4 basic measures - Size, Effort, Defect and Schedule, the projects can decide critical data requirements and collect them.


Previous - CMMI - L2 - Manage - Configuration Management

Next - CMMI - L2 - Manage - Quality Assurance

For question, write to know.cmmi@gmail.com or leave a comment here.

Read more...

CMMI - L2 - Quality Management

Product and Process Quality Assurance is process area at Level 2.

The purpose of this process area is to provide the project and the management with objective insight into process quality of software

The objective here is to ensure that the right processes are followed. Towards this, quality assurance should begin in the early phases of a project to establish plans, processes, standards, and procedures that will add value to the project and satisfy the requirements of the project and the organizational policies.

As the project goes along, sufficient monitoring is in place (like audits, compliance checks) to ensure that the processes are followed and which results in a good quality final product.

Goals:

1. Objectively evaluate processes and work products ­ - Adherence to the process is objectively evaluated. Here “Objective” means use of a standard procedure for evaluation. Evaluation must be done in a structured manner (a checklist, for example) rather than in a superficial manner.

2. Provide objective insight - Non compliance issues are objectively tracked and communicated, and resolution is ensured.

Objective evaluation should be perform in one/more of the below ways:

- Compliance checks by SQAs
- Internal Audits by peer PMs
- Senior Manager's Review

The objective of the above activities is that:

- The right process as required are defined at the project level
- The project team is following the processes in the correct manner
- Any non conformances are identified as early as possible and corrected


Previous - Measurement & Analysis

Next - Supplier Agreement Management

For questions, write to know.cmmi@gmail.com or leave a comment here.

Read more...

CMMI - L 2 - Manage - Supplier Agreement Management

The purpose of Supplier Agreement Management process area is to manage the acquisition of products from suppliers through a formal agreement.

The salient features here are:

Determine if any product/software/tool need to be bought from a vendor:

- Select the vendor
- Establish an agreement with the vendor
- Test and accept the product/software/tool

Goals:

1. Establish Supplier Agreement
2. Satisfy Supplier Agreement

This process area is not applicable for many projects. It applies where project needs some external tools software and needs to be opt thru a suplier.

It also applies when we download tools or other things from Internet. The Supplier Agreement Management guidelines in QSD explains the process in detail.


Preivious - Quality Management

Next - CMMI - L 3 - Defined

Read more...

CMMI - Level 3 - Defined

Level 2 - The Managed or Repeatable level focused on building strong project management processes in the project.

Level 3 - The Defined Level, looks at building Engineering processes and organizational level processes using the strong base set at Level 2.

Level 3 is, when an organization will have processes for Requirements gathering, Design, Build, Reviews, Testing etc, defined at organization level. Best practices observed in many projects and experience of people is captured in organization wide guidelines and processes. These processes also give guidelines on how the processes must be tailored to suit individual projects. Information and artifacts of previous projects is available for re-use within the organization through mechanisms of knowledge sharing.

There are 13 process areas in Level 3 of CMMI. Apart from engineering processes and organizational level processes, there are a few process areas focused on certain critical aspects like risk management, decision making, team work etc:

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.


Previous - CMMI - L2 - Manage - Supplier Aggrement Management

Next - CMMI

For questions, please write to know.cmmi@gmail.com or leave a comment here.

Read more...

CMMI - L 3 - Defined - REDV, TS

Requirements Development (REDV)

The first process area at Level 3 is Requirements Development. The purpose of Requirements Development is to gather and analyze the customer requirements. The major activities are:

- Elicit proper and complete requirements from relevant stake holders.
- Develop the life cycle requirements
- Develop design requirements

Goal:

1. Develop Customer Requirements - equivalent to business requirements

2. Develop Product Requirements - equivalent to technical requirements

3. Analyze and Validate Requirements - use of methods like prototyping/simulation to validate the requirements

Proper requirements elicitation must ensure that requirements are not just correct, but complete too.

Technical Solution (TS)

This process area talks of design and coding processes.

The focus is on evaluating and selecting solutions (design approaches), developing detailed designs (Program Specifications) and implementing the design as a product (coding).

There are 3 goals here:
1. Select Product Component Solutions
2. Develop the Design
3. Implement the Product Design

One indicator of a good design process is that the design was chosen after comparing and evaluating it against alternative solutions.


Next - CMMI - L3 - Defined - PI, VAL, VER

Read more...

CMMI - L 3 - Defined - PI, VAL, VER

Product Integration

This process area is more focussed towards Systems Engineering. It talks of how big hardware and software systems are integrated. (This does not refer to Integration testing.) In software scenario, this refers to how different data streams (input, output) are integrated. That is, how the business flow is maintained.

Verification

Verification, as the name suggests is to ensure that the work products (all work products like Requirements, Design, code, test plans) meet their required criteria. The activities involved here are preparation for verification, performing the verification activity and identifying corrective actions.

The goals in this process area are:

1. Prepare for Verification
2. Perform Peer reviews
3. Verify selected work products

All reviews, Unit testing, Integration testing and System testing come under part of verification. Specific significance is given to reviews, since finding and correcting defects through reviews, very early, is highly cost effective. Also, you cannot “test” a requirement document or a design document – you can “review” them !

Experience has proved that cost of rework increases by a factor of up to 100, as we find defects late. Earlier the defects are found, the better. That is where a formal review process (with standards, checklists) help.

Validation

Validation on the other hand, focuses on Acceptance testing. This is to demonstrate that a product fulfills its intended use. Actually the differentiating line between Verification and Validation is very thin.

The goals for Validation are:

1. Prepare for validation
2. Validate product


Next - CMMI - L3 - DEFINED - Risk Management

Read more...

CMMI - L 3 - Defined - Risk Management

The purpose of Risk Management 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

The goals of this process area are:

1. Prepare for Risk Management
2. Identify and Analyze risks
3. Mitigate risks
------------------------------------------------------------------------------------

A CEO of a leading company was once asked what single characteristic was most important while selecting a project manager.

He responded: “A person who has the ability to know what will go wrong before it actually does” .

This in essence highlights the importance of Risk Management. We live in a world of uncertainty. Understanding the risks involved and taking mitigation steps is of paramount importance to ensure success of the project.

Robert Charette, in his book, Software Risk Analysis and Management gives a definition of risk. Risk concerns future happenings. Whatever happened today and yesterday are out of scope of risk analysis. The question is how to adjust our actions today so that we are better prepared for tomorrow . Risk Mitigation is like insurance premium. To protect our family, and ourselves we pay a premium. This premium is calculated based on the probability of occurrence of any event.

To do an effective risk management, project managers need to do the following:

1. Risk Identification: Identify all risks in the project. Look at project objectives and goals and see what are all the reasons that you may give if you don’t meet them. All these are potential risks in your project!

2. A use of a risk item checklist is very important, since it gives visibility to things (risks) unknown to you.

3. Risk projection is the next step. That is, identifying the probability of occurrence of the risk, and the consequences or impact of the risk, should it occur. This serves to highlight the visible impact of the risk.

“We will see when it happens” – This type of statement may be true for politicians or super characters like James Bond. It seldom works for project managers. A proactive risk management strategy identifies risks at project initiation stage itself. The risks are continuously monitored and mitigation steps planned. I present below a case from one project. In this maintenance project, the customer manager changed. The project manager did not have an idea how the new manager would be. Customer response time was put as a risk that would impact schedule. Similarly, quality of issue resolution was put as another risk that would impact delivered quality. The project manager took effective mitigation steps. In this case, it included buffering in time for issue resolution and an extra review of the issues. One thing to remember is that mitigation steps require time (cost). But that is the premium we have to pay.

Things, which are already known, are not risks. For example, if you know that the team is new to that domain - it is not a risk. Many times, in project plans, it is seen that events, which have happened, or happening are put as risks. This should not be the case. Known facts are no longer risks. These are called constraints and should be handled right away in the plan. We should also be able to see the final impact of the risk. That is, if this risk materializes, what parameter in my project will go wrong – cost? or schedule? or defect levels? or performance of application etc.

A Chinese proverb said it well: Risk is project managers enemy. If you know your enemy, half the battle is won.


Next - CMMI - L3 - Defined - DAR, OPF, OPD

For questions, write to know.cmmi@gmail.com or leave a comment here.

Read more...

CMMI - L 3 - Defined - DAR, OPF, OPD

DAR - Decision Analysis and Resolution

Decision Analysis and Resolution, process area at L-3, is to analyze possible decisions (options) using a formal evaluation process that takes into account critical and established criteria.

The objective is to arrive at the “right” decision when we are confronted with multiple options. Both numeric criteria (like a weighted average method) and non-numeric criteria (like High, Medium, and Low) can be used during the evaluation process.

The aim is also that we identify multiple options and then choose the best one rather than going with the first option that comes to the mind.

DAR can be used in decision making situations like:

- Should I go for a .NET framework or J2EE framework
- Should I go for regression testing (in maintenance projects)
- Can I offshore the maintenance of a application
- The kind of design approach we should take, etc

Goal – Evaluate Alternatives.

The activities involved here are:

- Identifying evaluation criteria
- Identifying alternative solutions
- Select evaluation methods
- Evaluate alternative
- Select solutions

Organizational Process Focus (OPF)

OPF looks at planning and implementing process improvement based on current strengths and weaknesses. Organizations processes are the organization set of standard process.

The 2 goals for this PA are:

1. Determine process improvement opportunities
2. Plan and implement process improvement activities

Organizational Process Definition (OPD)

OPD on the other hand looks at how an organization establishes a usable set of process assets. The organization’s process asset library is a collection of items for use by the people and projects of the organization.

Organizations should have a system to capture as-is artifacts - Process Assets.

The goal at this PA is Establish organizational process assets

Next - CMMI - L3 - Defined - OT, IPM, IT, OET

Read more...

CMMI - L 3 - Defined - Organizational Training

Organizational Training (OT)

The purpose of OT is to develop skills and knowledge of people so that they can perform their roles effectively.

OT includes training to support the organizations strategic business objectives and tactical needs that are common across projects and support groups.

Note - that specific project related training are not included here. These are included in Project Planning PA itself.

The goals for OT are:

1. Establish an Organizational Training Capability – The organization must be capable to provide training

2. Provide Necessary Training – Necessary training is provided

One thing to note here is that collecting measurements and improvement areas are inherent part of all PAs. So, in OT, we collect metrics like Person hrs of training, training feedback, training effectiveness etc. Sometimes tests, quizzes or reverse presentations are conducted to evaluate how effective the training was.

IPM for IPPD - Integrated Project Management for Integrated Process and Product Development

The purpose of IPM is to establish and manage the project and the involvement of relevant stake holders according to an integrated and defined process that is tailored from the organizations’ set of processes. The key word to note here is tailoring. IPPD covers the establishment of a shared vision for the project and a team structure for integrated teams

The goals at this PA are:

1. Establish and Use the Project’s defined process (tailoring)
2. Coordinate and collaborate with relevant stakeholders
3. Use the project’s shared vision
4. Organize integrated teams


Next - CMMI - L 3 - IT and OEI
For questions, write to know.cmmi@gmail.com or leave a comment.

Read more...

CMMI - L 3 - Defined - IT and OEI

Integrated Teaming (IT)

The purpose of IT is to form and sustain an integrated team for the development of work products. The integrated team members share a common goal and vision. They operate in accordance with established operating principles and ground rules.

An example of integrated team – SAM + IVS or SAM + DCG etc. It can also be 2 different project teams who share a common program level goal

The goals at this PA are:

1. Establish Team Composition
2. Govern Team Operation

Organizational Environment for Integration (OEI) : The purpose of OEI is to provide the required infrastructure and manage people for integration. The organization must raise performance expectation from all projects while providing mechanisms that stimulate both team and individual excellence. Important things that the organization must provide are: workplace that maximizes productivity, set of standard processes and guidelines, tools, process assets etc.

The goals at this PA are:

1. Provide infrastructure
2. Manage people for Integration


Next - CMMI - Level 4 - Quantitatively Managed

For questions, write to know.cmmi@gmail.com or leave a comment here.

Read more...

CMMI - Level 4 - Quantitatively Managed

Level 4 - in CMMI is a very critical step.

At this level, the organization has achieved all the goals of PAs in Level 2, 3 and 4.

They key attribute of Level 4 is sub process performance. The selected sub processes are controlled using statistical and other quantitative techniques

At Level 4, process and project management happens through Quantitative techniques. Quantitative objectives are based on the needs of the client, end users, organization and process improvement. Quality and process performances are understood in statistical terms and are managed throughout the life of the processes.

For the various processes, measures of process performance are collected and statistically analyzed. Special Causes of process performance are identified and corrected to prevent future occurrences.

The crucial difference between Level 3 and 4 is Predictability.

At Level 4, performance of process is quantitatively predictable.

There are 2 PAs at this level:

1. Organizational Process Performance (OPP)
2. Quantitative Project Management (QPM)


Next - CMMI - L4 - Quantitatively Managed - OPP, QPM

For questions, write to know.cmmi@gmail.com or leave a comment here.

Read more...

CMMI - L 4 - Quantitatively Managed - OPP and QPM

Organizational Process Performance (OPP)

The purpose of this PA is to establish and maintain a quantitative understanding of the performance of the organization’s set of processes. It also provides process performance data, baselines and models to quantitatively manage the projects.

Goal - Establish Performance Baselines and Models

Quantitative Project Management (QPM)

The purpose of this PA is to quantitatively manage the project’s defined process to achieve the project’s quality goals and process performance objectives. It involves:

- Establishing goals
- Identifying suitable sub processes for control based on historic stability (Statistical Process Control – SPC)
- Monitoring to see whether goals are being met
- Finding out reasons for variation (from SPC charts) and taking suitable measures to reduce them in future

The key aspect at Level 4 is to Understand special causes of variation. Reducing variation of parameters is the objective. The parameters can be process or product measures.

Ex:
DIR, CoQ, Review effectiveness (all process measures);
Schedule deviation, Delivered defects(quality), Code quality (all product measures).

Goals:

1. Quantitatmanage a projectively
2. Statistically manage sub process performance (Ex of statistical methods are: SPC, Pareto, Cause Effect diagrams, etc.

QPM gives us direction to measure and manage project performance in terms of measurable data. Having a good QPM structure helps the organization in having better control, better management information and improved estimation and tracking.

When a project starts, it defines the metrics it will collect (defects, effort etc) and goals. It also defined sub processes that will be statistically controlled. These are defined in the PM Plan. These goals are monitored on a continuous basis through milestone reports and SPC charts.

Next - CMMI - Level 5 - Optimizing

For questions, write to know.cmmi@gmail.com or leave a comment here.

Read more...

CMMI - Level 5 - Optimizing

Level 5 – The Optimizing Level, focuses on continually improving process performance through both incremental and innovative improvements. The effects of deployed process improvements are measured and evaluated.

A critical distinction between Level 4 and 5, is the type of process variation that is addressed. At maturity Level 4, we look at Special cause of variation (Through Statistical Process Control or other statistical techniques)

At Level 5, we are concerned with addressing common causes of variation and changing the process (Ex – Defect & Problem Prevention)

There are 2 PAs at Level 5

1. Organizational Innovation and Deployment (OID)
2. Causal Analysis and Resolution (CAR)

Organizational Innovation and Deployment

The purpose of OID is to select and deploy incremental and innovative improvements that measurably improve the organization’s processes and technologies

Examples:
- Deploying a new tool
- Deploying a new technology across the organization (ex – Windows xp)
- Introducing a new process (Ex. Decision Analysis and resolution or an Account management process)

Goal:

1. Select Improvements – Necessary process and technology improvements are selected
2. Deploy improvements – Improvements to organization’s processes and technologies are continually and systematically deployed

The essence of this PA is how effectively can an organization make continuous change to its processes and technology that results in incremental and innovative improvements.


Next - CMMI - L5 - Optimizing - CAR

Read more...

CMMI - L 5 - Optimizing - CAR

Causal Analysis and Resolution – PA at L-5, is to identify causes of defects and other problems and take action to prevent them from occurring in future.

It involves the following:

1. Identifying and analyzing causes of defects and other problems
2. Use techniques like Pareto, Brainstorming, Cause-Effect to come up with root-cause rather than surface level cause
3. Taking specific actions to remove the root-causes and prevent the occurrence of these types of defects and problems in the future

The basic principle behind the PA is that reliance on detecting defects is not cost effective. We have to prevent them from happening. Some defects or problems may have been previously encountered on other projects. Causal Analysis and Resolution activities are also a mechanism for communicating lessons learnt among projects.

Causal Analysis may be performed on problems unrelated to defects.

Examples are: Cost of Quality, Productivity, cycle time, issue resolution time, number of requirement changes etc.

The key is to identify the most important improvement area in the project and then do causal analysis.

Causal Analysis and Resolution will be effective only if a proper measurement program is in place. There is no point in doing a defect prevention activity if defects data is not proper !

Goals:

1. Determine Causes (root cause) of defects
2. Address causes of Defects (and other problems)


For questions, please write to know.cmmi@gmail.com or leave a comment here.

Read more...