Model Structure for the Staged Representation

To explain the structure of the CMMI , we first use the staged representation of the model as our example and then follow up with a brief discussion of the continuous representation. The reader is directed to read Chapter 4 concerning CMMI representations along with this chapter.

Terms and Definitions

Before we begin, there are two very important concepts that need to be discussed:

1. Implementation

2. Institutionalization

Implementation is simply performing a task within the process area. (A process area is an area defined by the CMMI as an area that organizations should focus on ” such as Project Planning or Configuration Management. It is a set of related tasks that address an area of concern.) The task is performed according to a process, but the action performed or the process followed may not be totally ingrained as part of the organization's culture.

Institutionalization is the result of implementing the process again and again. The process has become totally integrated into the organization. The process will continue after those who created it have left the organization. An infrastructure to support this way of doing business exists and provides support for the process and the individuals following it.

Other definitions that might prove helpful include:

• Development: the Construction phase of a life cycle, including Maintenance.

• Project: activities and resources necessary to deliver a product to the customer. A project is not just a software project. A project can also consist of many projects. The term "program" is not used. A project is also expected to have a start and end date, with a formal project manager assigned.

• Product: a service or system or tangible output delivered to the customer.

Another term that is frequently used, extremely important, yet very difficult to define is organization. What is an organization? Well, normally an organization is a series of projects currently underway within a department. The term "organization" also implies people, the structure of the departments, and the physical plant and equipment. So, if you are a developer, you might be working on coding five programs to maintain an automobile insurance system, developing a small Web site to track customer complaints about medical reimbursement, and beginning to design a document management system to document work hours performed for payroll purposes. That sounds like three projects to me. However, depending on how your place of business is set up, you could be working in three different organizations ” the auto insurance department, the medical insurance department, and the payroll department. Or, you could be working in just one organization ” the Technical Information Systems department. An organization can also consist of one individual! So, the definition of an organization depends .

Our advice to the scenario above is to develop improvement programs (and resultant assessments) based on the three different organizations mentioned in the first scenario (automobile insurance, medical insurance, and payroll as three separate organizations). Why? Because each organization has different rules it must follow. For example, automobile insurance may have state department of transportation regulations to follow, medical insurance may have federal medical regulations to follow, and payroll may have federal IRS and state tax regulations to follow. Therefore, the processes will be different. For example, do you think a customer service department of a utility company answering billing complaints from customers should be run the same way as a nuclear power plant? The nuclear power plant has environmental regulations, nuclear regulations, and other federal, state, and local policies it must implement in its processes. The customer service organization probably has fewer. The margin of error allowed in the safety factor is also significantly different.

With the CMMI, the definition of organization becomes even less clear. An organization can be one department headed by one director, or it can be expanded to include the entire company or enterprise. Our advice? De-scope. Do not bite off more than you can chew when beginning process improvement efforts. They tend to mushroom anyway. Start small ” such as with the project in the above example doing Web-based medical insurance design and coding, and increase your efforts as necessary.