QualityMentors Blog

This blog is a membership based discussion forum on Project Management, Software Quality, CMMI® for development, ISMS and associated subjects. It provides a common platform for our training participants and others to share views and obtain expert opinion on issues related to above subjects. Also, it is used by QualityMentors training participants to upload their personal details in a secured manner in line to the guidelines laid down in ISO/IEC 17024:2003. This blog draws its strength from its members who are welcome to share professional and personal experiences, comments, articles and reference links to make it a preferred knowledge repository for their collective use. It encourages fact based decision making as an success enabler for projects in member organizations.

Category Archives: CMMI(R) for Development, V 1.3

Mapping an NC to applicable standard’s clauses during audits

Today I concluded conducting an IRCA authorized  QMS Lead Auditors Course. During the mock audits conducted as part of the course curriculum, the participants’ ability to identify most appropriate clause of ISO 9001:2015 against an NC remained a challenge. In real life first/second/third party audits, even experienced auditors find it challenging to map a given NC to the right clause of the standard.  For example, an NC about product delivery with known defects is mapped not only to clause 8.6 of ISO 9001 but also to 8.5.2 (Identification and tractability), 8.7 (control of NC outputs), 9.1 (monitoring and measurements etc) and 7.3 (competence). Needless to say, by doing this the focus on right correction and corrective action is lost, leading to vague responses from auditees.

My advice to auditors is to think for a few moments on the NC or the situation on hand and then mentally map it to ‘most appropriate clause’.  Only if necessary, start going through the clauses of the standard for such mapping, To the extent possible, map the situation to one clause only, unless off-course when there is a genuine need to refer to two clauses.

In no case, more than two clauses should be mapped.


QualityMentors Course Offering by CAI University, USA

Thomas Swider, Project Manager of CAI University talks about a new course being launched by them. The course title is ‘Successful Project Management with CMMI(R)-Dev,V 1.3 and it is authored by Ribhu Lavania. Read on…

Clarification on Configuration Management

This is the response to AKM Desai’s posting of March 31.

Since you say that this old project is nearing its completion, I presume that it must be having some level of control on its work products, and that practice has allowed it to reach its final stages. All the intermediate deliverables, software code, executable files and so on must have evolved in some manner and the project team must be having a system to establish and maintain its work in a defined, and planned fashion. If that is true, CM is being applied to this project. Generally speaking, project management should decide which work products should be subjected to CM and the extent of control on them.

Having said that, there may be a good reason for the project to use a suitable CM Tool for maintaining the integrity of its work products by using a CM Tool. The selected tool will mitigate the increasing risk of project loosing its work products in its final phase and increase the success rate by providing only the desired versions of intermediate work products for final product build. However, if I were the management, I would have left the decision to the Project Manager.

In any case, just bringing in the CM Tool for satisfying the appraisal team is not recommended. CMMI or other quality frameworks don’t impose the use of a CM Tool. Project Management has to take a call. If the PM is satisfied and has good reasons for not using a tool, it should be acceptable to the appraisal team. Anything important enough to maintain its integrity must be subjected to CM practices.

People feel Agile is some rocket science which does not need processes. Totally false. A formal CM in agile environment is much more important to support frequent changes the agile project undergoes. So if the project in question is an agile project, a CM Tool should have been  necessary for it.

QA Team Size

Let me try to respond to Rohit’s posting of March 31 regarding available benchmarks on QA Team size in software industry.

Famous benchmarking expert Capers Jones, in his presentation ‘SOFTWARE QUALITY IN 2002: A SURVEY OF THE STATE OF THE ART’ indicated that software organizations on an average need more than 5% of total manpower in quality for ‘Active QA’, less than 3% for ‘Passive QA’ and less than 1% for ‘Token QA’. This data is based on a survey of 600 organizations (150 Fortune 500 ones) and 30 Government or military groups. For smaller organizations, the percentages will be same or slightly higher.

With added process orientation based on CMMI, availability of best practices and latest benchmarks from ISBSG, SPINs and SEIR and availability of automated tools for project management, metrics based SPI and knowledge management, certain organizations may be able to bring down these percentages in case they peruse real quality and don’t run after certifications.

3 to 5% of engineering team size in QA is a good benchmarks in 2011.

I feel,  software industry still has plenty of  improvement opportunities in metrics based SPI. If implemented correctly and linked to business benefits (not certifications), this percentage may further come down.

Members may contribute their comments on this issue.

Clarification on Configuration Management

