How CMMI Applies for IT Project Management

I would like to start this article with giving a very brief explanation and introduction to CMMI

Detailed discussion will be covered in individual articles for each sub item for a particular CMMI level .In this article i will discuss the CMMI level 2 , "Requirements Management"

What is CMMI ?

In General the “Capability Maturity Model Integration”, or CMMI, is a process model that provides a clear definition of what an organization should do to promote behaviors that lead to improved performance and to achieve products / services quality objectives

CMMI Maturity Levels and Process Areas for IT Projects 

CMMI Level 2 :

• Requirements Management 
• Project Planning 
• Project Monitoring and Control 
• Measurement and Analysis 
• Configuration Management 
• Process and Product Quality Assurance 

CMMI Level 3 : 

• Integrated Project Management 
• Risk Management 
• Decision Analysis and Resolution 
• Requirements Development 
• Technical Solution 
• Product Integration 
• Verification 
• Validation 

CMMI Level 4 : 

• Quantitative Project Management 

CMMI Level 5 :

• Causal Analysis and Resolution 
• Organizational Innovation and Deployment 

CMMI Level 2 : Requirements Management in Detail

Requirements Management 

Develop an understanding with the requirements providers :

• Identifying Stakeholders responsible for providing requirements 
• Requirements Management Plan should contain the acceptance criteria and the objectives of the requirements 
• In addition ,Requirement Management Plan should contain 
• Who will gather, document, review and sign off the requirements 
• How or the approach we should take to achieve it
• What techniques will be used to gather requirements, gain understanding or clarifications and review of the artifacts

Obtaining commitment to the requirements  from Stakeholders :

• Making sure impact analysis of the requirements has been done, getting commitment to the requirements from the team (this can be obtained through leads most of the time)
• All the impact details must be documented and if any actions to be taken on those , action items and time lines should be determined
• Changes to the estimates, plans,schedules, milestones & delivery dates must be evaluated , relevant artifacts must be updated and all the stakeholders must be aware of it 

Manage Requirements Changes

• Document all requirements and requirement changes that are given to or generated by the project
• Maintain the requirements change history with the rationale for the changes; this can be achieved by using Change Request Log 
• Impact analysis of the CRs raised should be done and it should be documented 
• Requirements artifacts, Q&A Forms and Logs, Business Requirements Log, CR Log and/or Change Request forms are filled with details and made available to the team 

Bidirectional Traceability of Requirements :

• Requirements Traceability Matrix (RTM) will be reflecting the current status of the entire system in scope
• Requirements mapping is done in the Requirements Traceability Matrix
• Requirements are mapped to the relevant architecture and design components, database elements, source code components and test cases done

Note :  I have provided a brief explanation on RTM in a separate article  

Identify Inconsistencies Between Project Work and Requirements 

• Project plans and work products are reviewed in the context of the requirements and the CRs to identify the inconsistencies, if any
• Reasons for the inconsistencies, if any, are identified and documented in Minutes of meeting, Design documents, Requirement Specifications, Project Plan and other relevant artifacts
• Changes to be made to estimates, plans, schedules and work products must be identified
• Corrective actions to implement the above changes are documented and managed