Process improvement is not all fun and games, especially for the people responsible for rolling out the improved processes. This article is a tongue-in-cheek look at some of the pitfalls of process improvement. However, many a truth is said in jest.
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