THE LONG, HARD ROAD TO HERE


My career in systems process improvement (SPI) began in June of 1996 when I took a new position within Xerox as a member of the Software Engineering Process Group (SEPG) in the company s Production Systems Group (PSG). Back then, it was just software process improvement because it was based on Software CMM and CMMI was maybe only a twinkle in Mike Konrad s eye. I left Central Florida, my home of 36 years , and moved to El Segundo, California ” process that is KPAs no movie stars.

My introduction to the Capability Maturity Model for Software ( SWCMM ) was magical : a personal and professional epiphany. In this simple model for process improvement, I saw the cure to all that ailed software development, the be all and end all. I very quickly became an apostle of process improvement via implementation of CMM. In my position as de facto spokesperson for the division s SEPG, I missed no opportunity to preach the gospel of the five maturity levels and their blessed key process areas (KPAs). In the business days before it was chic to make fun of those who believed in holy grails , silver bullets, and pixie dust, I was convinced CMM was all three rolled up into one. So were a lot of other people. Of course, we were mistaken.

Less than four years later and still working in process improvement, I began turning around inside. Secretly and inwardly, I felt myself about to become one of the most vocal and antagonistic critics of the software process improvement initiative in Xerox. Thinking that perhaps the cause of my angst was peculiar to the Xerox environment (which is peculiar), I went to work for Computer Sciences Corporation (CSC) with the belief that they were doing things right with CMM. It took less than two years for me to find out they were not, and again I become disillusioned. Na ”ve me.

After considerable introspection, I finally came to grips with what had happened to me: the former CMM evangelist, while still completely enamored with the beauty of the model itself, had become quite disillusioned with the way in which most organizations were implementing CMM. By this time, many more organizations were making the same implementation mistakes with CMMI. I also came to the realization that so many people focus so much on the CMM/CMMI models that they lose sight of process improvement.

Thus this book. Sure, I could spend hundreds of pages lambasting management ineptitude in implementing process improvement in software and systems organizations. But then this book would be just one more of many in the useless genre of I told you so. And, hey, by the way, I was one of those inept managers. I d rather not focus on what people have done wrong and continue doing wrong. Instead, my contribution to people trying to make CMM or CMMI work for them is to share some valuable lessons I and others have learned in the hope that such lessons can be used to enable a smoother, easier, and quicker approach to process improvement.

I think the biggest problem people have with implementing Software CMM and CMMI is that they tend to view the model as something foreign or alien to software and systems development. Yet, when you really come to know these models and how they can be implemented, you begin to see just how naturally the models align with the way you would develop and deliver software and systems if you had the freedom to do things the right way. Despite what their critics believe, CMM and CMMI really are intuitive and natural. They represent the way people in software and systems organizations already work or want to work.

To prove this point, conduct this little experiment. Go out and ask some engineers , integrators, and project managers in your organization to describe how things would work if they were the bosses. Not surprisingly, you ll get original and organic answers from people that describe processes that can be closely mapped to SW-CMM and CMMI.

You ll get answers from engineers like, I wish the customers would make up their minds what they want. Translation: Define the requirements and manage them. Project managers/leads will say, I d like for my senior managers to stop changing the priorities every day. Translation: Manage (e.g., define, document, approve, and communicate) project commitments and find a way to keep them.

This is not coincidence . As cited in Software CMM s [1] Chapter 1, Section 1.1, The Evolution of the CMM, SW-CMM is based on actual software practices and knowledge gained from the study of successful software organizations. CMMI [2] improves on the CMM by incorporating real-world lessons learned from people who used CMM. CMMI does not introduce anything new to systems development and delivery, just as Software CMM didn t introduce anything revolutionary to software development. Both models simply codify what successful software and systems delivery organizations have been doing for many years. Translation: As a matter of practicality, if SW-CMM and CMMI are collections of good software/ systems engineering and management practices, then these models would exist whether or not they were ever published as books.

