by Mark Phillips, Lead Spokesperson, Vertabase
Capability Maturity Model Integration (CMMI) makes it easier to get better work product from your development process. It provides guideposts based on the relative sophistication of your process and organization. It gives you a map of how to improve your process, what to measure and how to achieve a better work-product. This is the first of a two part article about getting better work product from your development process. The first part contains background on CMMI and an explanation of the five maturity levels. The second part, which will be published in two weeks, focuses on how the maturity levels can be applied to your development process to improve the software you deliver.
CMMI, the gold standard for process improvement in the world of software development, was originally developed by Carnegie Mellon University with significant support from the Department of Defense. Its custodian is the Software Engineering Institute housed at Carnegie Mellon in Pittsburgh. (Incidentally, their website is built in ColdFusion).
CMMI sprang out of the military's need for services with a near-zero defect rate in the final deliverable, because of the catastrophic consequences of failure like a faulty navigation system on a fighter plane. Buyers around the world now use it to gauge a vendor's ability to deliver consistent quality. It also can provide valuable guidance for deriving practical steps to improve your work product.
CMMI assumes that the way you do things directly affects the quality of what you produce. By helping you understand the mechanics of that relationship, CMMI allows you to improve your work product by improving your procedures. It is a framework for processes and people. It also paves the way for organizations to grow and expand by uncovering how they do things and embedding that as a process into the organization. The secret sauce, as it were, becomes vested in a recipe and not in a particular chef.
Like any model, it does not purport to provide an exhaustive picture of reality, just an approximation of it. And, like any model, it is not a set of standards. It does not try to define the reality of process improvement, only to represent it.
Many ways lead to the points in the model, like the many ways of getting from Detroit to Chicago. You could take a train, drive, take a bus or ride a bike, for example. That means that you can use various methodologies and approaches to get from one point to another. You could use Agile methods or waterfall methods. You could use spreadsheets or project management software. You could have tons of face-to-face meetings or collaborate via the web. CMMI tells you where you should go and what the terrain looks like. How you navigate it is up to you.
There are five levels of maturity in the CMMI framework. Note: an alternative representation of the framework released in the 2006 edition describes the terrain, in terms of capabilities and capability levels. In this article, I will to stay focused on the older, and better known, terminology of maturity levels:
The maturity levels build on each other, laying the foundation for the next level. Information, processes and metrics from each previous level roll up into the next levels.
Here is a quick visual overview from an internal NASA presentation on CMMI (that was made public and retrieved from Wikipedia images). This image describes the maturity levels in the classic CMM representation and not the capabilities representation.
Image Source: Wikipedia
Deeper definitions follow for each level. I've included a quick layperson explanation of each level beneath the its formal name.
Tasks and Task Management
A level one organization lacks formal processes. Its goal is to keep operations moving forward, keep the wheels moving, keep the people doing what they need to to produce. It is juggling and traffic management. It coordinates communication and feedback. It is about iterations, cycles and getting approval to move to the next step. It creates a platform where projects can keep moving forward so things get done, the lights stay on and the organization functions.
As noted by the Software Engineering Institute of Carnegie Mellon in the CMMI for Development, Version 1.2:
"Success in these organizations depends on the competence and heroics of the people in the organization and not on the use of proven processes. In spite of this chaos, maturity level 1 organizations often produce products and services that work; however, they frequently exceed their budgets and do not meet their schedules. Maturity level 1 organizations are characterized by a tendency to over commit, abandonment of processes in a time of crisis, and an inability to repeat their successes."
Project management in a level one organization is almost purely tactical. That is, it is a series of short term measures geared at keeping things moving forward. As brought out by http://www.thedwick.com/blog/2009/02/tactical-vs-strategic-an-alternative-definition/, these measures can change on a case by case basis depending on how things change in the project.
Projects and Basic Project Management
The level two organization has standardized the way things get done. This standardization most often involves grouping efforts into projects. The projects have specific steps that they go through. Stakeholders in the projects have the necessary input. People on the projects have the budget, time and resources necessary to execute the projects. Management has sufficient information on the projects. Projects are monitored and controlled. The performance of a project gets measured at specific milestones or major tasks. Deliverables are assessed as to whether they meet the desired standards of the organization. If they don't, processes exist to rework them without causing everyone to go into a panic.
As noted in the CMMI for Development, Version 1.2
"The process discipline reflected by maturity level 2 helps to ensure that existing practices are retained during times of stress."
"Project management in a level two organization becomes more disciplined, less about putting out everyday fires and more about organizing and creating multiple projects with their appropriate plans. Project management begins to be applied to many activities within the organization."
Consistent Project Management, Reports Across Projects and Basic Portfolio Groupings
A level three organization has a generic set of standards and terminology established. This set becomes the language of projects, processes and measurement, used across the organization. Projects and processes are built in this language. Milestones, project reports, the quality of deliverables all are discussed in terms of this terminology and these standards.
The methods of managing projects becomes standardized. Instead of each project or process having its own description for how things get done, the same words describe and measure all projects and processes. These words are cut from the cloth of the organization's generic standards. What's more, the organization can now start to improve those processes. The discussion of those processes can move out of the sphere of the direct practitioner and involve people across the organization, exposing the process to external creative thinking and problem-solving.
Projects can be grouped into portfolios or
"projects of projects." Analysis of these portfolios can begin, in order to assess how well they meet the organization's overall goals. Project management becomes increasingly strategic and creative. Discussion of standards and processes set in level two by teams outside of those directly involved in their execution becomes possible. For many, a project management office, or scrum of scrums, starts to become useful at this level. Project management is increasingly strategic. That is, it consists of standards that are meant to guide how projects are done. The project and people conform to the plan rather than the plan changing radically every time something changes on the project.
Quality Metrics, Portfolio Management and Project Management Officers
A level four organization measures deliverables quantitatively, where a level three organization mostly uses qualitative measures. Deliverables can be compared across other projects and processes, and processes and projects can be objectively compared to each other based on quantitative metrics, then improved upon. This opens up the ability to compare apples to apples and to make decisions as to the relative value and importance of one set of projects over the other.
As noted in the CMMI for Development, Version 1.2:
"Quantitative objectives are based on the needs of the customer, end users, organization, and process implementers."
"Quality and process performance measures are incorporated into the organization?s measurement repository to support fact-based decision making [McGarry 2000]."
With objective measures in hand, a level four organization can assure greater predictability in the performance and outcome of any of its processes. That is how large companies that do many, many things, like General Electric or 3M, can get such good results at whatever they do, no matter how different the sets of operations are from each other. These companies can also decide whether they excel at something and if not, what steps they will need to take to become good at it.
Process improvement has its own office at this level, of which portfolio management and project management have become subsets.
Cross Portfolio Reporting, Deep Portfolio Management and Process Officers
Process improvement rules in a level five organization. A level five organization continually improves its performance and deliverables by tweaking its processes and the underlying drivers of the success of its deliverables
As noted in the CMMI for Development, Version 1.2:
"Maturity level 5 focuses on continually improving process performance through incremental and innovative process and technological improvements. Quantitative process improvement objectives for the organization are established, continually revised to reflect changing business objectives, and used as criteria in managing process improvement."
A level five organization has a deep organizational culture. In other words, the way things are done is embedded in the corporate culture. Personnel have likely worked there for a long time and moved up through different positions. Process leaders can evaluate common causes of quality and common causes of problems across the organization. They can determine modifications that should result in improvements in the deliverables and the overall ability of the organization to attain its goals.
Take our example of General Electric. At their level of maturity, subject matter expertise in a particular area gets funneled within a well-understood and measurable process. Just because someone knows a lot about building airplane engines doesn't mean they will be in charge of the airplane engine division. A professional process manager will be in charge of the airplane engine division with the specialist working for him.
We've come to the end of the first part of this article. By now you should have an understanding of what the CMMI is, the purpose of the framework, and the five capability maturity levels describing the evolution of an organization's project management process. Stay tuned for the second part, which will focus on how to apply the maturity model to your software development process to improve your work product.
Mark Phillips is the product manager and lead spokesperson at Vertabase project management software. Vertabase makes the world's leading ColdFusion based project management software. Mark has been the project manager and creative lead on numerous web-based and rich internet applications. He has presented to ColdFusion and Adobe User Groups in the U.S. and Canada on software design, usability, project and time management. He most recently spoke at CFUnited 2009 on project management. He hosted a Birds of the Feather Session at Adobe MAX 2008 on CFML Language Development.