CRITICAL FACTOR 2: PLAN PROCESS DEFINITION WORK

The second critical factor, and one frequently overlooked, is planning the process definition work. It is easy to forget about planning process definition; after all, it s just writing a bunch of procedures, right? Not exactly.

Remember, the process focus people such as SEPG or the senior management presumably believe in the principle that putting effort into planning will save time, money, and frustration later in the life cycle. (If the process people in your organization don t believe in this principle, then they need to stop pushing about five of the CMMI PAs on everyone else!)

The process definition phase of your organization s CMMI process improvement project deserves to have its own subplan, complete with a WBS, schedule, and resource allocations . This process definition subplan will, in turn , help the various process definition teams plan their respective work.

Not surprisingly, there are many similarities between the development of a software- intensive system and a process system. A good place to look in your organization for ideas for a plan for process definition is the project plans for systems development.

Defining and Estimating Process Definition Tasks

There is a set of tasks and activities which are almost always performed in process definition, yet few organizations actually plan these tasks and activities by allocating time and resources to performing them. Inevitably, the CMMI or process improvement project overruns cost and schedule because of all those things we had to do which we didn t know about. So know about them now and build them into your plan.

The commonly performed yet infrequently planned process definition tasks include:

• Establishing the process definition teams (read Integrated versus Vertical Approaches to Process Improvement in Chapter 4 ” Process Improvement Strategies that Work)

• Defining organization and process terminology (read Critical Factor 3: Define the Process Language for Your Organization in this chapter)

Establishing format and content standards for process assets (read, Critical Factor 4: Design First, then Build in this chapter)

Developing/designing use cases

• Establishing and defining process asset verification (aka peer review) criteria

• Defining process asset configuration management, version control, or release management standards and procedures

Some of the more important and less understood items in this process definition task list are expounded upon in the rest of this chapter.

Building the Process Definition Teams

Going back to our systems development analogy, would we expect the people doing requirements analysis to also do the implementation or coding and then also do the integration test? Would we expect software engineers to also perform all the project management functions, requirements management functions, and verification and validation functions? Probably not. So why do we expect a SEPG to have the skill, knowledge, and resources to perform all the tasks in the end-to-end development and delivery of a process system?

This really comes down to answering the questions:

• What is the difference between the SEPG (or whatever you call the people with process responsibility) and the CMMI process improvement project team?

• Do they have to be the same people?

Most organizations, even if they buy into the concept that process improvement can be projectized , simply assume that SEPG is the CMMI or process improvement project team. But it doesn t have to be so. If you think about it in terms of predefined longevity, a process improvement project team needs to exist only for the duration of the project or release, say moving from one maturity level to the next . The SEPG, on the other hand, is usually an organizational function which has no predefined or preset duration for its existence. The process focus function is more of an ongoing interest in the organization, like the personnel department or the training department; they are the process department.

We can apply this model to CMMI-based process improvement. The project teams in your organization probably exist only for the duration of a project. During the life cycle of the project, the project manager acquires services and resources from the ongoing functions in the organization such as architecture and design, engineering, manufacturing, shipping, personnel, testing, etc. Similarly, the process improvement project team can be established to exist only for the duration of a defined process improvement project. This project team will also plan and then execute the project by acquiring and temporarily managing resources from ongoing functions such as SEPG, engineering, management, training, etc.

This is exactly what I did in CSC and it worked beautifully. I was the project manager for the project to move the organization from CMM Level 2 to CMM Level 3 and achieve some other defined business goals. The process improvement project team was a separate and distinct unit from SEPG and planned and used resources from SEPG, the quality assurance group, the configuration management group , and other ongoing concerns. This model can work very well in organizations that draw the distinction between a program and a project, with that distinction being that projects have a finite start and end date and programs, which are often an ongoing collection of related projects, do not. In the CSC organization in which I worked, SEPG ran the process improvement program to which the process improvement project I managed was a contributor .

(For more information, read Establishing the Process Improvement Project Team in Chapter 3 ” Managing the Process Improvement Project.)