Basics of CMM and Documents to support.

CMM compliance is a step forward to ensure process maturity and compliance for projects. It is a model to measure the process capability. It was incorporated initially by SEI, Carnigie Mellon.

KEY TERMS YOU NEED TO KNOW

  • Level – indicates the capability of your organization,
  • KPA – Key Process Areas. Delves into process areas in detail.
  • Goals – Identify your goals and strive to attain them.
  • Common Features – discusses the features that should be satisfied by the organization.

Understanding your CMM

Common Features

  • Commitment to perform (Verifies your commitment to the cause of implementing CMM and its procedures)
  • Ability to perform (Once committed, evaluates “Do you have the ability to perform and do the needful?”
  • Activities performed (If you have the ability, what should be the activities that could be performed to attain the process maturity)
  • Measure and analysis (Once you perform the activities, it is important to measure. You cannot grow if you cannot measure. So measure the growth and the compliance and ensure the right way to maturity)
  • Verify implementation (Once measured, you need to verify if your implementation of the policies and procedures were right)

CMM Levels

  • Level 1 : Initial level
  • Level 2 : Defined
  • Level 3 : Repeatable
  • Level 4 : Managed
  • Level 5 : Optimizing

Project/ Organization level documents needed for CMM

1) Effort Estimation Guidelines : Will enable the concerned team to arrive at a proper estimate and related documents.

2) Contract/ Proposal Guidelines : Will enable us to prepare the right contract/ proposal with the required details to present to the customer

3) Project Initiation and Closure Guidelines : Will enable us to have proper Project Initiation procedures and closure procedures (including project closure meetings) to enable the other projects to learn about the best practices and lessons learnt during the course of the project.

4) Software Project Management Plan (SPMP) : Will enable the Project Manager to plan to the minutest possible details on the plan and the actual happenings within the project. Milestones can be tracked and deviations noted and corrected during the project schedule.

5) URS Guidelines : Will enable us to put the requirements together in a consolidated form as required by the Software Engineering team (SEG)

6) Managing Non-conforming product procedures : Will enable the resources  to identify the non-conforming work product and take corrective action. These corrective actions should be noted and effort made to atleast prevent these causes in future operations. This document will contain steps to tackle such deviating products.

7) Corrective and Preventive Action Procedures : Will enable the resources  to take appropriate corrective action for deviating products. (This document can be linked to Managing Non-conforming products procedures. This document gained importance with the ISO 9001-2008 which clearly states that review of the corrective action needs to be done)

8) Software Development Review procedures : Will enable the resources to undertake review process and evaluate the said work product based on the review.

9) Acceptance Test Procedures : Will enable the resources to have clear cut instructions and procedures to undertake Acceptance Test.

10) Billing/ Collection Procedure : Will enable the delivery and billing staff to have proper documentation in place for billing and collecting the dues from the customer.

11) Document Control Procedures : This procedure will highlight the various steps required to have document change control procedures to identify the changes done to any document and notification to the concerned teams on the changes. This document goes hand-in-hand with the SEPG Guidelines which is the main group involved in the creation/ update  of new processes and procedures. We would also have close interaction with the Software Configuration Management Group for the document updates.

12) Management Review Meeting Procedures : This document will highlight the process for scheduling, managing Management reviews and the related documents/ reports that needs to be created therewith.

13) Internal Audit Procedures : This document will guide the internal audit team to carry out an efficient review and appraise the Senior Management on the status of projects and the various groups that are associated with the software development process.

14) Software Metrics procedures : This procedure document will enable the project team and the SQA group to come together and create appropriate metrics associated with the project team. This will enable the Projects to know the strengths and weaknesses and take appropriate action in the next project.

15) Training Procedures : This document will highlight the various steps needed in place to handle training for new joinees, existing employees on subject matter relevant to the organization. This will also cover the feedback procedure and the evaluation procedure for the training.

16) Software Engineering Process Group Guidelines : This document will highlight the necessary process required for updates to the processes based on research and feasibility of having it included in the organization. SEPG group is responsible for these updates. The SEPG group consists of senior members of the project, and the management who will ensure that the right process and technology makes its way to the organization. They are also responsible for reviewing the process and approving the same so that the processes are in-line with the Lines of Business of the organization.

17) Software Quality Assurance Group Guidelines :  This document will highlight the roles and responsibilities of the SQA group who are referred to as the eyes and ears of the management on the projects. They evaluate and keep an eye on the project to monitor any deviations, which can then be resolved and the project be brought on track. If the issues are found to be serious and out of bounds, the SQA group can escalate it to the top management. The document identifies the roles of the SQA group, their involvement in the projects and their ability to ensure the process compliance within projects.

18) Project Management Guidelines : This document ensures that the roles and responsibilities of the Project Manager are outlined and made clear to the concerned PM resources. It also provides detailed analysis of the tasks to be performed and monitoed by the concerned Project Manager.

19) Technology Change Management Guidelines : This document is used to identify the process that is synonymous with technological ventures and changes that might be affected in the organization. How the right technology should be identified that will aid the organization in the future business prospects will be outlined in this document. The Technology change management group will evaluate the right technology for assimilation to the organizational process.

20) Software Change Management Guidelines : This document will highlight the process to be followed for identifying the right work product as configurable item, baseline these and delivering correctly to the customer. Every workproduct which can be delivered should be maintained and baselined to reduce error prone delivery to the customer. Organizations should identify the appropriate methods or tool to maintain their configurable items. This process guides the teams to carry out right Change Management steps to have a good, centralized and well maintained repository for these items.

Advertisements

2 thoughts on “Basics of CMM and Documents to support.”

  1. There are some CMMI consultants out there who do not understand the how the software development operates. They simply do not understand the very purpose of CMMI and try to coach organizations. Unfortunately I had come across one such consultant and in order to teach him (yes teach him) how the software development is actually carried out and to practically relate each stage of software development to the CMMI process areas and work products I hit upon this blog of yours and it did help me to put up to him more clearly. Thanks Mr. Gopi for the basic but wonderful information.

    Just in case who I am, I have spent over 18 years in IT from a developer to a project manager to a program manager.
    (1992 – 2010)

    Like

    1. Hi Dear Venkat,

      Thanks for your compliments. I am here on this blog just to educate people on so many things out there in the IT world. If I could do my bit, then it is nice. Thanks a lot.

      I too have been in the IT from the last 21 years, as you from a developer to a QA Manager/ Project Manager (1989 to 2010). Nice to meet you.

      Regards,
      Abhilash

      Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s