CMMI and Project Management

CMM or CMMI may be the most prominent quality standards for software. CMM/CMMI goes beyond the scope of standards such as ISO to define the criteria for good software processes, which is what makes the standard so attractive to organizations with IT shops. CMM/CMMI is intended to govern processes of the entire IT organization, and the complete lifecycle of software applications so must include the processes used to govern the development of the software. CMM/CMMI’s influence on processes that govern software development means that it also influences the way that software development projects are managed. PMI’s PMBOK (Project Management Body of Knowledge) is recognized around the world as the bible of project management best practices. These apply to the management of projects in any industry including the IT industry so the best practices of the PMBOK will be influenced by the CMM/CMMI standard in any organization that wishes to apply the two standards.

So far as I know, no-one has attempted to create a CMM or CMMI standard that is tailored to the PMBOK and no-one has customized the PMBOK to accommodate CMM or CMMI. This article is my attempt of offer guidance to the project manager who is charged with managing a software project in an organization that is certified at a CMM/CMMI level of 2 or above. Fortunately, these two standards are by no means mutually exclusive; however they do influence one another so some care should be taken with the processes used for the project. The best way to address the relationships is by Key Process Area (KPA) which happens to align fairly closely with Knowledge Areas described in the PMBOK. This is not a manual on achieving CMM or CMMI certification, not is it a manual on implementing PMBOK best practices, I’m simply pointing out ways of aligning the two standards. Since the intended audience for this article is mainly project managers, I’ll begin it by providing some background on CMM/CMMI

Background

CMM stands for Capability Maturity Model. CMMI standards for Capability Maturity Model Integration and evolved from CMM. CMM was developed for the US federal government by Software Engineering Institute (SEI), which is associated with Carnegie Melon University (CMU) for the purpose of measuring the quality of a defense contractor’s processes. CMM evolved to become a roadmap for continuous software improvement through 5 stages: Initial, Repeatable, Defined, Managed, and Optimizing, then further refined to address problems with integrating CMM processes across the entire organization. The way the SEI set out to do this was to identify different process areas, to define the processes critical to each process areas, and to define criteria the processes ought to meet. Processes in each of the Key Process Areas (KPA) evolve through each of the levels of maturity until they reach level 5. The model is not meant to advance every practitioner’s processes to level 5. Level 5 is intended for organizations such as NASA who have a need for that level of process maturity.

Level 1 is the beginning stage for the model and in fact any organization that creates software will be defined at level 1. Level 2 requires that project management processes are established to track cost, schedule, and functionality. This is the stage that any project that implements the best practices from the PMBOK will be at and requires no rationalization between the PMBOK and CMM. Level 3 requires that software processes for both management and engineering be documented, standardized, and implemented across the organization on all projects. This is the level that requires a degree of coordination between project management and CMM.

Level 2 CMM requires processes in the following areas:

• Requirements management
• Software project planning
• Software project tracking and oversight
• Software subcontract management
• Software quality assurance
• Software configuration management

All these areas, with the exception of software configuration management, are described in detail by the PMBOK. Software configuration management is not covered and is normally considered one of the process assets that the project will inherit from the organization performing the project. Software subcontract management does not apply to every project, so if your project does not require the procurement of any products or services externally this area can be ignored.

CMM focuses on understanding the needs of the customer of the software project, translating those needs into requirements, and documenting those requirements. The capability striven for in this area is a common understanding of what those requirements are and proper documentation of the requirements so that they can be used to performing and tracking the project’s activities. Project planning focuses on the development of realistic estimates for the work which must be performed and obtaining the commitments to do the work. Planning also includes identifying the goals, effort estimation, resource requirements estimation, scheduling the work, and identification of the risks to the plan. Project tracking and oversight requires the project manager to establish sufficient visibility into project performance so that deviations from the plan can be detected and corrected. Corrections can include re-planning the work or taking actions that will allow the team to meet the existing plan. Subcontract management governs how qualified subcontractors are selected and managed. The purpose of quality assurance is to provide visibility into the processes used and products built by reviewing products and processes to ensure compliance with the established standards. Software configuration management establishes and maintains the integrity of the products and components through the build process and throughout the lifecycle of the software. This integrity is established by controlling changes to the product configuration using a baseline library. Changes to baselines are controlled by change control processes.

Level 3 focuses on project and organizational issues that formalize effective software engineering and management processes across all projects. The goal is the improvement of the organization’s processes. The project manager cannot be responsible for organizational standards, but can ensure that the project they are managing supports processes at level 3. The areas that comprise level 3 are:

Organization process focus (the focus is applied to the level in general)

• Organization process definition
• Training program
• Integrated software management
• Software product engineering
• Inter-group coordination
• Peer reviews

Process definition develops and maintains the set of process assets the deliver performance improvements. It also defines the data required by quantitative process management. One example of this data would be test results. The process doesn’t address specific tests but rather how the test results will be used to improve software development. Training is focused on developing the skills and knowledge to execute the processes CMM has implemented and the tasks called for by the project plan. The processes and focus in this area are pretty much unchanged from the PMBOK. Integration fits the project’s processes into the organizations standards, policies, and assets while meeting the technical needs of the project. PMOs or PMCs are probably the most common example of this. Engineering processes are simply the processes and tools used to produce the software. One example of software product engineering is RAD (Rapid Application Development). Code compilers and web application development platforms are other examples. Inter-group coordination integrates the processes and tools used by the groups across the project. An example of this integration would be the participation of the Business Analyst group in reviewing designs produced by the software development group. Peer reviews refer to design reviews, code reviews, or code walkthroughs.