WORK PRODUCT-BASED APPROACH TO PROCESS IMPROVEMENT

Over the years , through unscientific studies of numerous organizations taking varied approaches to systems process improvement, through personal involvement in at least eight different efforts to achieve a maturity level, and after hours of surveying the prevailing literature, I have come to the general observation that the vast majority of organizations take what I label a procedure-based approach to software and systems process improvement or CMMI implementation.

The procedure-based approach to process improvement works, but it has one major flaw that makes it slow, costly, and painful: The simple, observable, and verifiable truth is that project managers or leads and engineers ” people who are doing the work to deliver software and systems ” do not like processes and procedures. (I ve invested most of my professional life in the process business and even I don t like procedures!)

Why don t managers and technical people like processes and procedures? The answer is found in the understanding that there are essentially two types of technological (including process) change ” competency-enhancing and competency-destroying. ^[37] A competency-enhancing technological change is one which people perceive helps them do their job better, makes them look competent, and makes them feel confident in performing their work. A competency-destroying technological change is one which people perceive inhibits them from doing a good job, makes them look incompetent in an area in which they were previously competent, and then threatens their sense of job security. People resist changes they perceive as competency-destroying for reasons that should be obvious: competency-destroying technology is perceived as a threat to being able to make the mortgage payment or rent.

In the world of CMMI-based process improvement, lengthy, detailed, narrative procedures are a competency-destroying technological change. Why? Because if you give a project manager or engineer a 40-page procedure document and tell them that it describes their job, they re wondering what was wrong with the job they were doing yesterday for which they didn t need a 40-page procedure. It gets worse from there. Let s say you hand a project manager a 30-page procedure telling her how to build a project plan. She reads the instructions, but when she sits down at her PC to build the project plan, she s still staring at a blank screen wondering where and how to start. Prior to the project plan procedure she was able to build project plans and now she can t. The procedure has left her feeling incompetent and threatened and the process people have made an enemy. There is a better way.

In the world of process, things such as electronic or online templates, forms, and checklists are all competency-enhancing process technologies. Why? Because with such items ” generically called job aids or implementation assets ” people are able to do the same job they were doing before, only better, faster, and more consistently. A plan template or a procedure checklist in the hands of a manager or technical person gives them an easy way to perform their work without having to remember or go read about things like sequence, format, and style. They re left deciding only on the area that is important, the content. Implementation assets also enable people to do the one thing they believe they re getting paid for, deliver work products. Engineers, architects , analysts, and project managers don t believe they get paid to perform processes; they believe they get paid to produce things. So when the process people give them an easier way to produce things (e.g., an easier way to get paid), it makes them feel more competent and more secure. And the process people have gained a friend and advocate of process improvement.

But wait, you say, what about CMMI GP 3.1 that calls for a defined process? Well, if you ensure that your template, form, or checklist is a documented expression of a set of activities performed to achieve a given purpose that provides an operational definition of the major components of a process, then it is a process description even if your organization calls it a template. ^[2] (For more information on defining your organization s terms for process assets and process definition activities, read Define the Process Language for Your Organization in Chapter 5 ” Five Critical Factors in Successful Process Definition.)

^[37] Adapted from Tushman & Anderson, Technological Discontinuities and Organizational Environments, Administrative Science Quarterly , 14, 311-347, 1986.

^[2] The Capability Maturity Model IntegrationSM ” SE/SW/IPPD/SS, V1.1, CMU/SEI-2000-TR-030 , Carnegie Mellon University, March 2002.