Chapter 11
Developing Process Improvement Infrastructure

At some point in your process improvement effort, although probably not at the beginning, you will want to have some stable infrastructure for this effort, just like you would for any other continuing operation. When you’re ready to approach this, you need to engage in several tasks to ensure you create a sustainable infrastructure.

First of all, you need to find people willing to work on process improvement tasks, and form one or more teams to execute the tasks that we’re laying out in this chapter.

Then you need to decide how to organize the people performing improvement tasks. In CMMI circles, you’ll most often hear this talked about as forming an EPG (Engineering Process Group). However, there are many ways to organize for improvement, and a permanent structure may not be where you start.

Depending on the type of structure you implement, you’ll need infrastructure—budget, support resources, space, and so on—to support it.

The bulk of the work done at first will be around defining project and organizational processes—we cover these in the next chapter. But there will be other things that your improvement teams will also have to deal with. For example, figuring out how/where to securely store measurement data.

Defining new/revised processes does the organization no good unless you actually deploy/implement them into the projects of the organization. This takes you out of the infrastructure realm into the “real world.” These tasks are covered in Chapter 13.

The last task we’ll talk about is collecting and incorporating lessons learned—from building/sustaining sponsorship, building/sustaining infrastructure, and deploying improved processes—back into the practices and assets of the organization.

When you look at the set of things needed just in the infrastructure tasks, you can understand why many organizations create a permanent group to coordinate and facilitate these activities. But if you’re just starting out, your team may be you and a couple of other members of your project; your infrastructure may be an agenda item on project review meetings and an action-item list, along with a shared Web space where you keep PI work products. And the “lessons learned” activities may be the project retrospective and pizza lunches once a month that actually (sometimes?) result in some notes.

SuZ once worked in an organization where most of the improvement work was done on Friday afternoons. The company had a policy that staff were not to work on their daily tasks on Friday afternoon; that time was dedicated to learning something new or working on some kind of organizational improvement task. There was no “formal” improvement infrastructure beyond this and a staff member who had an assigned quality assurance role. With only ten development staff, this “infrastructure” generally worked well.

11.1 Developing and Sustaining Process Improvement Team Members

As you’ve probably already discovered if you’re new to process improvement, the skills and tasks needed to be successful in process improvement are not entirely the same as those needed for traditional engineering. Unfortunately, that is the home ground for many of the people working in process improvement. So it’s natural that investment in training and mechanisms to help people adjust to their role will be needed.

What types of skills will be needed? A good place to look is the “O” process areas of CMMI. You’ll need people who can implement the practices in Organizational Process Focus, Organizational Process Definition, Organizational Training, Organizational Innovation and Deployment, and (eventually) Organizational Process Performance. You’ll certainly need people with project management and project support skills, because you will be implementing improvement projects. You’ll also need access to specialists in several different aspects of product engineering and organizational support.

If you don’t already have access to staff with the requisite skills, you’ll need to find people willing to acquire them. You can look at this book as a primer on some of the skills/techniques you’ll need to have mastered; lots of training courses offered by SEI partners and others will address the skills that you need. One of the questions we frequently get asked is “How do I choose training and trainers that will be right for my situation?” That’s a more complicated question to answer now than before CMMI, because the widespread adoption of CMMI has led to an explosion of consultants and trainers offering services.

There are two things we would recommend when searching for training services:

•  Take advantage of the SEI Partner Network, presuming that you’re using CMMI as your base model. The members of the Partner Network have gone through extensive training in the model and its application in appraisal to achieve authorization as either an Introduction to CMMI trainer or a SCAMPI Lead Appraiser. They are authorized to deliver authentic SEI services, and part of their authorization requires that they stay current with advances in the model and in the improvement arena in general. The SEI maintains a Web site with lists of the individuals and companies that are partners. In the absence of other preferences, find several that operate in your region, and check their Web sites to get a feel for them.

