In the Beginning
In early 2002 my organization, a large New York City based company, instituted a Process Improvement initiative.

Management wanted to gain control over project requirements, configuration, and deliverables, define best practices for software development and give themselves a common measure to gauge development efficiency.

To meet these objectives, management decided upon using the Software Capability Maturity Model (SW-CMM) developed by the Software Engineering Institute. In addition, the Process Development Team, of which I am a part, was charged with developing a generic Software Development Lifecycle (SDLC) as a road map through our own best practices, containing processes, procedures and templates that could be used throughout an organization of approximately 1,500 software developers.

We immediately had problems
Since the Capability Maturity Model was new to most of us, the process consultant that we relied upon led us to believe that CMM required that everything we did needed a documented procedure. Consequently, we had a procedure to develop procedures, a procedure to develop templates and a ten page procedure documenting the steps to getting a sign-off on a document. Project teams came to think that if everything they did required a documented procedure, then they would not do anything unless they had written instructions. Common sense and good judgment died at that point.

The next thing that management focused in on was the concept of process audits defined in the CMM Software Quality Assurance Key Practices: "The SQA group reviews the software engineering activities and work products to verify compliance."

Even before the SDLC was fully rolled-out with appropriate training, management instituted a series of rigid compliance audits. "Since senior management did not fully understand the concept of process improvement they felt that good software discipline meant imposing rigid standards and then demanding full compliance as the ultimate goal of process improvement. Metrics were used solely to punish those who weren't doing what they were supposed to be doing, even though the staff did not really know what they were supposed to be doing. The emphasis on audits to the exclusion of planning assistance turned the SQA group into the process police."

Many project teams and senior managers, as well as many in the SQA group, imagined a rigid life cycle with ponderous documentation requirements, imposed on all projects, regardless of project scale, duration, or risk. Consequently, project teams began to "fill out the templates" without truly understanding the reasons for doing so. In so doing, many project managers reported that they did not have time to "follow the SDLC" or to "do CMM work."

In many cases, project managers told their users that a schedule could not be met because "we need to follow CMM." Without a better understanding of process improvement, the business user could not help but feel that it was just an impediment to progress.

During many training sessions we emphasized that the SDLC and the CMM were just best practice guidelines that a project manager should have already been following. No additional work should be involved, just a bit more rigor in doing existing work. This wasn't rocket science; these were just basic project management concepts.

Back to Basics
Unfortunately, we soon found that most project managers were completely unfamiliar with the basic concepts. "What! We need to track changes to requirements? You mean we need to estimate and plan our project?" "Do we need to track defects for small projects?" These became familiar questions.

When explaining the need to define task dependencies in the project schedule, one senior project manager asked how he would know what a dependency was. "Is there a checklist that will tell me?"

Another project manager, when told that professional judgment and common sense needed to be used when determining the necessary precision of a project plan actually asked, "How do we know when to use common sense?. Is it documented somewhere?"

Understanding of the CMM was also lacking, even though all project managers attended CMM introductory sessions. "What template does CMM require that I use?" "How often does CMM say that I need to have a status meeting?" The project is done, except for the CMM work." It just went on and on.

Failure is Not an Option
Believe it or not, even with these problems, several divisions within our information technology sector have been appraised at CMM Level II maturity. The rest of the sector is scheduled for CMM appraisals before the end of this year.

Unfortunately, the problems continue. Management is now treating the attainment of a level–"the plaque on the wall"–as the ultimate goal of process improvement. Consequently, there is little emphasis on institutionalizing the best practices, only on passing the assessment. As long as the templates are filled out, little thought is given to understanding and following the best practices.

Of course, the staff is petrified of "failing" the assessment. Not surprising since senior management shows its commitment to process improvement by threatening fire and brimstone if Level II is not achieved, regardless of any real improvements that may have been made in development efficiency.

The process team is conducting coaching sessions to prepare people for the appraisal. The sessions go beyond talking about the types of questions to expect. Participants want to know what the correct answers would be, as if this were a test of their knowledge of CMM. For example, "How do you track changes?" is answered with "What does CMM say I should be doing?", rather than just saying how they track changes.

Lessons Learned
It's been a long road that we ve traveled, and there's a lot of work still ahead–CMMI Level III anyone?

However, we've come up with some lessons learned that may help others just starting out with process improvement.

• The old saying that there are no stupid questions? Ignore it. There are stupid questions, and you'll hear them all.
• Understand that the CMM does not require you to have a documented procedure for everything that you do.
• Don't institute compliance audits before project teams know what they are complying with.
• Most questions you get will boil down to What's the minimum that I need to do to pass an audit?"
• SQA staff should have at least minimal experience in project management.
• Management commitment to process improvement should only be given after a complete understanding of what process improvement actually is and what it is not.
• Don't assume that your project managers know anything about project management.
• Emphasize tailoring to fit your procedures, templates and tools to the project at hand.
• Don't let tools drive how you manage your project.
• Make sure people understand that process does not replace common sense.
• Realize that you can improve regardless of whether you achieve a "level."
• Stress the importance of following the best practice activities without over emphasizing the physical work artifacts.
• Don't emphasize CMM at all. Train staff in basic project management practices and concepts and let CMM take care of itself.