Chapter 3
Why Process Improvement Isn’t Trivial

Lest you misinterpret anything we have discussed so far, be aware that process improvement (PI) is not trivial. First, it is an intentional activity—that is, if you start a PI project, it won’t run on autopilot; you have to pay attention to it.

Second, many collateral activities have to go on to support a PI initiative. These initiatives do require resources, for example, and unless you personally have control of sufficient resources, you will have to establish and sustain sponsorship for the activity from someone who does. You have to establish some modicum of infrastructure for measurement and deployment of improvements, even in a small organization. That may be a single person paying attention to improvement issues part time, or it may be a group that gets together on a regular basis to prioritize and deal with process issues. Larger organizations will probably need to stand up some sort of official process improvement group, and that means more resources. You will most likely cross some organizational boundaries, so negotiation with other groups may become necessary.

The object, of course, is to minimize the amount of infrastructure and overhead so that your PI initiative can be as lean and effective as you want your business processes to be.

This chapter provides a summary of the primary cost and effort challenges associated with a process improvement effort. In Part IV, we’ll give you some guidance on how to deal with these challenges successfully.

3.1 Building and Sustaining Sponsorship

The challenge of building and sustaining sponsorship is one that every organization faces, but it’s one area where the solutions tend to be fairly specific to the context and culture of the particular setting.

The sponsorship we’re talking about is the people who have purview over the policies, processes, and resources associated with what you want to improve. Getting those people to agree to sponsor PI actively—through allocating resources, supporting policy changes, and reinforcing the changes made with the improved processes—is the first challenge. The second challenge is keeping them interested and supportive when things get moving.

This is one area where small settings may have an advantage, if your senior management is supportive of process improvement. If the CEO or CTO favors process improvement, it’s usually a very short walk to find the project manager who will make the changes needed to improve a project’s practices.

The larger and more diverse the organization (in terms of geography, business sector, customer, or culture), the more of a challenge sustaining sponsorship is likely to be. Usually, to be successful, a process improvement effort requires both the sponsorship of a manager whose span of control encompasses all the parts of the organization affected by the improvement and the sponsorship of the intervening managers in the organizational hierarchy. Some people call this intervening level of sponsorship the “middle-management black hole,” because many improvement efforts seem to disappear between the senior manager and the parts of the organization meant to participate in them. In Part 4, we explore some of the particular challenges you may run into and some strategies for dealing with these kinds of sponsorship challenges.

3.2 Managing an Appraisal Life Cycle

Appraising your processes—evaluating the gap between your current processes and the way you want your processes to work—is one of the activities that you must perform on a regular basis if you are to have confidence that you are improving, not just changing. Most organizations find it useful to appraise their processes against external benchmarks of best practices relevant to their business as an objective way to measure their improvement (what we call reference models in Chapter 2). CMMI is our personal favorite of several models that are used to help organizations benchmark their processes.

Note that the title of this section is “Managing an appraisal life cycle” as opposed to “Conducting appraisals.” We don’t assume that you will have in-house capability to conduct appraisals when you’re getting started. There are different forms of appraisal, some external and some internal. External appraisals are often used to inform supplier decisions or to make marketing claims. Many organizations want to have confidence that the processes of the suppliers they are dealing with are capable of performing to their expectations. External appraisals usually are a fairly expensive activity; that’s the first challenge of managing an appraisal life cycle. External appraisals involve hiring external consultants who are qualified appraisers and involving internal staff in both preparing for the appraisal and participating on the appraisal team.

Internal appraisals typically are less expensive and time consuming than external ones, and after you know what you’re doing, they can be quite effective. When you’re just getting started, however, you’re often in the position of not knowing what you’re doing, in relation either to the model you’ve chosen to benchmark against or the appraisal approach you’re planning to use. This is one of the places where getting external expertise can have a high payoff.

Most organizations employ a mix of external and internal appraisals: external ones when they are ready to or need to “prove” to outsiders how far their improvement has progressed, and internal ones to help them decide what to address next to get the most business value for the organization or to understand how close they are to an external benchmark they need to achieve.

The improvement challenge here is finding and retaining the skills and resources (both external and internal) to plan, perform, and communicate about the appraisals needed for your business context.

3.3 Developing and Sustaining Process Improvement Infrastructure

No matter which improvement life cycle or model you choose, you need to accept the fact that a long-term organizational improvement effort will require a sustainable infrastructure of people and other critical resources. This is the capital-investment aspect of improvement. When you’re building a manufacturing facility, you accept the fact that you will have to pay for the building, the tooling, the design of the manufacturing line, and the selection and training of the people who will manage the plant before you produce a single item from that line. We’re not trying to say that an improvement effort is as big as building a manufacturing plant, but both efforts share the attribute of requiring some level of investment before you can expect to see much benefit, and both require maintenance and sustainment of that infrastructure if you want to continue seeing benefit from their operation.