•  When you’ve found several candidates to think about, we recommend going to both the SEIR (Software Engineering Information Repository) and the NDIA (National Defense Industrial Association) Events Web site (www.ndia.org) to find presentations or tutorials that your candidates may have offered. The SEIR collects many of the presentations from the System/Software Engineering Process Group conference. The NDIA sponsors a CMMI Technology and User’s conference annually, and publish its proceedings for free on the Events section of their Web site. Reviewing presentations gives you a better idea of the philosophy and approach of different trainers/consultants. Keep in mind, however, that not all trainers/consultants will present every year, and we certainly wouldn’t recommend hiring someone just from his or her presentation materials. But it is a way to start if you don’t have recommendations from people in other organizations whom you trust.

Developing and acquiring the skills is part of the task. The other part is forming the groups that will be working together into effective teams. In the next section, we’ll discuss our favorite team life cycle management model. CMMI doesn’t specify any particular team model, but in IPM it does call for the creation and sustainment of teams that implement an integrated project’s plans and provides a basic set of practices that we would expect to see supported in any team life cycle model.

11.2 Developing a Team

There are many contexts within an improvement effort where working together as a team is both necessary and beneficial. Generally, the people who are facilitating the improvement effort will be an explicit team of full-time people permanent in that role while others may be part time and temporary. Those working on a specific improvement issue will be working together as a team. Hopefully the management sponsors of the improvement effort will also be working as a team.

So team development and sustainment is a critical knowledge-and-skill area for your toolkit. As with most of the techniques we describe, there are multiple choices for the approach you take to team development. The two we’ve worked the most with are the Joiner and Associates high-performance team approach¹ and the Drexler-Sibbett Team Performance Model.^† We’ll give a brief overview of the Drexler-Sibbett model because, in our experience, it has the richest set of support tools and is both the most explanatory and most diagnostic of the approaches we’ve used. Table 11-1 shows the stages of the Drexler-Sibbett model and the key questions that are answered at each stage of the model.

1. Scholtes, Peter R. The Team Handbook: How to Use Teams to Improve Quality. (Madison, Wis.: Joiner and Associates, 1988).

† Team Performanc Model is a trademark of Grove Consultants International.

The model is supported by a set of books and tools that are all available from Grove, the publisher of the model, at www.grove.com. We consider this model useful for both planning team engagements and for diagnosing team issues. In addition to providing a description of the model, Grove provides diagnostic aids that describe symptoms you may see if particular stages of the model are not successfully traversed and suggest activities/approaches for solving them. Although Grove also offers training, should you need it, it is also a useful resource for trained team facilitators, because most of the knowledge needed to effectively use its models are captured in a set of guidebooks and job aids available directly from the Web site at a reasonable price.

In Table 11-1, we provide a short overview of the stages and what we think each stage contributes to team performance. If you look at it, one thing you may notice is that the “work” of the team—what are we doing, and how will we do it—is not the first thing the model deals with. We think that this is one of its strengths. When overlooked, understanding why you’re here as an individual and the level of trust needed and available to perform the task of the team often causes problems when figuring out team operations. That’s not to say that you have to spend tons of time in each of these stages. We often work with groups that complete Stages 1 and 2 within the first hour of a one-day planning session and spend most of their time on Stages 3 and 4. If the task is small enough, they might even work some of Stage 5.

Table 11-1: Drexler-Sibbett Team Performance Model Summary²

2. Adapted from Grove Team Leader’s Guide, www.grove.com. Accessed July 2006.

The main book we use from the Grove Web site, the Team Leader’s Guide, contains detailed descriptions of the types of tasks to include in each phase, as well as symptoms and solutions for problems. The guide also address the different needs of different types of teams. The senior leadership team, which is a team that persists over a long period of time, probably needs different kinds of support than a process improvement task force chartered to solve a specific problem in the course of one or two months). One of the SEI courses in process improvement, Mastering Process Improvement, explores the Team Performance Model in its activities. There are also members of the SEI Partner Network who include the Team Performance Model in their training/consulting.

11.3 Establishing Improvement Infrastructure to Support and Sustain CMMI Implementation

This is the set of tasks that will see the most variation, depending on (1) the size of your organization and improvement effort and (2) where you are in terms of your commitment to CMMI (or other reference models). Most of the topics discussed here won’t be ones you’ll address fully until you have committed to your improvement approach and are ready to build a sustainable infrastructure suitable for your size and context. We cover choices for both larger and smaller organizations in the discussions that follow.

11.4 Staffing and Organization

