APPLYING A SYSTEMS VIEW TO PROCESS IMPROVEMENT | Real Process Improvement Using the CMMI

Systems thinking, which was definitively described by Peter Senge in his seminal work, The Fifth Discipline ^[22] has been used by many people to investigate and resolve deep organizational problems and to achieve higher states of operational excellence. You can use systems thinking to effectively resolve many of the barriers and problems that commonly plague CMM and CMMI-based process improvement initiatives.

Losing Sight of the Forest

Living day to day in a process improvement job, it s easy to quickly lose sight of the big picture; we can t see the forest because we re focused on the trees. We tend to see individuals around us making independent decisions and taking seemingly unrelated actions. We get caught up in trying to deal with every separate event using a different approach and frame of mind than the last event. It is also quite easy to lose sight of the relationships between your process improvement work and product or service delivery. Sometimes, CMMI or process improvement takes on a life of its own and we end up doing process improvement for its own sake.

In systems thinking, Senge described two systems archetypes that provide a way of gaining a big-picture view of commonly occurring systemic problems in organizations: fixes that backfire and shifting the burden . These two archetypes are particularly useful in understanding and resolving problems that frequently plague CMM and CMMI-based process improvement efforts.

Fixes That Backfire

In the fixes that backfire systems archetype , the obvious solutions are applied to problems. However, because the perceived or obvious solution is frequently applied hastily and without a thorough understanding of the problem, the result is often unintended consequences, including a worsening of the problem. The most pronounced example of a fix that backfires is corporate downsizing to improve profits. In one 1991 study of 850 companies that had cut staff drastically, only 41 percent had achieved the savings they hoped for. ^[23]

The diagram in Figure 4.2, known as a causal loop diagram, illustrates the dynamics of the fixes that backfire archetype as it relates to software and systems process improvement. Because the net, long-term, negative effects of the fix are greater than the short- term , positive effects, the reinforcing loop is the prevailing influence in the system.

Figure 4.2: Process Improvement ” Fixes That Backfire Causal Loop Diagram

In Figure 4.2, the top loop represents the organization attempting to address the problem of poor software or systems delivery by implementing CMMI-based process improvement. The bottom loop ” also known in systems thinking as an addiction loop ” represents the long-term effects of the fixes. When it turns out that process improvement is not the panacea that it is often touted to be, there can be unintended negative consequences.

The fixes that backfire archetype has three primary manifestations in process improvement:

The race to achieve a maturity level causes widespread cynicism, which in turn leads to a grass-roots resistance to the process improvement initiative.
Process discipline and improvement is done for its own sake and the consequence is that the organization s software and systems development performance gets worse .
The cost and value of process improvement activities are not integrated with the price of things sold to a customer, such as the price of products sold or cost of services rendered. Process improvement ” and probably other internal improvement initiatives ” are viewed as infrastructure or overhead. As these internal initiatives grow, so does the percentage of the organization s employees whose work does not directly produce something that is sold to or adds value to what is sold to a customer. Thus, as William Bergquist noted in his book, The Post Modern Organization, ^[24] and as illustrated in Figure 4.3, it becomes increasingly difficult for the expanding organization to achieve and maintain its profit goals because operating costs grow at a faster rate than that of realistically achievable revenue.

Figure 4.3 The Relationship between Organization Size, Internal Infrastructure, and Profits

The Race to Maturity Levels

Frequently, executive and senior level managers are sold on CMM or CMMI as a vehicle for improving software or systems development and delivery. However, they get fixated on achieving maturity levels under the belief that maturity levels are concrete evidence that processes have improved. The maturity level becomes the evidence that the organization has improved its efficiency, effectiveness, and quality. Such beliefs are as faulty as assuming a student has actually learned something because he received an A in class.

Acting on this fixation, the executives will sometimes construct incentives, such as bonus programs for senior and mid-level managers to achieve maturity levels in their respective suborganizations. Now, both level envy and the ensuing race to achieve levels is on! The focus on maturity levels drives people to look for quick fixes that will enable them to pass an appraisal. The symptoms ” observable behaviors and artifacts ” most commonly associated with a race to maturity levels are:

