Chapter 12
Defining Processes

As you might guess, this chapter focuses primarily on the building of process solutions to your organization’s process-related problems. Remember, as Figure 12-1 shows, developing processes is analogous to developing products. We start with a technique to help you choose which processes will be most useful for you to (re)define at any given time and then discuss some techniques that have been successful at getting a set of useful process guidance in a minimal amount of time. Notice, however, that minimal is not “no time.” If these are the processes that your business depends on for producing the products that make the profits that keep everyone employed, it’s a good bet that they are worth careful thought, consideration, and review by those who will be asked to use them.

12.1 Cmmi Business Analysis as a Source of Requirements

The CMMI-based Business Analysis, as described in Chapter 15, is meant to help a group that is contemplating using CMMI to understand how its current business problems might be addressed by various parts of the model and prioritize the many Process Areas the group could start with.

As you have learned up to this point, you have requirements besides just the process requirements to think about in engineering your process solutions. You have time and cost constraints; you have skill and knowledge requirements; and you have communication and sponsorship requirements, to name just a few. All these requirements need to be taken into account when you design process solutions for your organization.

Figure 12-1: Product Versus Process Development Phases

From the perspective of thinking about engineering your process solutions, the CMMI Business Analysis is one way for you to elicit requirements for the processes you want to work on. You’re using your business goals as the customer needs, and your gap analysis against CMMI is helping you narrow those needs down to a set of “product” requirements—that is, which Process Areas are most useful for you to define and improve at this time.

After you’ve used CMMI-based Business Analysis to select the Process Areas you want to use as guidance for your improvement, our next section will help you create process guidance that provides utility to your stakeholders.

12.2 Developing Useful Process Guidance

A critical aspect of supporting a process improvement effort is developing and deploying useful guidance on performing the important processes of the organization. The purpose of process documentation or guidance is to capture how to do something for future reference. This may be for your own use, in case details/agreements you’ve made are forgotten, or it may be for use by someone else who may not have performed that part of the process before. When you capture the expectations for what will happen when common activities are performed, you typically shorten the training time for new people performing the process. You can also use process documentation to capture expectations that will help develop time estimates for activities; if you generally go through the same set of steps to perform an activity, over time you can get a sense of what it takes to nominally perform that activity. Finally, you can use process documentation to compare actual results of an activity to expected results. Through checklists and adding specific instrumentation into process guidance, it is clearer whether an anomalous result is due to the process itself or to some outside influence.

One of the most challenging aspects of this task is figuring out “how much is enough” when it comes to writing this kind of guidance. In working with groups trying to write process guidance, one of the guidelines we suggest is that different kinds of process guidance be written for different roles and different skill levels within the organization. What this means is that one size does not fit all when it comes to guiding people through performing processes. A common mistake we see when looking at process guidance written by organizations that are just starting their improvement effort is that they write very detailed guidance about processes that they know very well, and they write very sparse guidance for processes that they don’t understand very well.^†

† Succumbing to this pitfall makes process consultants look like magicians when we come in, review representative process documents, and (presto!) immediately produce a profile of the organization’s problematic processes.

Some other typical problems in the process guidance we’ve reviewed include

•   Too many different types of guidance (information types) included in one document

•   Inconsistency in the types and levels of guidance that are provided (very detailed in one procedure, followed by something very sketchy in the next)

•   Difficulty in finding the information needed by a particular role in the process

•   Lack of a shared mental model of how the information should be organized

One of the techniques that we’ve found useful in overcoming the first three of these problems is Information Mapping, described in our next section. The fourth—lack of a shared mental model of how information should be organized—relates to the concept of a process architecture. A process architecture is an explicit description of the boundaries of the set of process guidance and how the various processes relate to each other. We describe the basics of establishing a nominal process architecture in Section 15.4.2, when we talk about the “One Hour Process Description Method.”

12.2.1 Information Mapping

A set of useful principles and practices for developing process guidance that solves these and other typical problems comes from a technique called Information Mapping (IM). Information Mapping is essentially an engineering approach to writing that was developed back in the 1950s and has been evolving since then. It uses a structured set of information types and has a set of representation rules that provide a useful set of heuristics for setting up different types of process guidance. There are separate IM guidelines on developing print-based and electronic information. We find that the IM definitions for information types are useful for developing good process guidance, even without using IM representational conventions.

Table 12-1 illustrates the information types and some suggestions for making them easily distinguishable in your writing.

Table 12-1: Information Mapping Information Types ¹

1. Adapted from Developing Procedures Handbook, IMI, Inc., 1993.

Other typical technical-writing concepts (also emphasized in Information Mapping) that are worth paying attention to include

•   Chunking. Visually distinguish related chunks of material so readers can find what they’re interested in.

•   Relevance. Keep together things that are needed to meet the purpose of the document, and use an appropriate representation for each information type.

•   Hierarchy. Break the information into chunks in a way that allows readers to move from general to specific.

•   Labeling. Label the information in a way that tells the reader what to expect.

When you look at the writing process recommended by Information Mapping, you can see parallels between this process and the typical engineering development process:

•   Analyze the audience and its use of the information.

•   Define the types of information needed to meet the audience’s needs.

•   Define the organization of the information to optimize reader navigation, based on the reader’s defined needs.

•   Plan the elicitation of the information for the document from relevant subject-matter experts.

•   Execute the information-elicitation plan.

•   Test the document design with pilots.

•   Complete the document and/or publish it.

The best way to learn about Information Mapping is to take one of the Information Mapping, Inc., courses. (See www.infomap.com for more information.) They are offered all over the United States, as well as outside North America, and come in a variety of formats.

