MONITORING AND CONTROLLING THE PROCESS IMPROVEMENT PROJECT

This section is short because the lessons are brief. The skills, techniques, methods , and tools involved in managing (aka monitoring and controlling) the process improvement project are indistinguishable from those used to manage software and systems projects. There are at least seven primary concepts to employ in managing the process project:

1. Use the project plans to which stakeholders have committed as the basis for all project performance monitoring and measuring. Let the committed, documented plans set the expectations, not hallway discussions.

2. Manage the critical, high priority project risks almost continuously.

3. Demand overt concurrence and recommitment to changes to the plan or commitments. Do not accept silence or nodding heads.

4. Continuously market, promote, and build continuing support for the project. Continuously involve the end users of the processes. Put out a periodic newsletter that both informs and entertains people about the process improvement project. Offer small prizes for involvement and interaction.

5. Be decisive and take action when project performance deviates from plans. Do not assume that things will just autocorrect or that leadership will descend from a higher power to help save the project.

6. Always make sure that the process improvement project follows the organization s existing and approved processes for system development and delivery. Never be caught being a hypocrite.

7. Don t be boring. Let s face it, process can be pretty dry stuff, but it doesn t have to be. Learn or find ways to have fun with the project. Reward people, even in small, simple ways, when they exhibit courage and the behaviors that process improvement needs to become institutionalized in the organization.

The Cost, Schedule, and Quality Paradigm

Historically, the project paradigm has been summarized by the clich , Good, Fast, or Cheap: Pick any two. I know there s a recent school of thought that suggests you can have all three, but I haven t yet seen that utopian balance attained in process improvement projects.

The problem with process improvement projects, and the one area in which they differ greatly from software and systems projects, is the quality criteria. In a systems project, an organization can establish its own acceptance criteria in terms of product or system defects that are allowable . However, if one of the acceptance criteria for the completion of a CMMI process improvement project is the attainment of a maturity level, then much of the quality criteria are determined by people on the SCAMPI appraisal team who are not members of the appraised organization. In other words, an organization producing a system and an external entity can count the number of defects in a system and come up with the same number. Yet, many organizations go into appraisals thinking they have implemented processes that are fully consistent with the CMMI practices, only to find out the appraisal team sees things differently.

The point is, the organization can t really afford to play with the quality of the process system because the risk is too great (and too expensive!) to target anything less than the highest possible quality of processes and their implementation. This leaves only two variables ” cost and schedule ” both of which are almost always constrained by people who don t even understand CMMI or the nature and magnitude of the organizational change it represents.

Let s take a truly hypothetical and very nonreal-world view and say that an organization can throw all the money and people in the world at achieving a CMMI maturity level. Couldn t it theoretically move from CMMI Level 1 to CMMI Level 3 in one day? No. The problem is that designing, developing, and implementing a process system has certain sequencing, dependencies, and constraints that logically and physically cannot be bypassed. For example, you cannot measure the performance of a process that does not exist and is not being performed. Thus, even if an organization had a million people on your SEPG and a trillion dollars to spend , they still couldn t implement a meaningful measurements program until some of the processes were defined and implemented.

So now we re down to the last and only variable, the schedule. This is really unfortunate because, as you know, the schedule for CMMI programs are typically established as target dates to achieve a certain maturity level by a certain date. That target is typically not based on any estimates, planning, historical, or industry information or ” in some cases ” even sanity .

So what do you and the process-focus people do when you realize the process improvement project s performance is not going to meet the targeted date for maturity level attainment?

You do what I had to do once when I was managing a project to move an organization from CMM Level 2 to Level 3 in a targeted time frame of 11 months. You do what any conscientious , responsible project manager does: you raise the issue or risk to those who can make decisions about the project s cost, quality, or schedule and you don t settle for an indecision.

My management in this situation offered to throw more money (i.e., people) at the project. After all, isn t that always the solution? However, I managed to convince them that just more people and not the right skills would be a phenomenal waste of their money. They asked if we could plan less quality into the process system. I told them yes and politely pointed out that they then might spend $40,000 on a CBA IPI and not achieve their desired maturity level. What do you think they asked about next , the schedule?

No. They said, Well, what if we just get another person to replace you who can do it. I replied, go for it, knowing full well that in business you can never bluff, because, if you re called on it and you back down, you ve lost all your bargaining power from then on. I had to be ready and willing to back up my words with action; I had to be willing to walk. The schedule changed by one month, which is all the more time the project needed.

For more information to understand the dynamics of cost, quality, and schedule as these parameters relate to process improvement, read Process Improvement: Good, Fast, or Cheap in Chapter 4 ” Process Improvement Strategies that Work.