Deadlines are established for achieving a maturity level without any estimating or project planning that supports the deadline (which, by definition, is a low maturity behavior).
The appearance of ridiculous slogans such as Level 5 in 05.
People read CMM or CMMI and learn to recite the model s terms and phraseology .
Policies and procedures are rapidly created and frequently copy practices verbatim from CMMI.
Project managers, under pressure from upper level management, create elaborate project documentation that satisfies the letter but not the intent of the model. They promptly shelve the project documentation and do not use it to manage their projects.

Figure 4.4 illustrates, in a not too exaggerated way, the kinds of behaviors you can often observe in an organization that has entered the maturity level race. You ll laugh , but I ve witnessed this behavior and the people involved took themselves seriously!

Figure 4.4: The Race to Maturity Levels

The problem worsens in a large organization in which various suborganizations are trying to achieve maturity levels independent of each other. The suborganizations respective managers too often let their egos and competitive natures get the better of them and try to out-do each other to be the first to achieve the targeted level.

Once organizations have become entrenched in the level race (or perhaps more accurately, level wars ), they are in the addiction loop of the fixes that backfire system archetype and you can count on rationale and reason being abandoned . The organization takes a short trajectory to the maturity level, which it more often than not achieves ” one way or another.

And what of the unintended consequences? Those incentives for achieving maturity levels usually stop at the mid-level manager and almost never make it down to anyone doing the work, including SEPG members and project managers who have done the bulk of the work in the death- march process improvement project. For a time period ranging from two hours to three days following passing the appraisal, everyone in the victorious organization is elated and ecstatic. Once the appraisal high wears off, people start looking around for some lasting and meaningful results of their work but, for reasons they can t always comprehend, everything looks and feels the same as it did before the maturity level race. Now, good luck to executives and senior managers who try to persuade these same people to get excited again about the next maturity level.

Even in extreme command-and-control work environments where the primary motivation is fear (usually of losing your job or being marginalized), these fixes that backfire eventually take their toll on the morale and momentum of process improvement initiatives. Smart, skilled, process-disciplined people start to look outside the organization for more meaningful, rewarding work. Project managers and engineers become jaded on the whole idea of model-based process improvement. They ll continue giving a gratuitous salute or lip-service out of fear of not conforming, but they ll be burned out on process. Worse yet, they will perceive ” perhaps accurately ” that the whole CMMI effort is a waste of time and money. Cynicism prevails.

The organization that chases maturity levels for their own sake and fails to set business goals for process improvement will spend hundreds of thousands or even millions of dollars on model-based process improvement and have nothing more than a few gratified egos to show for a ROI. Recent very public situations tell us that greed and ego may not be so in vogue anymore in corporate America.

Process for Its Own Sake

Sometimes, organizations don t get too wrapped up in CMMI maturity levels, yet process still becomes the be-all and end-all to fixing every issue plaguing the organization. For many of my years in Xerox, it s the process or fix the process became the only politically acceptable approach to any problem. The primary fallacy of this approach is that it ignores the observable, measurable fact that there really are people and accountability problems which cannot be resolved by addressing only the process.

A classic example of a backfire from applying a fix occurs when organizations attempt to apply the entire CMMI to traditional IT or sustaining engineering shops . With intelligent interpretation and tailoring, many of the CMMI practices can be applied to improve work in these environments. But the implementation of processes and procedures that are nothing but a regurgitation of CMMI in these environments results in burdening the organization with process overhead that doesn t add value, thus making the organization less effective and efficient than they were without CMMI.

Strategies for Fixes That Backfire

Here are some strategies you can employ to prevent or mitigate the effects of implementing fixes that backfire:

In planning the process improvement effort (see Chapter 3 ” Managing the Process Improvement Project), ensure the plans include achieving measurable or observable business goals in addition to achieving maturity levels. Make sure that reporting progress or success includes status against all the process improvement goals and not just the number or percentage of practices satisfied.
Increase awareness, especially among senior and executive managers, of the unintended consequences of chasing maturity levels. In 2001, I was involved in an e-mail conversation with senior level managers and marketing people in CSC who were trying to come up with strategies for countering the CMM level race approach of one of their biggest competitors . I sent out a note thinking that it would be career limiting because it went directly against the prevailing beliefs. Much to my surprise, a senior marketer read and understood my note and invited me into further conversations on how we could market real process improvement benefits without getting into level-wars with our competition.
Spend the time understanding the problem. You don t necessarily have to conduct time-consuming formal root cause analysis, which can often lead to analysis paralysis, but you can t afford to continue applying solutions to symptoms, only to have the root problem perpetuate or worsen.
Establish alliances or relationships with people in your marketing and sales organizations. Find ways to defray some of the cost of process improvement activities by selling (and charging for and collecting!) the benefits of process improvement. With the right approach, a customer or client will be willing to pay a higher price for the goods or services so long as you ve convinced them that there is greater value.