Another approach to structured process guidance that we’ve seen used very successfully is the scripting technique associated with the Team Software Process (TSP). The Addison-Wesley Web site for the Team Software Process books (www.awprofessional.com/title/020147719X) contains examples of process scripts that are used to guide the project management and other team processes supported by TSP implementation.²

2. Humphrey, W. TSP—Coaching Development Teams. (Boston: Addison-Wesley, 2006) and Humphrey, W. TSP—Leading a Development Team. (Boston: Addison-Wesley, 2006).

12.2.2 Process Diagramming Techniques

In a process improvement effort, the elicitation of the information to be put in process guidance is usually done via some kind of process definition activity. Again, there are many approaches to process definition, from very formal graphical constructs (such as IDEF—Integrated DEFinition method) to informal prose documents, and many techniques in between. In our experience, the more formal static definition techniques are useful to process engineers and analysts who understand the formalisms, but they are not typically meaningful for the users of the process guidance—the managers and practitioners who are expected to follow it. An intermediate technique that is easy to support with nominal tools (Microsoft Word tables and Microsoft Visio diagrams) is called “swim lane” diagrams or, more properly, Rummler-Brache diagrams, after the authors who originated the technique.³ The relevant characteristic of a swim-lane diagram is that it provides a row or “lane” for each major role that participates in the process and uses a fairly basic flow-charting technique for identifying the tasks and intermediate work products and decisions that are part of the process. The technique is easy to do with sticky notes and mural paper or flip charts posted together. In a customer pilot of CMMI for small-business settings, this technique was considered to be the most significant new technique that the improvement team learned. Its swim-lane mural became a working document that team members used extensively to communicate about the projects they were working with, and to refine their understanding of the new process expectations. Figure 12-2 is an example swim-lane chart drawn using Visio, a drawing product that has lots of templates for different types of diagrams, including swim lanes.

3. Rummler, Geary A., and Brache, Alan P. Improving Performance: How to Manage the White Space in the Organization Chart. (San Francisco: Jossey Bass Business & Management Series, 1995).

One of the implications of “one size does not fit all” is that you will initially generate multiple versions of the same basic process that reflect how different projects or groups accomplish that process. It’s tempting to move straight to a “standard” process that everyone will follow. That is rarely a successful strategy, for several reasons. First, gathering “the way we do it now” from the different groups that perform a similar process (for example, estimation) gives you a sense of the variation that already exists in the ways that people within your organization communicate about processes and what they think is important to record. Second, defining a standard process without the inputs of the current process could lead you to define something that is infeasible in one or more of the contexts that your organization works in. And third, when you develop a process without reference to the processes that are already being performed within the organization, you’re really increasing the chance that the new process will be seen as a foreign element, rather than just as an improvement on what’s already happening.

Figure 12-2: Example Swim Lane Diagram

Even when you get to the point of synthesizing a standard process for your organization, you will find that you really need a set of standard processes. In most organizations of any size, there are sufficient differences in the context in which the process is performed that having multiple processes to start from is usually beneficial. First, the more the standard process looks like the one the group or project is accustomed to using, the more likely it is to be accepted. Second, having a few standard processes that have to be tailored (adapted) minimally for each use gives you better data for measuring process performance than having one standard process that has to be tailored extensively each time.

As you can see from the preceding discussion, there are many things to consider when developing useful process guidance. In general, stay as simple as you can, and always keep in mind that the practitioner or manager is the end user of the guidance, not the improvement consultant or the process improvement team. You will probably need to learn some new ways of writing that will be awkward at first, but they will get easier with time. Techniques like swim-lane diagrams and Information Mapping can help, but don’t expect this to be a simple task. One common mistake we’ve seen is for an organization to download a Web site full of process documents written for some other organization and try to use them with minimal adaptation. The language, jargon, and approach are usually just the beginning of the problems. And after the organization figures out that it needs to seriously rewrite the material it has purchased or gotten free, it wonders whether starting with its own, even poorly written documentation would have been easier. In Chapter 15, we describe the one-hour process description method—our favorite method for eliciting the process information that will eventually become useful process guidance.

12.3 Collecting/Incorporating Lessons Learned from Improvement Activities

There are many ways to learn from your improvement activities. You can learn from both successes and failures. In both cases, learning can occur only if you reflect on what you have experienced and integrate that understanding back into your approaches and methods. Sadly, by the time we’ve finished an improvement activity, the team usually has very little energy left for the reflection and integration activities that lead to the deepest learnings. This is especially true in the smaller settings, where there are so many competing demands for mind-share that taking the time out for lessons-learned activities ends up at the bottom of the to-do list.

A very simple technique for collecting lessons learned as you go is to use a small amount of meeting time to perform in-process evaluations. Ask participants to think about the event they’re involved in right now and to answer two questions:

1.  If we were to do this again, what would you want to keep from the approaches and techniques we’ve used?

2.  If we were to do this again, what would you want to change in terms of the approaches and techniques we’ve used?

We usually collect these on—you guessed it—sticky notes and post them on two flip charts; one says “keep,” and the other says “change.”

After the meeting, transcribe the items into a spreadsheet or other document, along with an identifier as to what phase the project was in when you collected the data. At the end of the pilot or project, ask the team members to review the list and suggest any changes that they would like to make. The reason for this is that sometimes in the middle of a process/method, you realize there are additional activities or information required to obtain the intended benefit from the technique. Most people find the “review the list” activity much easier to do than generating a list for the entire project time span.

We also use this basic approach for gathering evaluation data for workshops, courses, and other events, and generally get consistently useful information from participants.

Another layer to add to this approach is to have a specific area in your process asset library (PAL) for lessons learned. An interesting and fruitful activity for your improvement staff to do is to look across a cross-section of events to see whether there are common threads in the keep/change lists. This could be one of the inputs to a causal analysis activity, if warranted.