It is not necessary to change. Survival is not mandatory. | ||
| --W. Edwards Deming (1900–1993) | ||
The complexity of practice has always dwarfed the simplicity of theory. | ||
| --Robert Britcher, The Limits of Software (1999) | ||
Given that you are reading (or at least browsing through) this book, either you are interested in continuous process improvement and Capability Maturity Model Integration (CMMI), or you have been told to get interested in it. Perhaps your management chain or a major customer has indicated that your organization should be at least CMMI “level 3.” You think: “Should I really be interested? Will it make it easier for me to do my job? What is level 3? What is CMMI?” This book will help you answer these questions.
Chapter 1 reviews the business context for any improvement initiative, explaining why that manager or customer may be encouraging you to undertake such an initiative. To understand the rationale for change, it’s important to look at some shortcomings of traditional process improvement when faced with the engineering paradigm of the twenty-first century. The engineering world has changed in at least three significant areas since the introduction of model-based process improvement.
First, the environment within which engineering is performed has become increasingly complex. Efforts are larger, involve more people, cross corporate and international boundaries, are distributed far and wide, and must adhere to continually compressing implementation schedules so as to meet customer needs and heightened expectations.
Second, the way in which engineering work is performed has evolved. Cross-discipline teams, concurrent engineering, integration of commercial off-the-shelf (COTS) and open-source software rather than traditional software development, agile and evolutionary development approaches, highly automated processes, and multinational standards are all trends that have affected engineering practice. These changes, in turn, have inspired modifications in the role of the engineering manager.
Third, the continuing proliferation of process improvement models, methods, and standards has increased the challenge of defining and managing process improvement activities. Organizations have adopted multiple approaches to continuous improvement to address their critical processes.
All of these trends highlight the need to integrate process improvement efforts. The myriad disciplines and processes involved in contemporary engineering are closely intertwined. Unfortunately, the overhead and confusion resulting from the application of multiple models and methods are too costly in terms of business expenses and resource allocation. As a consequence, a means of addressing process improvement across a number of disciplines within a single framework is needed. This chapter discusses how changes in the engineering world have influenced the effectiveness of traditional process improvement strategies and explores how organizations can benefit from applying an integrated approach to reach their business objectives.
First, let’s talk about your organization and how you or your management might like it to perform. Organizations generally have many different business objectives:
Produce quality products or services
Create value for the stockholders
Be an employer of choice
Enhance customer satisfaction
Increase market share
Implement cost savings and successful practices
Gain industry-wide recognition for excellence
To achieve a strong competitive edge in a rapidly moving marketplace, you might like to aggressively take advantage of opportunities and avoid simply reacting to change. You might also like to improve your ability to predict costs and revenues, find ways to raise productivity, and implement means to lower expenses. These measures could help you to anticipate problems, and develop ways to address them early.
To meet any of these objectives, you must have a clear understanding of what it takes to produce your products or services. To improve, you need to understand the variability in the processes that you follow, so that when you adjust them, you’ll know whether the adjustment is advantageous. In short, you’ll want to manage your business using accurate data about both products and processes.
But wait: How do you know that your data is reasonable or accurate? Can you compare information between projects? Generally, there has to be some consistency in the work you do if you are to make valid comparisons. You want to be able to measure your success and make sure that the processes you follow add value to the products and services that you provide. Of course, that implies a standard way of doing things and a baseline against which to measure your subsequent efforts.
Now we are getting down to the nitty-gritty: Does your organization have experience with writing and following a process, and can it support the development of common, standard processes? Can you determine the best ways to go about a particular task? Establishing standard processes that are appropriate and successful for your workplace and business is fundamental for process control and improvement. Unfortunately, it may not be within the scope of your position descriptions or training. And what about that training?
Without good project management and fundamental technical skills, projects cannot operate effectively enough to spend any time on improvement. Basic activities such as planning and tracking need to be understood and encouraged. Version control and risk management are essential disciplines that need to be addressed. In addition, managing requirements so that you deliver value to your customer is a key business objective.
As you can see from the preceding discussion, getting to the point where your organization enjoys a competitive edge requires a number of incremental improvements. That’s where process improvement can really help. Process improvement activities focus on improving process capability, organizational maturity, process efficiency, and process control so as to help you advance the organization and accomplish its objectives. They can provide you with guidance on how to document and standardize processes, increase your work effectiveness, limit rework, measure the performance of the organization, and use the data to manage the business.
Of course, there is a cost associated with process improvement. Experience shows that it can take between 2 percent and 10 percent of normal engineering effort to support a significant process improvement initiative. At the same time, experience also confirms that process improvement brings a significantly positive return on investment (ROI) and improvement in key business indicators. Consider these representative examples of CMMI successes:
DB Systems GmbH reported that its costs dropped 48 percent from a baseline prior to SW-CMM maturity level 2 as the organization moved toward CMMI maturity level 3.[5]
As the organization moved from SW-CMM maturity level 3 to CMMI maturity level 5, IBM Australia Application Management Services saw its on-time delivery increase by 10 percent, its on-budget delivery improve by 41 percent, customer satisfaction rise by 33 percent, and application development productivity improve by 76 percent, resulting in a cumulative costs savings of AU$412 million to the company’s client.[6]
Northrop Grumman IT Defense Enterprise Solutions, a CMMI maturity level 5 organization whose engineers had undergone Personal Software Process (PSP) training, reduced identified defects from 6.6 to 2.1 per KLOC over three causal analysis and resolution cycles.[7]
Reuters’ schedule variance decreased from approximately 25 percent to 15 percent as the organization moved from CMM maturity level 3 to CMMI maturity level 5.[8]
As these examples demonstrate, process improvement promises significant benefits for organizations. In the remainder of this chapter, we show how integrating process improvement across several disciplines can increase those benefits.
Remember when there was only one telephone company and only one kind of phone service? When the only telephone-related worry you had was keeping long-distance calls under three minutes? When you understood not only the principles but also (perhaps) the mechanics of how the system worked?[9] Unfortunately (or fortunately in some cases), the era of such relatively simple systems has ended. When you realize that your new telephone contains more software than the lunar landing module, Dorothy’s plaintive cry, “Toto, I don’t think we’re in Kansas anymore,” may all too closely echo your feelings of consternation. Even technology-savvy engineers occasionally profess a sense of awe about the relentless pace of technological change. No one can deny that this change has brought new capabilities, new conveniences, and new complexity.
We are now on the rising edge of the system complexity curve, and there is little chance of moderation in the foreseeable future. The U.S. Department of Defense has estimated that it will soon need to field systems utilizing as many as 40 million lines of software code. In some autonomous military systems, software will provide decision-making functions for reconnaissance and weapon delivery.
Many traditionally hardware modules now contain significant microcode that will inevitably interface in some manner with a software control system housed in yet another hardware device. In increasingly complex systems, the ability to differentiate between hardware and software functions may become nearly impossible, complicating design and maintenance tasks and significantly affecting our ability to calculate expected reliability. This complexity is readily evident in the products and systems being conceived, designed, and manufactured each day; moreover, it is mirrored in the activities of the acquiring and developing organizations, both in industry and government. As if the complexity of modern systems was not enough, now more attention is being focused on “systems of systems,” as better integration of functions across individual systems is needed.
As systems grow more complex, the processes used to develop them will follow suit. The complexity of processes inevitably increases to keep pace with the number of individuals who are involved in their execution. The theory and concepts of process improvement are elegant and understandable. When we apply them to increasingly complex systems, however, we find that, as Robert Britcher writes, “the complexity of practice has always dwarfed the simplicity of theory.”[10] This result is particularly likely when the processes cut across organizational, discipline, corporate, or cultural boundaries.
With large and complex organizations, processes, and systems, process improvement activities can easily become lost in the multiplicity of tasks, agendas, and personalities. Because each office or organization has its own responsibilities and diligently strives to improve its own practices, process improvement efforts can evolve into a patchwork of unrelated and uncoordinated activities spread across a variety of organizations. Multiple groups and their executives may vie for limited process improvement resources. Various process groups may select different and sometimes conflicting improvement models. Competition can emerge between groups, and the ownership of process improvement can become hotly debated. In the end, often more energy is spent on the peripheral activities than on the improvement initiatives.
Lest you think that only large organizations have process problems, consider the small, entrepreneurial firm racing to capitalize on a rapidly approaching market window. Such an organization finds it difficult—if not impossible—to address process improvement when the time-to-market criterion is so crucial to its survival. Such a firm often has personnel performing multiple engineering functions simultaneously; conceivably, it may have a different process for each individual in the company. As another example, an information technology application services company may be forced to deal with an erratic customer who constantly changes requirements, priorities, and schedules, leaving little alternative for the firm except to function in a crisis development environment. Although neither type of organization described here has the financial or people resources to pursue traditional process improvement, each could benefit greatly from taking a more disciplined approach to engineering.
The organization of engineering and product development work has undergone significant changes in recent years. Much of this change has been aimed at eliminating the inefficiencies associated with stepwise development, in which intermediate work products are handed off to next phase workers, who may have to do significant rework to correct misunderstandings. Concurrent engineering, cross-discipline teams, cross-functional teams, integrated product teams (IPT), and integrated product and process development (IPPD) all represent ways to address this problem and apply the necessary expertise at the appropriate time throughout the product or service life cycle. In practice, this trend means that designers and customers work with manufacturers, testers, and users to support the manufacturing organization in developing requirements. It has also been described as having “everyone at the table,” implying that all critical stakeholders support all phases of product or service development.
Understandably, the concept of concurrency has redefined the nature of organizational structure and development. It requires an enhanced management competency for dealing with “gray areas” and ambiguity, which is not easy for many managers who are perhaps more versed in dealing with tangible facts and figures. The general acceptance and rapid deployment of cross-discipline or cross-functional teams in the engineering world has also proved to be a thorny issue for process improvement. The concept of functional departments, each with its own processes under its own control, strongly clashes with the highly interactive work style associated with cross-discipline teams.
To date, discrete process improvement models and techniques have not effectively supported the “mixing bowl” environment of concurrent engineering. If the hardware engineering department is using one approach, the software developers are using a second approach, and the outsourcing and contracts departments are using yet another strategy, problems are inevitable. Separate “stovepipe” models and methods offer little chance of improving the processes used by a cross-discipline team where every member is an actor in most of the processes and the separation between the disciplines has gone the way of the Berlin Wall.
Rather than relying on the strict stages of classical development, cross-discipline teams use integrated processes that are matched more closely to the ebb and flow of the emerging life cycle models and agile development methods They take advantage of evolutionary development approaches and innovative design techniques. Attempting to apply the discipline-specific methods to such processes is analogous to requiring members of a jazz trio to strictly play their individual parts. Of course it’s possible—but the outcome is not very satisfying. What is needed is an approach to improvement that not only integrates the disciplines, but also integrates the processes themselves and supports effective work among various stakeholders, functional personnel, and management.
The advent of agile processes and the extension of spiral development to systems and “systems of systems” add an additional twist to the engineering process. These methods challenge much of the traditional industrial approach, replacing it with a more flexible and change-neutral process. There is still a great deal of discussion as to how process improvement is defined and measured in these paradigms, particularly when changes to the process may be as frequent as changes to the product requirements. A good discussion of the impact of agile and spiral approaches may be found in Balancing Agility and Discipline by Boehm and Turner.[11]
If imitation is a measure of success, then the Capability Maturity Model for Software (CMM) was exceptionally successful—and for good reason. People in many disciplines were attracted to the elegance of the CMM concept and its close ties to quality management theory and practice. The general response was, “Hey, that’s a great idea. Let’s build something like that for our shop.” The end result was a number of similar models that shared intent but not terminology or construction and, therefore, were difficult to use together or to compare results.
At the same time, several international standards have been created that address similar issues:
ISO/IEC 15288, an international standard on system life cycle processes, was first issued in 2002 and reissued in 2008.[12]
ISO/IEC 12207, an international standard on software life cycle processes, was first issued in 1995 and amended in 2002 and again in 2004, and reissued in 2008.
ISO/IEC 15504, an international standard that defines the requirements for performing process assessments that (in various parts), was first issued between 2003 and 2006.
Finally, other approaches to achieving process improvement benefits have been widely implemented. These include Six Sigma and lean engineering and manufacturing.
In the preceding sections, we enumerated many factors that complicate process improvement. It is our assertion that overcoming many of these obstacles is possible by integrated, continuous process improvement. Of course, you may need to be convinced that this endeavor is worthwhile for your organization. At the end of the day, what are the real benefits of integrated process improvement?
Fundamentally, process improvement integration significantly affects four areas: cost, focus, process integration, and flexibility. Some of these changes are more easily quantified than others, but all represent real advantages.
Cost containment is probably the easiest benefit to understand. Although integration requires additional investment, the savings from process improvement integration can be significant. By applying a common approach to continuous improvement, organizations can reduce the costs attached to the following endeavors:
Training in multiple approaches, including models and appraisal methods
Performing multiple appraisals within the same organizations (and possibly with the same practitioners)
Maintaining redundant process assets in a repository
Maintaining or purchasing expertise in multiple approaches
The enhanced probability of success that arises from integrated process improvement also makes it more likely that the organization will achieve cost savings resulting from higher quality, better predictability, and all the other benefits of improved processes.
Within the diverse world of engineering organizations, particularly when projects cut across organizational boundaries, it is difficult to achieve the critical mass necessary to bring about real improvement. This problem can be characterized as a lack of focus and a need to unify the disparate activities. That is, the pressures from outside the group are too strong, the costs too high, or the resources too thinly applied to both improve local processes and interface them with other organizations or disciplines. Budget changes, the business environment, internal politics, and mergers all take their toll by consuming resources that might otherwise be applied to improvement.
An integrated process improvement program can clarify the goals and business objectives of the various constituencies. By integrating process improvement activities across a wider range of disciplines, it becomes easier to rally the troops—both practitioners and executives—to the process improvement banner. Having a single process improvement focus can unify and reinforce vision, efficiently marshal and apply scarce resources, and provide a common language for improvement across various disciplines. In particular, a single model with common terminology and common appraisal methods helps to provide this kind of focus.
A word of caution is appropriate at this point. Not every model can become the focus for continuous process improvement. If the focus doesn’t include all of the disciplines critical to organizational success, it will miss the breadth actually needed to improve the organization’s operations. An integrated approach allows personnel in each discipline to identify with the processes and feel that they have a stake in the now-focused process improvement program.
One of the less obvious benefits of integrated process improvement is the “integrating” effect it has on organizations. When processes are defined across organizational and discipline boundaries, new understanding and mutual education often occur, resulting in the streamlining of the critical work flow and the elimination of redundant or unneeded activities.
Stovepipe[13] process improvement often assumes that interfaces between organizations work effectively; rarely is one process implementer aware of closely related or redundant activities in a sister stovepipe. By working on improving processes across the board, the organization essentially obtains a bonus reengineering effort as a byproduct of the process improvement initiative. This streamlining supports the lean concept, which strives to provide increased value to the customer by eliminating waste in the production of products.[14]
A final benefit is the ability to adapt to and exploit business or engineering environment changes. Integrated, continuous process improvement creates and supports an organization that is comfortable with changes associated with refining their work processes. Having a common process infrastructure allows changes to rapidly enter critical work processes, increasing the rate of both infusion and diffusion.[15] Decision making and strategic planning are more efficient and effective given capable processes across disciplines and maturity across organizations. Organizational changes such as corporate reorganizations, mergers, acquisitions, and teaming may be able to benefit from common process language. This benefit may be moot, however, if the organizations involved have chosen radically different process implementations.
This chapter argued that integrated process improvement can be an effective and efficient way of addressing a wide range of business objectives. It identified changes in the engineering environment, discussed the integration of processes across the product life cycle, and described a cacophony of competing standards—three factors that strongly suggest the need for integrated process improvement. Finally, it defined the benefits of such an approach beyond the simplification of an organization’s improvement efforts.
Any change requires letting go of old ways of doing business—even ways that may have been successful to some degree in the past. This can affect not only the way in which those directly involved in projects work, but also the way in which managers at all levels understand their roles. To maximize the chance for true improvement, managers need to lead the effort to make process improvement a way of life across the organization, even in the face of the constant need to deal with short-term problems.
Chapter 2 offers some practical advice on taking the plunge and implementing an integrated approach to continuous improvement. By providing some guiding principles for how process improvement integration works in large and small organizations, we hope to ease your implementation of this beneficial approach.
But what if your organization isn’t complex or multidisciplinary? Single-model or single-technique process improvement works perfectly well in some organizations. Nevertheless, we invite you to look carefully at the CMMI product suite and its role in an integrated approach to continuous improvement before returning to or beginning your single-model effort. The integration of disciplines in CMMI has produced a better model in a number of ways, even when applied just to a single discipline. Besides, as a result of learning CMMI you’ll be a lot better informed if your new CEO starts preaching the benefits of cross-disciplinary teams and a unified approach to continuous improvement.
[1] Deming, W. Edwards. Out of the Crisis. Cambridge, MA: MIT Center for Advanced Engineering, 1986.
[2] Crosby, P. B. Quality Is Free. New York: McGraw-Hill, 1979.
[3] Juran, J. M. Juran on Planning for Quality. New York: MacMillan, 1988.
[4] Garcia, Suzanne, and Richard Turner. CMMI Survival Guide: Just Enough Process Improvement, Boston: Addison-Wesley, 2007.
[5] Richter, Alfred, “Quality for IT Development and IT Service Operations: CMMI and ITIL in a Common Quality Approach.” London: ESEPG, June 16, 2004.
[6] Nichols, Robyn, and Colin Connaughton, Software Process Improvement Journey: IBM Australia Application Management Services. A Report from the Winner of the 2004 Software Process Achievement Award (CMU/SEI-2005-TR-002). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 2005.
[7] Hollenbach, Craig, “Quantitatively Measured Process Improvements at Northrop Grumman IT.” Denver, CO: CMMI User Group and Conference, November 2003.
[8] Iredale, Paul, “The ‘Internal Offshore’ Experience at Reuters.” Adelaide, Australia: Australian SEPG, September 27–29, 2004.
[9] If you are too young to remember this time, ask a parent or other elder within your circle of friends. They’ll appreciate the time to reminisce. If they begin to talk about the value of hard work, the buying power of the dollar, or walking 20 miles to school barefoot in the snow uphill both ways, however, make your escape quickly!
[10] Britcher, Robert, The Limits of Software. Reading, MA: Addison-Wesley, 1999. This fascinating treatise on the philosophy and practice of software engineering is drawn from the author’s work with IBM on the Federal Aviation Administration’s (FAA) Advanced Automation System (AAS). AAS was terminated after expenditures of approximately $2 billion, based on the judgment that it could not be accomplished.
[11] Boehm, Barry, and Richard Turner, Balancing Agility and Discipline: A Guide for the Perplexed. Boston: Addison-Wesley, 2005.
[12] ISO is the International Organization for Standardization; IEC is the International Electrotechnical Commission. For current information on international standards in the areas of systems engineering and software, see http://www.jtc1-sc7.org/.
[13] Stovepipe processes are usually organized by discipline and do not include the interfaces between those organizations.
[14] Womack, James P., and Daniel Jones, Lean Thinking. New York: Simon and Schuster, 1996.
[15] For a discussion of measuring infusion and diffusion, see Garcia and Turner, CMMI Survival Guide: Just Enough Process Improvement.