One difference between the DLI life cycle and some other PI life cycles is that the first three stages (Decide, Try, Analyze) are geared toward getting results without a large infrastructure already in place (at least for the first time through the cycle). This allows you to learn a little bit about the improvement process before committing resources to your PI infrastructure.

Some of the typical infrastructure elements you will need for a long-term effort include a measurement system; a Process Asset Library (PAL) or other knowledge repository; and training materials, some of which you may be able to acquire and some of which you’ll probably have to develop internally. We give you guidance on these and other infrastructure elements you may need in Part 4.

3.4 Deploying New and Improved Processes

The real work of process improvement is about understanding your current processes and making changes in them that will make them work better for you. If you’re an engineer, this is akin to improving a product that’s been released. You need to understand what needs to change to improve the product (the requirements), and you need to design, implement, and test the changes that will meet the requirements. You do the same thing with processes. If you’ve ever built or evolved a product, you know that this simple set of steps breaks down into an often amazing number of details that have to be done correctly, at the right time in iterative cycles, to enable everything to integrate in a way that will actually be an improvement.

As shown in Figure 3-1, designing and deploying new or improved processes is like building a product, in that you should, for each iteration

•   define requirements for the process. What does this process need to accomplish? Some of these requirements can come from the gaps you find between your processes and an external benchmark, such as CMMI; others come from the business needs of the organization.

•   design the process. Usually, you do this through a process-definition exercise, which usually has both a graphical “mapping” type of component and a more text-based component.

•   implement the process. This is often discussed in terms of piloting the process—making sure that the first people using the process understand it and are appropriate to use it, and that the right support mechanisms are in place to get feedback on the new process.

•   validate the process. The results from the pilot provide feedback on the utility and appropriateness of the process in its first use. Often, you will extend the pilots into other parts of the organization after the feedback from the initial pilot has been incorporated into the process definition and support elements so that the process can be deployed to its target audience. In some cases, you may have to go back to the drawing board for a process redesign.

•   deploy the process. Now you can communicate the process to the target audience, making sure that they have the support tools needed to perform it and verifying that your incentives system encourages (or at minimum doesn’t discourage!) use of the process.

So if you’ve built products before, what’s the big challenge in developing and deploying new processes? The fundamental difference between product development and process deployment is that process deployment is all about getting people in an organizational setting to change their behavior as individuals and groups. The skills that we learn for designing particular products generally are not the same as the ones we need for enabling people to change to a new set of behaviors. Most of those skills come from the psychology, sociology, and anthropology disciplines, which typically are not well represented in business and engineering organizations. In later chapters, we expose you to some models and techniques we’ve found useful in helping people change their behavior.

Figure 3-1: Product versus process development phases

3.5 Developing And Measuring Realistic Goals

A key area of discussion in any endeavor in which capital (human or otherwise) is invested is concise definition of goals and mechanisms used to measure progress. Unfortunately, measuring something as invasive and complex as process improvement has proved challenging. In large companies, it is almost impossible to separate benefits gained in PI from the variances in personnel, task complexity, customer, domain, or any other number of contributors to project outcome. In smaller environments, however, it may be easier to identify where and how PI contributes to the business.

Our best advice is to develop goals around business values that resonate with all levels of your organization. Goals for improving organizational performance and quality generally are more useful than those associated with strict cost savings. It may take some time to achieve financial returns, and if those returns are not achieved, the PI program could be in jeopardy before it has a chance to provide its real benefits.

Often, goals are set around achieving some organizational maturity level by some certain date. This is a two-edged sword. First, it makes the process improvement the focus rather than the outcome of the processes being performed. It also invites the dangerous level-chasing syndrome. This teaching-to-the-test strategy has resulted in companies spending large amounts of resources to get a grade without actually doing the work to improve their processes. Although these companies may be able to fly a Level X banner, they usually don’t perform significantly better than their “less certified” competition.

Our best references for describing the business value of process improvement in the software arena are Don Reifer’s book Making the Software Case¹ and the SEI technical report CMMI Impact Study, by Dennis Goldenson and Diane Gibson.² The impact study is part of an ongoing SEI project to measure ROI for CMMI use, so updates will come out periodically.

1. Reifer, Donald J. Making the Software Business Case: Improvement by the Numbers. (Boston: Addison-Wesley, 2002).

2. Goldenson, Dennis, and Diane Gibson. Demonstrating the Impact and Benefits of CMMI: An Update and Preliminary Results. CMU/SEI-2003-SR-00. (Pittsburgh: Carnegie Mellon University, 2003).

3.6 Advantages And Disadvantages Of Different-Size Improvement Efforts

The activities just described—building and sustaining sponsorship, managing an appraisal life cycle, developing and sustaining process improvement infrastructure, deploying new and improved processes, and developing and measuring realistic goals—provide a nice way of segmenting the cost, effort, and skills required for an improvement effort. It is worth noting that the scale of cost and effort for these different aspects of improvement is influenced by many factors. One factor that is easy to visualize is the size of the organization that is the focus of the improvement effort. Table 3-1 summarizes differences in the challenge for very small settings and for large settings.

Table 3-1: Size-Based Advantages and Disadvantages

3.7 Project Management Issues

Many aspects of managing an improvement effort are related most easily to managing a project. Most of the models that people use to improve their processes include some guidance on managing projects. Project management content is prevalent in these models because many organizations exhibit problems in managing projects. Soooooo … you need to manage your improvement project, but if you were already good at managing projects, you probably wouldn’t need the model to help you. Yup, that’s the crux of the issue and one of the reasons project management made it into this chapter.

We won’t spend many pages elaborating on basic project management practices and processes, for two reasons:

•   There’s probably more good literature available on managing projects than there is for almost any other subject covered in this book. (We include some of our favorites in Part 5.)

•   Each model that you might choose to work with treats project management differently (though there isn’t a huge amount of variation). It makes sense to try out the project management approaches that the model you choose suggests.

What isn’t covered in most of the books about project management is the idea of “above the line/below the line” planning. SuZ’s friend and colleague Chuck Myers uses this concept to explain one of the important nuances in managing an improvement project.

Above-the-line planning is the planning of the tasks that come out of events such as model gap analyses and from suggested practices from a model. These tasks include things such as “Create an estimation procedure for critical attributes of a project” or “Create the appraisal plan for the year for the organization.” Often, these tasks are directly traceable to some element of the model you’re using, and their completion indicates the closing of some gap between your organization’s practices and the practices of the model.

Below-the-line planning is the planning of the more nebulous tasks that go along with things like building sponsorship and helping people adopt the new practices. Some of the tasks in the below-the-line section of the plan include things like “Perform informal communications about CMMI with new staff members” or “Have meetings with all the project leaders once every two weeks to get an idea of where barriers to adoption are showing up.”

Judging completion of these tasks is often the first challenge, because many of them are ongoing and/or recurring. And after you do “complete” one of these tasks, there isn’t necessarily something new that’s been created or something tangible, such as an event, to mark the completion. Often, completion is marked by something like the absence of complaints about some new procedure or improved timeliness of certain process steps being completed.

Which of these types of tasks is more important to plan and manage? The answer depends on which part of your improvement journey you’re on and what kinds of problems you’re encountering or are anticipating. In our opinion, the best solution is to plan and manage both. Forgetting to do either one will result in a lack of progress or slower progress than you want or need.

Of the two types, the above-the-line tasks are the easier to plan and manage, because they have the more tangible, visible outcomes. But trying to manage only above-the-line tasks rarely works. Also, most of the visible schedule slips that occur when you don’t get explicit with below-the-line tasks can be attributed to lack of planning and lack of visibility of related below-the-line tasks.

3.8 Common Pitfalls For Pi Initiatives

Over the years, we have discovered various PI initiative pitfalls—generally by falling into them ourselves or by pulling others out. In this section, we list the ones we’ve seen most often, in the hope that foreknowledge can help you avoid most of them. Most of the techniques we present in the rest of the book address one or more of these pitfalls either directly or indirectly. Although most of the pitfalls aren’t deadly, they certainly can raise your costs, lengthen your schedule, and increase your risk, as well as possibly damage your professional reputation.

Common pitfalls we’ve seen are

•   Trying to do too much too fast

•   Not understanding what it takes for people to be willing and able to adopt new practices

•   Lack of understanding about how to deal with culture change

•   Lack of objectivity in initial gap analysis (common when a self-taught group tries to perform a model-based gap analysis)

•   Underestimating how long or how much it takes to perform the tasks related to a process improvement project

•   Becoming too inwardly focused and forgetting that the ultimate goal is to improve your product and performance for your customers.

•   Having no baseline data to compare progress against

•   Setting goals that are not measurable (remember that measurable can include a binary yes/no)

•   Setting goals that are in no way achievable based on the organization’s current state

•    Measuring things that will lead to a different result from the desired behavior

•   Ignoring the history of previous change attempts within the organization

•   Endorsement by senior management, but no active commitment or engagement

3.9 Summary Of Part I

In this first part of our journey, we have presented some basic information about process improvement in general and about what we see as the primary challenges that any organization faces as it approaches a serious process improvement effort. We’ve also provided some ideas about how some of the challenges of process improvement may play out differently in organizations of different sizes. If you’re ready to move forward, Part II will help you understand some of the many choices you have available to you at the start of your process improvement effort.

Illustration from The Travels of Marco Polo by Witold Gordon (1885–1968)