One of the reasons we call DLI a “light” life cycle is that we try to minimize the staffing requirements for process improvement, at least while you’re trying it for the first time. One of our experiences in working with organizations is that they decide to do process improvement and then spend six months to a year (sometimes even more!) putting together a process improvement group and a management steering group to provide oversight. During that time, the improvement group is usually doing useful things in terms of building your improvement infrastructure, but they’re not solving any of the immediate problems of the organization—those things that led you to decide to work on improvement to begin with. This can create a serious problem with sponsorship and with the members of the organization to whom you’re intending to deploy new practices.

When you’ve decided to commit to a long-term improvement effort, you will need to staff some kind of ongoing group within your organization to perform the kinds of tasks you saw in Table 4-2, The Task/CMMI Cross Reference, which relates process improvement tasks to CMMI. There are many approaches for doing this. We’ll cover and comment on a few of the common ones that we’ve worked with.

11.4.1 No Ongoing Improvement Team Infrastructure

Yup, we’ve seen this one. It can work for a while. How long is “a while”? This staffing model breaks down when you want to start leveraging the process assets you’ve developed and are successfully using in some projects by deploying them into your new projects. The projects that have participated in improvement activities get benefit from them, but the other projects don’t. If your company is very small, with only a couple of projects, this could work for quite a while. The small company SuZ worked for in the ‘90s managed with this model for almost two years, although both the CEO and SuZ were expert enough in improvement to be able to provide some guidance on a very limited effort basis.

11.4.2 Single Focal Point for Improvement, Others Part Time, Designated Senior-Management Sponsor

This is the model that is common for many small to medium-size enterprises. When a commitment to ongoing improvement is made, one staff member is assigned at least half time, if not full time, to this effort. That person organizes the infrastructure and the improvement projects with part-time staff and possibly external consultants for specialty tasks, such as appraisals.

This model works best if you can hire someone into this role who already has improvement background, skills, and experience. It also helps if the designated senior management sponsor has experience in successfully sponsoring an improvement effort. (We know we’re asking for a lot!) If you can manage that, this can be a very effective model while you’re small. With sufficient resources for external consultants, even midsize companies can use it.

The risk with this approach is that you have a single point of failure. If your focal point gets tired of the work or decides to leave the position or your company, you’ve got a big hole to fill. This is especially true if he or she leaves in the middle of your effort—and when you get going in your improvement effort, you’re almost always in the middle of something!

11.4.3 Internal Focal Point, Designated Senior-Management Sponsor or Steering Group, External Consultants for Most of the Work

In this model, the primary role of the internal focal point is to coordinate with the external consultants to make sure they get access to the internal folks they need, and to report status back to the senior management sponsor or steering group. It can be a useful model if you don’t have anyone internal with process improvement background and skills, but you do have someone who knows the ins/outs of the organization and is willing and ready to learn those skills.

This model works best if you focus the external consultants on teaching the internal staff, not just doing the improvement work for them. There are two advantages to this:

•   If the consultants are teaching PI skills, you’re building internal capability that you can take forward into future cycles and have less dependence on outside staffing.

•   You will get a lot more buy-in from your staff if they have participated in generating the new assets rather than just watching them get built and being responsible for using them.

11.4.4 Internal PI Group, Senior-Management Steering Group, External Consultants for Training/Specialty Work, Internal Part-Time Improvement Teams for Improvement Projects

This is the classic EPG (Engineering Process Group) model. It is the model taught in SEI training courses like Mastering Process Improvement (MPI) and many SEPG conference tutorials and was covered in the first publication on process improvement organization that the SEI published, called Software Engineering Process Group Guide.³ If you decide to read this report, understand that it was written when the software CMM (the predecessor of CMMI) had not even been released. Some of the advice is sketchy, because the base of experience wasn’t nearly as broad as it is today. Other process improvement textbooks also go into a good bit of detail on how to organize and staff this kind of structure.

3. Fowler, Priscilla, and Stan Rifkin. Software Engineering Process Group Guide, CMU/SEI-90-TR-024. (Pittsburgh: Carnegie Mellon University, 1990).

