CMMI models must often refer to the organizational entities that are at the foundation of process improvement efforts. These entities are focal points in the organization for creating value, managing work, tailoring processes, and conducting appraisals. In CMMI-SVC, these entities are called “work groups,” while in CMMI-DEV and CMMI-ACQ these entities are called “projects.” The glossary defines both terms and their relationship to each other, but it does not explain why two different terms are needed.

Those who have prior experience using CMMI-DEV or CMMI-ACQ models, or who routinely think of their work as part of a project-style work arrangement, may wonder why the term “project” is not sufficient by itself. The CMMI glossary defines a “project” as a managed set of interrelated activities and resources, including people, that delivers one or more products or services to a customer or end user. The definition notes explain that a project has an intended beginning (i.e., project startup) and end, and that it typically operates according to a plan. These notes are characteristics of a project according to many definitions, so why is there an issue? Why might there be a difficulty with applying terms like “project planning” or “project management” in some service provider organizations?

One simple reason is that projects have an intended end as well as an intended beginning; such efforts are focused on accomplishing an objective by a certain time. While some services follow this same pattern, many are delivered over time without an expected end (e.g., typical municipal services, services from businesses that intend to offer them indefinitely). Service providers in these contexts are naturally reluctant to describe their service delivery work as a project under this definition.

In prior (V1.2) CMMI models, the definition of “project” was deliberately changed to eliminate this limitation (i.e., that projects have a definite or intended end), in part to allow the term to be applied easily to the full range of service types. However, the change raised more questions and objections than it resolved when interpreted by many users (even in some service contexts), and so the limited meaning has been restored in V1.3: projects now must have an intended end.

For organizations that do not structure their people and other resources into projects with intended ends, or that only do so for a portion of their work, the original problem remains. All of the common CMMI practices are useful whether or not your work is planned to have an intended end, but what can we call a fundamental organizational entity that implements CMMI practices if it is not a project? How can we refer to and apply the practices of process areas such as project planning when we are not discussing a project?

The CMMI V1.3 solution is to introduce some new terms that take advantage of two distinct senses of meaning for the English word “project”: as a collection of resources (including people), and as a collection of activities performed by people. CMMI-DEV and CMMI-ACQ continue to use the term “project” for both senses, because this use reflects the typical nature of development and acquisition efforts. CMMI-SVC replaces “project” with “work group” (when it refers strictly to a collection of resources including people) or with “work” (when it refers to a collection of activities, or a collection of activities and associated resources). The glossary defines a “work group” as a managed set of people and other resources that delivers one or more products or services to a customer or end user. The definition is silent on the expected lifetime of a work group. Therefore, a project (in the first sense) can be considered a type of work group, one whose work is planned to have an intended end.

Service provider organizations can therefore structure themselves into work groups (without time limits) or projects (with time limits) depending on the nature of the work, and many organizations will do both in different contexts. For example, development of a service system can be performed by a project, whereas service delivery can be performed by a work group.

The glossary also notes that a work group can contain work groups, can span organizational boundaries, and can appear at any level of an organization. It is possible for a work group to be defined by nothing more than members of an organization with a particular common purpose (e.g., all those who perform a particular task), whether or not that group is represented somewhere on an organization chart.

In the end, of course, organizations will use whatever terminology is comfortable, familiar, and useful to them, and the CMMI-SVC model does not require this approach to change. However, all CMMI models need a convenient way to refer clearly to the fundamental groupings of resources that organize work to achieve significant objectives. In contrast to other CMMI models, the CMMI-SVC model uses the term “work group” rather than “project” for this limited purpose, and uses the term “work” for other senses of the word “project” including combined senses. For example, a “project plan” is called a “work plan” in CMMI-SVC. (In a few cases, the word “project” is retained in the CMMI-SVC model when it explicitly refers to a true project.)

Consistent with this usage, the titles of some important core process areas are different in CMMI-SVC compared to CMMI-DEV and CMMI-ACQ: Work Planning, Work Monitoring and Control, Integrated Work Management, and Quantitative Work Management (cf. Project Planning, Project Monitoring and Control, Integrated Project Management, and Quantitative Project Management). Despite these differences in terminology in different constellations, Integrated Work Management and Integrated Project Management cover essentially the same material and are considered to be the same core process area in all three CMMI constellations; the same is true for other equivalent process area pairings.