Shifting the Burden

According to Senge s, Systems Thinking, shifting the burden

usually begins with a problem symptom that prompts someone to intervene and solve it. The solutions are obvious and immediate; they relieve the problem symptom quickly. But they divert attention away from the real or fundamental source of the problem, which becomes weaker as less attention is paid to it

Shifting the burden to process improvement is illustrated in Figure 4.5.

Figure 4.5: Process Improvement ” Shifting the Burden Causal Loop Diagram

In this systems archetype, the perceived problem is a lack of process or process discipline in the organization or that the organization does not have a CMM or CMMI maturity level. So the obvious solution is to implement CMM or CMMI. In the short term, the fix does appear to address the perceived problem; lack of process is resolved by writing and implementing processes.

The not so easily observed yet insidious effect is that effort and focus shifts from product or service delivery (or integration) to the symptom of inadequate processes, which in turn either does nothing to improve product or service delivery or hurts it by burdening the existing delivery processes with overly bureaucratic standards, procedures, methods , and work products which don t help.

Table 4.1 identifies some common systems development and delivery problems (in the left column). The center column identifies how these problems often are perceived as process (or lack of process) problems. The third column identifies other possible root causes of the problem, which may have little to with process discipline or maturity levels.

Table 4.1: Common Shifting the Burden to Process
Software/Systems Delivery Problems	Perceived as a Process Problem	Potential Real or Root Problems Not Addressed Due to Shift
Projects experience scope creep	Inadequate requirements management process	Poor business relationship with customer Lack of discipline in engineering staff No release strategy No strategy/process or insertion of new technology Lack of standards for acceptance or decline of original requirements The organization doesn t understand the market it is in
Projects overrun cost and schedule	No estimating or planning process Project plans are not adequately documented	Culture encourages low bid; accurate bidders don t get work Schedule is synonymous with plan Poor business relationship with customer No release strategy Staff has inadequate skills to do the work The term project is not defined Management doesn t perceive planning activities as work/progress
Product quality (e.g., defect density) is poor	No quality process No people assigned to inspect/audit the quality	The organization has no defined standards or criteria that define quality Management and the culture rewards fast and cheap; good is not encouraged or rewarded Staff has inadequate skills and resources to produce quality work
No amount of process improvement activity seems to improve the bottom line	People won t buy into the PI initiative Not enough in-house CMM/CMMI expertise Clients don t value the process improvement efforts	Misalignment between the chosen model and the organization s core business and business goals There are no baseline performance or capability measurements with which improvement could be ascertained. Improvement is anecdotal.

Strategies for Dealing with Shifting the Burden

Why Systems Thinking?

Modern software or systems organizations are themselves a system of systems. There are people (social systems), tools and technology ( technology systems), and policies, processes, and practices (process systems). The three systems ” people, processes, and technology ” are inextricably interwoven and changing one without considering the interrelationships can cause fixes that backfire, don t resolve the original problems, or inadvertently make the problems worse.

The greatest unintended consequence of applying a CMMI or process solution to a nonprocess problem is too often the vast waste of resources used for the faux fix. If you really want to improve things in your organization, start by improving the process of process improvement. You can save your organization money and aggravation by using this systemic approach.

^[22] Adapted from Senge et al. , The Fifth Discipline Fieldbook: Strategies and Tools for Building a Learning Organization , Currency-Doubleday, 1994.

^[23] Amputating Assets: Companies That Slash Jobs Often End Up with More Problems Than Profits, US News and World Report, May 4, 1992.

^[24] Adapted from Bergquist, William, The Post Modern Organization: Mastering the Art of Irreversible Change , Jossey-Bass, Inc., 1993.