The relevant elements of this model are that a group of full-time staff—usually supplemented by rotating part-time staff—is responsible for the improvement infrastructure, improvement-related training development and delivery, managing appraisal consultants and/or developing internal appraisal capability, and deploying improvements throughout their designated scope. The guidance from their efforts comes from a Management Steering Group that is usually composed of some subset of the organization’s senior management. This group has sufficient resource authority to enable the EPG to get what it needs, and it holds the EPG accountable for the resources spent and the results achieved. These two structures are supplemented by improvement teams from the organization at large. These teams are temporary and staffed by subject-matter experts in the activity being worked on. Usually, one of the EPG staff will either lead or facilitate each of these groups.

The advantage of this structure is that if you have sufficient numbers to warrant it, you can get a lot of progress from a small number of full-time people, and you can sustain management sponsorship if you have the right kinds of communication going on. You also end up with an organic, sustainable capability in PI methods and techniques that can support you through a number of improvement cycles.

The risk with this model is that you can end up putting too much resource into building and sustaining your infrastructure. There’s always more to do, and the more resource you put into it, the more you can do, but you have to weigh that against what you should do to improve your business outcomes. Aligning your improvement goals with your business goals is a critical mitigation for this risk.

11.5 Creating and Evolving a Pal (Process Asset Library)

A working definition of process asset library (PAL) that works for us in teaching about developing and using process guidance is

an organized, well-indexed, searchable repository of process assets that is easily accessible by anyone who needs process guidance information like examples, data, templates, or other process support materials.

Please note that this definition says nothing about the technology base used to create or deploy the PAL. From a strict CMMI viewpoint, the PAL is a technology-independent concept. However, from a practical viewpoint, this is a high-payback area to invest in technology to support a process improvement effort.

The term process asset may need explanation. CMMI defines a process asset as “anything that the organization considers useful in attaining the goals of a process area.”⁴ We tend to go beyond this definition.

4. From the glossary in Chrissis, Mary Beth, et al. CMMI: Guidelines for Process Integration and Product Improvement. (Boston: Addison-Wesley, 2003).

In our experience, a process asset is

any process guidance, in whatever form, that an organization believes will provide sufficient return on investment to commit the resources necessary to store and evolve the asset.

Even if CMMI is not being used as the basis for improvement, identifying process assets and making them accessible are worthwhile investments for a business.

The purposes of a PAL include but are not limited to the following:

•   Provide a central knowledge base for acquiring, defining, and disseminating guidance about processes related to the organization’s tasks (usually, product or service development, management, and improvement).

•   Reduce unnecessary duplication of process assets in the organization and the work that goes into re-creating assets.

•   Provide mechanisms for sharing knowledge about the organization’s process assets and how they are used.

•   Support an effective learning environment for new employees expected to use the organization’s processes.

•   Provide a basis for making decisions about evolving and tailoring the organization’s processes.

•   Support maintaining version and configuration management of key assets such as your set of standard processes and your organizational policies.

•   Improve the consistency of content and application of process guidance throughout the organization.

Why would an organization invest in designing and deploying a PAL? For a small organization, a PAL is a key infrastructure element that reduces training time that can be ill afforded during growth spurts, and that helps lead to a process-focused culture that provides a backbone of discipline for the organization. In addition, an effective PAL is a key element in supporting reduction in time needed for planning new projects—a typical area where both small and large projects are challenged. The ability to rapidly deploy and use processes to serve the needs of the marketplace is a critical attribute of an organization experiencing hypergrowth.

For a large organization, a PAL provides one of the infrastructure elements required to support movement from one set of behaviors to another, by making public the “new rules” that the organization intends to live by. A well-designed and deployed PAL also reduces planning, implementation, and training time, especially for processes that are performed only intermittently. In these processes in particular, having access to relevant guidance to “refresh” even competent practitioners can prove a potent accelerator of confidence, and as a follow on, speed of execution.

Depending on the other process characteristics of the organization, other business benefits may accrue. These include

•   increasing the adherence to the preferred processes in the organization by making the process guidance in the PAL the auditing basis for process compliance audits;

•   increasing the participation of staff in making suggestions for changes to process assets, if responses are reasonably and visibly responded to; and

•   reducing the cost of project startup, both from the perspective of less training time required to get staff up to speed on the processes to be used and from the perspective of active, planned reuse of existing assets where appropriate.

