CMMI and Project Management

There are intersections between Capability Maturity Model Integration (CMMI) and project management beyond the specific or obvious project management areas listed below in the staged representation:

1. Project Planning is Level 2
2. Project Monitoring and Control Level 2
3. Risk Management Level 3
4. Quantitative Project Management Level 5

There are other non-obvious intersections between CMMI and project management.  Consider requirements management and requirements development for example. We submit that CMMI makes project management easier.   Let us first look at requirements management and the connection to project management.

Requirements Management

This is a set of processes (in staged representation level 2) that we will use to evoke and understand the customer needs.  These are in level 2 because these are fundamental to success.  The specific goal is to ensure the requirements are managed and inconsistencies between project plans and work products are identified [CMMI].  Requirements are the detailed incarnation of the project scope. Poor requirements understanding will mean poor translation from the project scope from the detailed expectation from the customer.  There is more to this than evoking the requirements as there are 5 associated specific practices with level 2[1]:

1. Obtain an Understanding of Requirements
2. Obtain Commitment to the Requirements
3. Manage Changes to the Requirements
4. Maintain Bidirectional Traceability of the Requirements
5. Identify Inconsistencies between Project Work and Requirements

The need for obtaining and understanding of the customer requirements is probably fairly well understood by project managers.  This is essentially the evoking of the scope of the project and decomposing that scope to the actions and objectives that would be required to achieve that objective.  The need for commitment to the requirements is also fairly well understood, this provides the company backing to bring the customer expectations to fruition.  Anybody that has been in project management for long understands that unmanaged changes to the requirements can spell disaster for a project.  Along with the changes is the ability to trace the detailed requirements back to the customer demands and vice-versa.  Experience suggests these two (items 4 and 5) are a significant source of failures in project management.  Change is not bad and is to be expected in conventional projects.  Unmanaged change is not good no matter the project methodology.  The ability to manage changes, and to trace the to level customer requirements to the details of the scope as a result of the decomposition of the customer demand, enables the last item, identify inconsistencies between project work and requirements.  If we can match each specific or detailed requirement to a specific customer expectation that is part of the scope, we then know what to de-content when we realize we have to reduce the scope to meet the customer schedule or cost targets.  This traceability will also play a role in the project closure work as we verify the scope has been met as part of our contractual obligations.  To verify the scope has been met, you must know how the detailed parts connect to the customer demand and then find a way to prove that delivery has happened.

All of these are fundamental to project success.  Failure in any of these 5 requirements management items will reduce our probability of project success.  The failure will result in project cost and schedule overrun, project contract closure difficulty, and certainly customer dissatisfaction.  Therefore, an organization that has reached a maturity level regarding these attributes and able to consistently manage the quality of this outcome will have a significant positive impact on the project results.

We will work on requirements development in the next blog.