In the late 1980s, the Software Engineering Institute of Carnegie Mellon University (www.sei.cmu.edu) introduced the first Capability Maturity Model. The version in wide current use was published in 1993 as the Capability Maturity Model for Software (SW-CMM), version 1.1.
SW-CMM identified five levels of capability:
1. Initial — success was possible, but everything depends on heroic individuals.
2. Repeatable — the processes are in place to allow project success to be repeated.
3. Defined — all development processes are defined and project success is the norm.
4. Managed — detailed measures are in place and management uses those numbers.
5. Optimizing — incremental and innovative ideas demonstrate qualitative success.
Many of the theoretical weakness of SW-CMM, version 1.1, are addressed in the new Capability Maturity Model Integration (version 1.1, March 2002). The documentation is a 700-page book, freely available on the Software Engineering Institute’s Web site.
CMM continues to win mind share. Vendors have discovered the power of reaching CMM Level 5, especially foreign outsourcing vendors. Level 5 vendors will have a defined, managed, quantified, and optimizing development process. Clients can have a high degree of confidence that their systems will be delivered on time, within budget, and up to specification. In short, a shop that makes it to SW-CMM level 5 really knows what it’s doing, and has the numbers to prove it.
CMM is not perfect, and there are no guarantees. The transition from one level to the next will typically take one to three years, and skipping levels is not practical. Getting to Level 5 is going to take time. With that in mind, will you be there in time to meet the competition?
And when an organization does turn to its internal development shop, can it have a similar high degree of confidence in the outcome? For too many North American IT shops, there is little confidence in the outcome, and a history of late, over budget, and under spec development efforts.
If we are to compete against such CMM 5 vendors, we need to move development from a black art to a managed and disciplined process. The transition can be uncomfortable for traditional developers. At a minimum, it requires that we define our development process, remove as many errors as possible, as early as possible, and measure and track our performance.
Failure to respond will swell the tide with organizations that turn to outsourcers who can demonstrate they know how to “engineer” the development of systems — thereby reducing the need for Canadian in-house developers and whittling down the number of job opportunities out there.
IT workers must find effective ways to add discipline to the development process. CMM establishes a Standard of Practice for how to best “engineer” the development of a system. It has received considerable international support. Agile, discussed in a previous column, is another way to add discipline to the development process. It offers a different Standard of Practice, focusing on the incremental growth of systems and internal controls.
As IT professionals, we have a responsibility to add effective discipline to systems development. We’ve got to get better at delivering on our promises. We are either an active part of the solution, or we will be seen as part of the problem. In these times, being seen as a part of the problem isn’t prudent.
Fabian is a senior management and systems consultant in Toronto. He can be reached at Robert@fabian.ca.