To accrue any of the benefits cited above, a PAL must be well designed and effectively deployed. The attributes of the PAL itself influence its ability to support the purposes and achieve the potential business impacts cited above. Table 11-2 describes several attributes of a PAL that we look for when evaluating its design and implementation. These attributes are not necessarily ranked in order of importance; the ones that are more important tend to vary in terms of overall organizational culture and other factors that are outside the design of the PAL itself.

Table 11-2: Critical Attributes of a Process Asset Library

We’re sure you won’t be surprised to learn that there are challenges in effectively designing and deploying a PAL. A few of the typical ones we’ve encountered are

•   Lack of participation. Problems can arise with insufficient participation and buy-in from opinion leaders among the staff expected to use the PAL.

•   Allocating too much resource to PAL design. It’s easy to end up spending too much of your improvement resources on creating the software and infrastructure needed to support the PAL, rather than spending that effort/money on actually improving your work practices.

•   Insufficient/inappropriate training. Understanding how the information is to be used and training users in how to access the correct information for their purpose increases the utility of the PAL greatly. Not providing training, on the other hand, makes it more likely that guidance will be misused and/or ignored.

•   Moving from print-focused documents. Moving from documentation that is designed for use in print to documentation in a PAL that is designed to be used via the computer desktop is one of the often-overlooked issues in creating and deploying a PAL.

11.6 Measurement System/Repository

Many of the same issues that are relevant to building and sustaining a process asset library apply to developing and sustaining a measurement system. By measurement system, we mean all the tools, repositories, and procedures related to collecting, storing, analyzing, and reporting on measurement data for the organization.

Although the repository issues are similar to the PAL’s, there are some particular requirements for a measurement repository that you should pay attention to:

•   Security requirements. Measurement data, like some “lessons learned” data, can be sensitive from the viewpoint that it could be used inappropriately. So things like keeping names of data contributors out of reports are something that you will have to think about for your measurement repository.

•   Filtering and synthesis requirements. The amount of data that is likely to be stored in a measurement repository for almost any organization will grow large and difficult to navigate very quickly if it isn’t designed carefully. Be sure that you keep only the minimum data required for your processes and that short-lived data expires in a reasonable time and can be purged.

Beyond the repository itself, the data collection procedures and tools are an issue for the measurement system. Understanding how the data is collected (from a process audit by a third party? from the person who generated the work product? from a tool set?) can be important for most kinds of data. And tooling is one of the things that can make or break a measurement system. We have worked with several organizations that lost a lot of ground in their measurement program because the data they were asking people to collect

•   had to be collected manually; and/or

•   was work added on to the process they were performing, not a natural result of it.

These may seem like trivial barriers, but they are frequently cited in presentations and workshops as the two things that have the greatest negative impact on data collection.

The third issue for most people asked to collect data is that they don’t know or trust how the data they are providing will be used. If they perceive that the measurement will be used against them, they are likely to provide data that they believe protects them most. For an interesting discussion of the effects of asking for the wrong data from people, read Donald Wheeler’s Understanding Variation.⁵ It’s a great book on the management uses of statistical process control and is probably the shortest measurement book you’ll ever be asked to read.

5. Wheeler, Donald. Understanding Variation: The Key to Managing Chaos. 2d ed. (Knoxville, Tenn.: SPC Press, 1999).

All the details of developing a measurement infrastructure are outside the bounds of this book, but you can find excellent guidance in the Practical System and Software Measurement (PSM) materials available at www.psmsc.com.⁶ PSM is sponsored by the U.S. Department of Defense and provides reference guides, books, and courses that take you step by step through the measurement process. PSM’s approach is also compatible with the ISO/IEC 15939 standard, Software Measurement Process. Other resources include the Software Engineering Laboratory at NASA (www.sel.gsfc.nasa.gov for Goal-Question-Metric) and the SEI Web site (www.sei.cmu.edu for Goal-Question-Indicator-Metric), as well as several SEI Series books on measurement.⁷

6. Card, David, et al. Practical Software Measurement: Objective Information for Decision Makers. (Boston: Addison-Wesley, 2001).

7. Paulk, Mark, and Mary Beth Chrissis. 2001 High Maturity Practices Workshop. CMU/SEI-2001-SR-014. (Pittsburgh: Carnegie Mellon University, 2002).