We are a middle size organization. We  launched our CMMI-Dev, V 1.3, ML 3 journey last year and are going to have our final SCAMP Appraisal soon. While most other projects are using MS VSS as the CM tool, an old and lengthy project nearing its completion has not been using any CM Tool. This project is selected, amongst a few others, for being examined during the SCAMPI Appraisal.

My question to fellow members is this: Shall we create a MS VSS directory for this project and put all past artifacts in it or keep leading the project as it is and risk our appraisal?



Differences / salient features of CMMi v1.3 over v1.2

I have tried to respond to Rohit’s post of 23rd March regarding ‘Differences / salient features of CMMi v1.3 over v1.2’ after going through the new version of CMMI-Dev (V 1.3) and have listed down following changes in it:


Architecture related changes:

  1. ‘Typical work products’ referred in CMMI-Dev, V 1.2 will be are now called ‘example work products.
  2. ‘Amplification’ model component has been removed, making the model simpler.
  3. ‘IPPD’ addition has been removed from V 1.3. You don’t see the term ‘IPPD’ anywhere in the model.

Process Area category:

  1. REQM PA has been moved from Engineering category to Project Management category.

New areas included in PA descriptions while providing interpretation of SPs and GPs:

  1. Agile methods
  2. Quality attributes (i.e., non functional requirements or “ilities”)
  3. Allocation of product capabilities to release increments.
  4. Product lines
  5. System of systems
  6. Architecture-centric development practices
  7. Technology maturation
  8. Customer satisfaction

The new model is therefore easier to implement by a variety of  organizations in software, as well as other industries.

GGs, GPs, and GP Elaborations:

  1. Generic goals, generic practices, and GP elaborations are available at one Place in the first section of Part 2. The GP elaborations in the process areas have been removed.
  2. Simplified GG1 to make it more understandable.
  3. Renamed GP 2.6 as ‘Control Work Products’ (earlier it was ‘Manage configurations’).
  4. GP 2.9 is now ‘Objectively evaluate adherence of selected work products’. ‘Selected work products’ now provide more flexibility.
  5. Simplified the GP 3.2. Earlier statement ‘Collect work products, measures, measurement results, and improvement information’ is now replaced with ‘Collect process-related experiences’.
  6. GG4 and GG5 have been eliminated.

High Maturity Updates:

  1. The possibility of subjective interpretations of high maturity PAs has now been minimized by adding clarifications on:
  2. Process models and process modeling.
  3. How business objectives thread to high maturity.
  4. Common causes – definition/concentration/expectations at ML5.
  5. Defining high maturity expectations on individual PA performance.
  6. High maturity re-structuring (including stronger alignment of ML4 & ML5).
  7. Sub-process – selection/definition/level of instantiation is better explained now.
    1. Better explanation of high maturity requirements and expectations eliminates subjectivity in interpreting the goals and practices. Such subjectivity was proving to be problematic  for appraisers and implementers, both. Both used to refer to high maturity presentations released by the SEI, the appraiser methods or their knowledge of other models/ standards to support of their interpretations. By providing clarity in version 1.3, such subjectivity will thus fade away.

I would say, this is the most important change in the model.

  1. OID PAs has been removed and a new PA, called OPM (Organizational Process Management) has been introduced.

Overall comments:

The new model is more concise with about 100 pages less than its earlier avatar, and with GG4 and GG5 removed.

I will get the book on  V 1.3 of CMMI-Dev in coming 3-5 days and would add to this post in case more differences are found. Rest of the details in the two versions remain the same.

Members may add to these details….


Differences / salient features of CMMi v1.3 over v1.2

Would like to know if anyone has a presentation or any other document that highlights the differences / salient features that the latest iteration of the model encompasses.


The new book on CMMI(R) for Dev., version 1.3

The new book “CMMI for Development®: Guidelines for Process Integration and Product Improvement, Third Edition” is now available from www.amazon.com @ USD 62.36, including shipping and handling charges of USD 9.98. Its ISBN is 0- 321-15496-7 and it is the hard copy version of SEI’s  ‘CMU/SEI-2010-TR-033’. They have started shipping it from 19th March.

Mapping:PMBOK® to CMMI®-Dev, V 1.3

This mapping has been compiled between the Project Management Process Groups and Project Management Knowledge Areas on the x and y axis, respectively;  and  practices of CMMI®-Dev, Version 1.3 in-between them. The Project Management Process Groups and knowledge area matrix is from the PMBOK® and the CMMI® SPs & GPs have been mapped by the author. You may notice that the technical activities (like design) of a  project do not  appear in this compilation, as “Project Management Body of Knowledge” does not and can not cover technical aspects of the project .  Comments and suggestions may please be posted on this blog . Read on

%d bloggers like this: