Chapter 13
Deploying Improved Processes
In this chapter, we discuss the challenging task of deploying the processes that you have defined or evolved. There are many different aspects to deployment, but most have to do with people. You will most likely face staffing issues, the necessity of using outside resources, and the critical need to convince practitioners that the new process is in fact better than their current one.
When you’re ready to try a new or improved process, except in the smallest of settings, it’s usually a good idea to pilot the new process on one project before deploying it to its intended scope. In some cases, it may even be worth doing multiple pilots.
13.1 Finding/Selecting Pilots for Cmmi Implementation
CMMI content related to this topic: |
• Organizational Innovation and Deployment • Risk Management |
There are many advantages and few disadvantages to using pilots in your improvement effort. This is actually one of the explicit practices in the Organization Innovation and Deployment process area:
Pilot process and technology improvements to select which ones to implement.1
1. Chrissis, Mary Beth, et. al. CMMI: Guidelines for Process Integration and Product Improvement. 2d ed. (Boston: Addison-Wesley, 2006). All references to CMMI components in this chapter are from this source.
When thinking about pilots, we classify them into two categories: technical feasibility pilots and adoptability pilots.
Technical feasibility pilots are useful if you are uncertain as to the soundness of the new process that you’ve developed. For this type of pilot, you want a project that is probably not on your organization’s critical path, and preferably one that contains people who would be considered innovators or early adopters (see the next section on adopter analysis for an explanation of these classifications). Essentially, technical feasibility pilots’ determine the technical feasibility of the new process. Adoptability pilots, on the other hand, are done when you’re confident of the soundness of the new process, but you’re not sure whether the things you’ve developed to support it—checklists, training, procedures—will work well with your mainstream organizational population. In this case, you’re generally looking for a project that contains people who are representative of the general population that you intend to deploy the new process to. They may not be the people who are the fastest to take up a new technology. For an adoptability pilot, you don’t really want the innovators; you want the pragmatists, who have to have a reason to try something new. If the adoptability pilot works with them, chances are that the support products you’ve built will work with the rest of your organization.
13.1.1 Understanding your Adoption Population: Adopter Analysis
Adopter analysis is a technique that comes from technology adoption. The idea is that individuals have some predisposition toward adopting a new technology or set of practices based on lots of different factors. The factors themselves aren’t that important, because most of the time, if you describe the “thing” to be adopted and the characteristics of several preformulated adoption categories, most people can tell you where they would fit in relation to whatever technology/practice you want them to adopt.
The categories come from Everett Rogers’s work on technology adoption2 but are actually easier to understand based on their popularization in Geoffrey Moore’s book Crossing the Chasm.3
2. Rogers, Everett. Diffusion of Innovations. (New York: The Free Press, 1995).
3. Moore, Geoffrey. Crossing the Chasm: Marketing and Selling Technology Products to Mainstream Customers. (New York: Harper Business, 1991).
Table 13-1 gives brief descriptions of the adopter categories used by Rogers and Moore.
Table 13-1: Rogers/Moore Adopter Categories and Characteristics
Adopter analysis is something you can do to identify individuals or groups that will be helpful to you with different aspects of the improvement task. Innovators and Early Adopters are likely to volunteer for your process improvement teams in areas that affect them. However, they will probably be satisfied with a partial solution that will not satisfy other adopter types. So for an adoption feasibility pilot, you probably want to find some Early Majority participants. If you want to know what kind of transition mechanisms (things that help with the communication or implementation of the new practices) need to be built over the longer term, you would want to talk with some Late Majority or Laggard types.
One of the things to note about different adopter types is that they typically move through change cycles (for example, the Satir cycle we discussed earlier) at different speeds, so you may run into a situation where some of the people in a group are enthusiastically embracing a new set of practices and others are clearly dragging their feet.
Adopter type is not the only characteristic that is useful to you in choosing people to participate in different aspects of the improvement effort. Another thing to look at is where they fit in your value network, one of the topics covered later in this chapter.
13.1.2 Staffing your First Improvement Pilot
Our recommendation for your first improvement project is to first find the people who have some passion around making improvements in the organization, then put them to work doing improvement activities within their projects. This will require some oversight so that appropriate resources are expended, and so on. But again, that doesn’t have to be the entire management team; it could just be one senior manager who has a stake in the improvement effort. It’s especially useful if that person has successful experience with improvement projects.
And yes, what you’re doing is really a project. It probably delivers a different kind of product from the other projects in your organization, depending on your business domain. A process improvement project delivers
• a set of assets upon which to base new practices;
• the experience of using those assets by the pilot project that develops them;
• experience and skill-building to enable further improvement projects.
One of the Catch-22s of process improvement is that project management skills and practices are among the things you’ll need to use first and effectively for the improvement activities to be successful, but that’s probably one of the areas of organizational weakness that led you to model-based improvement to begin with! We have witnessed the dawning of this conundrum countless times, and our answer is generally twofold:
• There are probably people in the organization who are good at project management, they just haven’t had a chance to use those skills in your environment. Find and recruit them!
• This conundrum gives your first improvement team a chance to get into the details of the chosen model, because their first use of the model, for almost all the models you would think about using, can be to apply project management practices to their own improvement project!
Depending on the skills/abilities of the staff you have available internally, you may want to consider a process improvement consultant familiar with the model you’re using to help get you started. If you want someone to follow the kinds of principles and practices we’re writing about here, you may actually have to do a little more work on your own to get them to understand your requirements for the project, because some of them will want to spend their initial time with you working on infrastructure, training, and appraisal rather than getting improvement projects started off quickly. And in truth, for some of the larger organizations we have worked with, this was exactly the right approach. In those kinds of organizations, the process deployment task was very large (often involving hundreds, if not thousands, of people) and having a bunch of little improvement efforts going on all over the place proved too chaotic. The lack of an infrastructure to bring their results together and provide unified training for the staff was sub-optimal at best.
To give you an example, the consulting provided for using CMMI in a small company in Huntsville, Alabama, was about four days of training/miniappraisal effort, followed by one day of on-site consulting per month, and less than one day of offsite work per month until the company started preparing for a SCAMPI A appraisal. At that point, the effort increased a bit. This was a company, however, that already had been registered with ISO 9000, and it already had some of the infrastructure we talk about in Chapter 11 in place. So, just like with automobiles, your mileage may (and probably will) vary. Also, we were working with only three projects and three Process Areas, so the scope of this effort in comparison to yours may be a good bit smaller. If you want more information on how this project was accomplished, go to www.sei.cmu.edu/ttp/publications/toolkit, and you can look at the description of the whole process, as well as download the materials we used. Some of them are included in this book as well, and there are some things we’ve added to the book that were not done with this pilot. (We try to learn from our experiences, too.)
13.2 Working With Consultants
CMMI content related to this topic: |
• Supplier Agreement Management • Integrated Project Management • Organizational Training |
Chances are that sooner or later in your process improvement journey you’ll hire one or more process improvement consultants to help you with your process implementation. The guidance in the Supplier Agreement Management Process Area is good advice when selecting and managing the relationship with your consultant(s). As in any field, there are many competent consultants to choose among, and many of the differences come down to personal style or preference, and experience working in a particular context or domain. A few things to ask your candidates to help get a better fit might be:
• Are you a member of the SEI Partner Network? These are individuals who are authorized to deliver authentic SEI services. Depending on their authorization, they may be able to provide SCAMPI lead appraiser/team leader services and/or Introduction to CMMI training, as well as other process improvement–related technologies.
• What is your experience working in our business domain? Ask for customer references that you can contact and then follow through by contacting the references provided.
• What is your experience working with organizations of our size? Have you worked with organizations focusing mostly on services or product development?
• What is your experience working with organizations targeting the profile we’re hoping to achieve in terms of capability and/or maturity?
• What is your experience getting an improvement program started with our resource profile (if that’s the stage where you are in your improvement)?
• What is your experience solving x kinds of problems? X could be anything from leadership problems to configuration management library problems and everything in between.
Some consultants specialize in teaching topics related to process improvement, others specialize in running workshop events, and still others specialize in providing hands-on daily help for your effort. Obviously, these different modes of interacting with the consultant will cost different amounts of money and various amounts of effort on your part.
The SEI uses a model for thinking about how you want or need to interact with a consultant based on a consulting grid that differentiates responsibility for project results from responsibility for client growth. The roles that are defined in the nine blocks of the grid reflect different levels of intervention that would be expected from the consultant. Figures 13-1 and 13-2 illustrate the degrees of intervention and briefly describe the roles for each block of the grid. SuZ regularly uses this grid with collaborators and pilot sites to clarify what’s expected in the working relationship, not just what is expected in terms of the deliverables of the collaboration. This grid is discussed in the SEI’s Mastering Process Improvement course.
Figure 13-1: Consulting Role Grid
Figure 13-2: Sample Role Statements
13.3 Deploying Practices to the Targeted Organizational Scope
Having determined the target projects and arranged for the appropriate help, now you need to actually deploy the changes. This is the point where many of the psychological aspects of process improvement show up. In the next sections, we present several tools to enable more effective and efficient deployments.
13.3.1 Dealing with People Issues Involved in Managing Change: The Satir Change Model and Beyond
In Chapter 8, when we were talking about building and sustaining sponsorship, we introduced the Satir Change Model. We provided some ideas on how paying attention to that cycle could help sponsors understand why the members of their organization are at a different place than they are (in terms of readiness to adopt) with regard to process improvement. In this section, we’ll go a little further with the Satir model as a way to help the facilitators of the improvement effort work more effectively with those who are being asked to change.
Figure 13-3 shows a more detailed view of the Satir change cycle, highlighting some of the different things you’ll see in organizations as they successfully and unsuccessfully navigate it.
When you look at the kinds of things going on in the Chaos block of Figure 13-3, you start to understand why performance during the Chaos period can be so variable. When energy in the organization is spent trying to deny the existence of the foreign element or is spent trying to make it go away, there won’t be a lot of energy left for executing the primary tasks of the organization. And when a Transforming Idea is found, integrating it into the personal and work group’s practices requires energy, as does practicing the new way of doing things until people become as skilled at it as they were with the old (attain Alistair Cockburn’s fluency stage). Another thing to note in this diagram is that if a significant amount of time goes by after a change has been successfully integrated, the New Status Quo will become the Old Status Quo, and making changes to that set of practices will involve some of the same struggles as the first time you changed the practices.
Figure 13-3: Flow Chart of Satir Change Model
One of the main functions of a process improvement group is to help the parts of the organization going through change successfully navigate both the Chaos and Integration & Practice stages of the Satir model.
Figure 13-4 shows graphically some of the things you’re likely to observe in a group going through chaos in an improvement effort that affects it. One of the things you almost immediately see is that old feedback mechanisms—measurements, reports, meetings, and so on—are changed, making it difficult for the group members to know the “who, what, when, and where” associated with reporting information. They need to provide information back to management on how the new process is going, as well as whatever information is called for by the new process. This often leads to wild-looking performance and a desire by the group members to find some kind of stability. This is, in essence, the search for a Transforming Idea. However, not all the choices for stability are good, and this is another reason you see performance fluctuations in this stage. When stability is sought from inappropriate sources (OK, maybe the “tea-leaf readers” choice is a little extreme), you’ll end up farther away from a Transforming Idea, not closer to one.
Figure 13-4: What Chaos is Like
So how do you help the people in your organization get through their chaos? Jerry Weinberg (in QSM volume 4, Anticipating Change) has some ideas of what’s needed as well as what’s not needed during this stage.4
4. Weinberg, Gerald. Quality Software Management Volume 4: Anticipating Change. (New York: Dorset House Publishing, 1997).
What’s needed:
• Consistent, compassionate offers of reliable information
• Active listening (an oldie, but a goodie!)
• Empathy
What’s not needed:
• Brutal versions of the facts that will destroy confidence
• Feel-better placating that will provide an excuse to stay in denial
• Actions that allow a temporary return to the old status quo (thus encouraging the hope that the foreign element can be successfully rejected)
When you’re involved in this type of communication, another model from Satir—her Communication model—is also useful. It is covered pretty comprehensively in Weinberg’s QSM volume 3, Congruent Action, 5 as well as his Secrets of Consulting.6 And if you find personality typing a useful way of analyzing your communications with others, many in the process improvement field find the Myers-Briggs Type Indicator (MBTI) to be a very useful way of helping groups understand some of the issues they are dealing with as they go through improvement activities.7 MBTI can be particularly useful to a process improvement team that comprises diverse roles from across the organization. There is a whole community of certified MBTI practitioners; if you’re going to get involved with using MBTI, it shouldn’t be too difficult to find one in your region and business domain. There are also several books that deal specifically with using MBTI in a work setting, such as Type Talk at Work.8 Another reference that is particularly useful for people within the software industry is Tom DeMarco and Tim Lister’s Peopleware.9
5. Weinberg, Gerald. Quality Software Management Volume 3: Congruent Action. (New York: Dorset House, 1994).
6. Weinberg, Gerald. Secrets of Consulting: A Guide to Giving and Getting Advice Successfully. (New York: Dorset House, 1985).
7. Keirsey, David. Please Understand Me II: Temperament, Character, Intelligence. (Del Mar, Calif.: Prometheus Nemesis Books, 1998).
8. Kroeger, Otto, et al. Type Talk at Work (Revised): How the 16 Personality Types Determine Your Success on the Job. (New York: Random House, 2002).
9. DeMarco, Tom, and Timothy Lister. Peopleware: Productive Projects and Teams. 2d ed. (New York: Dorset House, 1999).
13.3.2 Using Technology Adoption Approaches Effectively
Technology adoption research can be easily and profitably applied to process deployment. Processes are similar to new technology in that they often represent change; they have associated knowledge transfer (for example, training); and they impact the way people accomplish their work and interact with co-workers. In addition to those we’ve already introduced, this section highlights some ways we’ve seen technology adoption approaches applied successfully to process improvement.
Among the first things to think about when deploying a new process or tool are the people you are asking to use it and any pertinent characteristics of the way that group tends to approach change. We discussed one aspect of analyzing the “who” when we talked about adopter analysis earlier in this chapter. Now we’ll talk about another powerful technique: value networks.
13.3.3 Value Networks
One way of deciding who needs to be enlisted, and in what time frame, is to construct a value network. The idea of a value network is to determine who (in terms of role and, where feasible, defined individuals and groups) needs something from you—a value you provide to them—and who you need things from—a value they provide to you. For example, as the process improvement group, you need money and access to labor resources from other departments and from your management sponsors. They need progress against PI infrastructure and deployment goals from you, as well as status reporting of the overall improvement effort from you.
Value networks were developed at the SEI, primarily by Eileen Forrester, as part of a technique called TransPlant. Their original use was to help technology developers identify what kinds of actions need to be taken with which groups to enable faster uptake of a technology within its intended community. The technique also works where you’re trying to identify the players in adopting a particular technology or set of practices that you’re deploying.
You start a value network by putting your improvement group in the middle of a diagram and identifying nodes in the network that represent different stakeholder groups. Then you identify what value is exchanged among the different nodes. In CMMI-based improvement, some of the nodes might be:
• Pilot projects
• Project managers
• Senior managers
• PI steering group
• External customers
• External consultants
• Training/education group
• SEI
When you think of the kinds of value that could be exchanged between the PI group and these stakeholders, or among the nodes themselves, you might think about:
• Resources
• Special skills
• Project measurements
• Lessons learned
• Process assets
• Process appraisal results
Figure 13-5 shows the beginnings of a value network for a group transitioning to CMMI from another model. When a value network starts to become complex, you can move to a table form to make it easier to capture the information, especially if you have particular nodes within a particular stake-holder group that will have different value exchanges from the main category.
When you’ve developed a value network, you can start analyzing it in many ways, asking questions like
• What nodes do you have the capability of serving now?
• What is the priority for serving the nodes you’re not capable of serving now?
Figure 13-5: Beginnings of a CMMI Value Network
• What is needed for you to be able to serve the priority nodes?
• Are there adopter type similarities that you can leverage among different nodes?
Look for future publications from the SEI on this technique as it gets used in a broader array of contexts.
13.3.4 Developing/Obtaining Appropriate Transition Mechanisms
At various points in your improvement activities, you will need to figure out what kinds of support people in different groups are likely to need to accelerate their adoption of the new practices. The model we use to help understand what kinds of things need to be created/deployed is called the Adoption Commitment Curve.10 The version of this model that the SEI uses (Figure 13-6) is slightly different from the original but captures the resource commitments a little more realistically, based on our experience.
10. Patterson, R., and D. Conner. “Building Commitment to Organizational Change.” In Training & Development Journal 36:4, pp. 18–30.
The idea of the Adoption Commitment Curve is that each individual or group moves through a series of learning stages while navigating a change.
Figure 13-6: Adoption Commitment Curve
You can relate this curve back to the Satir model as well. The first three stages of this curve—Contact, Awareness, and Understanding—reflect the recognition of a foreign element and some of the Chaos stage that goes along with trying to understand the new process/technology to get to the Transforming Idea. Trial Use and Adoption reflect the stage of Integration and Practice, where you’re actually using the new practices and finding ways to make them stick. Institutionalization is putting the final mechanisms in place to get to the New Status Quo. And Internalization is akin to moving over time to the Old Status Quo.
Figure 13-7: Satir Model Plus Adoption Commitment Curve
13.4 Communication
How you communicate with the stakeholders in a process improvement initiative is crucial. Everyone needs to at least know what chapter you’re reading, even if they’re not quite on the very same page. At a minimum, the implementation team should develop some approach for figuring “who needs to know what.” Often, it helps to specifically identify the communications that are critical to success in your organization. Table 13-2 shows an example of a communication plan in a simple, tabular form. The headers in the table are
• Objective—the purpose the communication is meant to achieve
• Responsibility to Report Information—who needs to make sure it gets communicated
• Member(s) Receiving Information—who needs to get it
• Receiving Information Mechanism—what the communication event/ artifact is called
• Medium Used—how the material should be transmitted
• Frequency—how often this kind of communication should occur
13.4.1 Lessons from Agile Methods
One of the best discussions on how humans communicate in work environments is found in an unlikely place. The first chapters of Alistair Cockburn’s Agile Software Development 11 focus entirely on this subject. His insights, based on keen observation of technical activities in several countries, are just as applicable to process improvement as they are to software development. Here’s a summary of what he (and other agile proponents) have learned.
11. Cockburn, Alistair. Agile Software Development. (Boston: Addison-Wesley, 2002).
People parse complex experiences in very different ways.
In general, we all perceive information in somewhat different orders. We “parse” it—that is, break it into little pieces—and then reconstruct it according to the patterns we recognize. The best example for the truth of this statement is the graphic tests of perception often used in communications courses. The two most prevalent are a cup-versus-vase picture and a young woman-versus-crone picture. Depending on how you parse images—usually light to dark or vice versa, but sometimes according to your mood—you see one or the other. It takes an effort of will to see the second image, because your mind holds on to the first patterns you detect. Alistair indicates that listening to how people tell a story about their work will often give you clues as to how they parse information.
Table 13-2: Example Communications Table
Understanding includes internal information restructuring and shared experience.
Another way we understand is by developing models of what we’re hearing that are constantly updated as more facts or descriptions are gathered. Have you ever found yourself interrupting someone to finish their sentence for them? If so, you should recognize that you have used your inner model to structure the information you heard and extrapolated the complete information from the fragments received. (Rich often inflicts this rather bad habit on his wife, Jo, usually missing her point completely.) Communication of any idea requires such internal restructuring and often leads to erroneous understanding, because we all build these internal models differently.
A corollary to this is communication based on shared experiences. Families and others in long-time relationships nearly always develop private languages of words, gestures, or expressions. Their use is incomprehensible to those outside the family, because they are usually shorthand for a long set of shared memories. An example of this in Rich’s family is listening for a rhythm in some phrase that matches the first phrase of “Fascinating Rhythm.” (You younger folks may need to look up this Gershwin tune and have a listen to appreciate this example.) The memory is based on going to the circus and the kids becoming hysterical when Jo noted that she could sing the animal trainer’s name to the music that was playing (Gun-ther Ge-ble-Wil-liams). Twenty years later, “the fam” can still lapse into paroxysms of laughter when someone happens to recognize a matching rhythm. (For example, di-ver-ti-cu-li-tis resulted in our almost being asked to leave a quiet restaurant; it goes without saying that “asked to leave” is another long family story.)
So our communication with team members and stakeholders can either use or abuse these principles. They can draw a team together if you can find a shared experience but can also leave folks feeling that they are on the outside looking in if they are not “clued in” to the context.
You can never really know what you are experiencing, and you can’t ever communicate it.
Although this sounds like an existential exercise, it is extremely important when working with all the diverse people and roles in process improvement initiatives. We understand what we hear or read based on the experiences and training we have received and our particular purpose at the time. In the same way, when we try to describe knowledge to others, we draw our language and thought constructions from the same reference sources. Because these references are essentially unique to us and vary with the task and thought priorities at hand, communication is always incomplete and misinterpreted.
The three stages of learning behavior—following, detaching, and fluent—are critical in communicating.
There are three stages that describe how comfortable or understanding people are with concepts and procedures. These would reflect “individual learning” in the learning model we talked about in Chapter 2. People in the first stage, following, are ready to hear about one thing that works. In the second phase, detaching, people parse an idea and look for places where it doesn’t hold true or can’t work. When they are fluent, people generally can’t recognize that they are following any particular process at all, because they understand the desired end effect and move toward it based on their integration of experience using several different techniques.
This is important to understand when teaching people about process improvement or training them in processes. Following-stage people, for example, will not be interested in how many variations of a particular process there are; they want to understand one way that works and will become frustrated with too many options. People in the detaching phase can make very good quality-control people for your evolving process assets. If the majority of the team is already at the fluent stage, minimal process guidance can keep them aligned.
13.4.2 Communication and Implementation Support Mechanisms
Although you can see that the Satir Change Model and the Adoption Commitment Curve are complementary, one of the particular things we use the Adoption Commitment curve for is to plan the transition mechanisms that need to be created to help people of different adopter types navigate an adoption process. Transition mechanisms are events or job aids that are usually meant to support either communication activities or implementation activities.
Communication mechanisms are transition mechanisms focused on improving understanding of the new practices/technology. They primarily serve to help move you from Contact through Understanding. Implementation mechanisms are transition mechanisms focused on actually assisting you in the implementation of the practices. They are used primarily for Trial Use, Adoption, and Institutionalization. Table 13-3, adapted from many sources by Eileen Forrester, shows typical Communication and Implementation support transition mechanisms for CMMI adoption.
Table 13-3: Typical Transition Mechanisms Categorized by Adoption Commitment Curve Category12
12. Forrester, Eileen. Omaha SPIN Meeting Tutorial, 2003.
One thing Table 13-3 can help you with is timing your development of process guidance and other work products that need to be developed or acquired. As you look through each stage and determine which of the types of mechanisms would work in your organization, you will start to see what kind of lead time you need before each activity (for example, start a pilot with Early Majority types of adopters). In many cases, your Innovators and Early Adopters will be willing to co-develop transition mechanisms with you. However, be aware that one characteristic of Early Adopters and Innovators is that they typically don’t need the same kinds of communication and implementation support mechanisms that Early Majority and later adopter types do. One further warning: Don’t try to use/develop all of the possible mechanisms. These are representative of several different organizations; you need to choose a subset and think about what other kinds of things work well in your environment.
When you’ve built a few transition mechanisms, it’s time to take the “what” to the “who.” Remember all those transition mechanisms that you started thinking about when planning your deployment? We hope you’ve been spending at least some of your time developing the job aids, training, and other communication and implementation support mechanisms that will be used by those slated to adopt your new processes.
The most popular transition mechanism, based on the people we talk to, is still training. We’ve seen both wonderful and abysmal training events, and one thing that almost always distinguishes the really good training events we’ve participated in or observed is that they are tuned to the roles of the people who are using the training to perform their jobs. This is not as important for Contact or Awareness types of training as it is for training meant to get adopters through the Understanding phase.
One of the fundamental tasks for an adopter in moving through the Understanding phase is to make the connection between the technology and work/activities. Anything your training can do to support making that connection is appreciated by potential adopters, and often this is one of the things that can make a huge difference in the success of your process adoption effort. SuZ and Shawn Presson’s tutorial, “Beyond Death by Slides,” introducess many techniques related to this.13
13. Garcia, S. and Presson, S. “Beyond Death by Slides,” tutorial, SEPG Conference 2004 (Pittsburgh, Carnegie Mellon University, 2004).