Confounding the pervasive misunderstanding of these models is that people want to view them as prescriptive. It seems that no matter with whom I speak in the process improvement community, they seem to want to read more into the models than what is there. Primarily, people trying to implement CMM or CMMI want to believe that it says how to do things, when, in fact, the model merely addresses what successful organizations do. People use meaningless phrases like SEI SM requirements or CMMI requirements when, in actually, nothing of the sort exists.

Thus the crux of this book: CMMI defines the processes that most reasonable people in systems development and delivery would do naturally if allowed to do so. If you really want to implement CMMI in your organization, don t! Don t try to force fit an academic model to your business. Instead, find what your business is already doing well and what it needs to do better. Map those good practices to the model and find what things in the model address what your organization is not doing so well. This book is not so much about CMM or CMMI as it is about process improvement; as you will see, the two are not synonymous.

Process improvement is inseparable from organizational change because introducing process or process improvement is change. There are dozens of books on the market ” some of them referenced herein ” which explore and explain managing organizational change and this book doesn t attempt to repeat those good works. However, because you cannot do process improvement without change considerations, there are digestible bits and pieces of practical organizational change advice interspersed throughout the text. Instead of being generic, this advice on change is specifically integrated with the how to text on process improvement to maximize its usefulness to you.

Another key message in this book is this: everything in CMMI may represent process improvement, but not all process improvement is in CMMI. CMMI is just one subset of the larger, more universal superset of things you can do to improve your software/systems delivery. It is very much like the field of astrophysics: each time scientists think they ve discovered the boundaries, they soon discover that the known is just a small part of a much larger, grander thing. CMM or CMMI is just a small part of the greater and grander universe of process improvement. For more information on this idea, check out CMMI s Place in the Process Improvement Universe in Chapter 1 ” News Flash! There Is a Level 1.

So the problem with focusing strictly on implementing CMMI (which you cannot do anyway) is that it becomes too easy to lose sight of many other opportunities for process improvement. People sometimes believe that if only they implement CMMI, they ll get process improvement. Many of the concepts and experiences described in this book suggest that the opposite is more likely: if you build a culture for process improvement, CMMI and maybe even maturity levels will come to your organization as a natural by-product.

Now back to my personal journey in process improvement. After leaving CSC and having over 20 years in corporate America learning mostly how things should not be done, a business partner and I struck out on our own and formed the process improvement and management consulting firm, Natural Systems Process Improvement (Natural SPI, Inc.). We founded our consulting practice on some very unconventional concepts and approaches to CMMI-based process improvement. So far, our unique message has been warmly welcomed by clients and the results of our work have genuinely benefited our client organizations. This book describes most of Natural SPI s successful concepts, approaches, and implementation practices.

Another pervasive theme you ll find throughout this book is that I try to balance thinking with acting and strategy with execution. On the Birkman personality profile, I m a documented freak: I think both globally and linearly, equally. Thinking great thoughts (which I don t claim to do) without being able to apply them is, for me, like fantasizing or daydreaming ; it s fun and may be good for me, but not very useful for anyone else. Acting without first thinking, executing without a plan, is almost always just plain stupid. So this book gives you the science and the technology, the proven concepts, and the practical steps for applying them.

I encourage you to have as much fun reading this book as I have had writing it. To illustrate concepts, I often point to mistakes people make in process improvement. I know of what I write for I have made or suffered every one of these mistakes. I made the mistakes, had a good laugh at myself, learned from them, and moved on. These mistakes are expensive. If your organization can avoid even one of the mistakes I address in this book, you ve gotten your purchase price returned many times over.

[1] Paul, Mark C. et al., The Capability Maturity Model, Guidelines for Improving the Software Process , Addison-Wesley, 1995.

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




Real Process Improvement Using the CMMI
Real Process Improvement Using the CMMI
ISBN: 0849321093
EAN: 2147483647
Year: 2004
Pages: 110
Authors: Michael West

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net