A Field Guide for Process Improvement in Small Settings · Pascal Rabbath, S-3 Consulting ...

Prototype for a Field Guide for Improving Processes in Small Settings

Suzanne Garcia Caroline Graettinger Chris Carmody Mary Lynn Penn

March 2008

DRAFT

Software Engineering Process Management Unlimited distribution subject to the copyright.

This work is sponsored by the Software Engineering Institute, University of Pittsburgh Medical Center, and Lock-heed Martin Corporation. The Software Engineering Institute is a federally funded research and development cen-ter sponsored by the U.S. Department of Defense.

Copyright 2008 Carnegie Mellon University.

NO WARRANTY

THIS CARNEGIE MELLON UNIVERSITY AND SOFTWARE ENGINEERING INSTITUTE MATERIAL IS FURNISHED ON AN “AS-IS” BASIS. CARNEGIE MELLON UNIVERSITY MAKES NO WARRANTIES OF ANY KIND, EITHER EXPRESSED OR IMPLIED, AS TO ANY MATTER INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR PURPOSE OR MERCHANTABILITY, EXCLUSIVITY, OR RESULTS OBTAINED FROM USE OF THE MATERIAL. CARNEGIE MELLON UNIVERSITY DOES NOT MAKE ANY WARRANTY OF ANY KIND WITH RESPECT TO FREEDOM FROM PATENT, TRADEMARK, OR COPYRIGHT INFRINGEMENT.

Use of any trademarks in this report is not intended in any way to infringe on the rights of the trademark holder.

Internal use. Permission to reproduce this document and to prepare derivative works from this document for inter-nal use is granted, provided the copyright and “No Warranty” statements are included with all reproductions and derivative works.

External use. Requests for permission to reproduce this document or prepare derivative works of this document for external and commercial use should be addressed to the SEI Licensing Agent.

This work was created in the performance of Federal Government Contract Number FA8721-05-C-0003 with Carnegie Mellon University for the operation of the Software Engineering Institute, a federally funded research and development center. The Government of the United States has a royalty-free government-purpose license to use, duplicate, or disclose the work, in whole or in part and in any manner, and to have or permit others to do so, for government purposes pursuant to the copyright license under the clause at 252.227-7013.

For information about purchasing paper copies of SEI reports, please visit the publications portion of our Web site (http://www.sei.cmu.edu/publications/pubweb.html).

SOFTWARE ENGINEERING INSTITUTE | i

Table of Contents

Preface vii

Acknowledgments ix

1 Introduction 1 1.1 Who Should Use This Guide 1 1.2 What is “Small” Anyway? 2 1.3 Why Process Improvement Matters to Small Settings 3

1.3.1 Market Forces 3 1.3.2 Internal Forces 3 1.3.3 National and Global Forces 3

1.4 Why Process Improvement is Challenging for Small Settings 4 1.5 Before Starting a Process Improvement Effort 5 1.6 What This Guide Is and Isn’t 6 1.7 Continuing to Evolve this Field Guide 7 1.8 Conventions Used in the Guide 7

2 Scenarios 9 2.1 Process Champion Scenarios 9

2.1.1 Scenario Topics for Process Champions Not Elaborated in Phase 1 9 2.1.2 Understanding How You Want New Processes to Work 10 2.1.3 Understanding How Processes Currently Work 10

2.2 Process Improvement Sponsor Scenarios 11

3 IPSS Competencies 13 3.1 Introduction to Using the Competencies 13

3.1.1 Applying Improvement Life Cycles 13 3.1.2 Applying Scenarios: Matching Problems and Solutions 13 3.1.3 Your Use Will Change as You Learn and Progress 14 3.1.4 Finding and Filling Skill/Knowledge Gaps 15

3.2 Building and Sustaining Sponsorship and Ownership 16 3.2.1 Introduction 16 3.2.2 Seeking Sponsors 16 3.2.3 Communicating With and Sustaining Sponsorship of Organizational Leadership 18 3.2.4 Being a Sponsor 19

3.3 Developing and Measuring Realistic Goals 20 3.3.1 Introduction 20 3.3.2 Setting Goals and Success Criteria Aligned with Sponsor Objectives 20 3.3.3 Understanding the Current State of the Organization 21 3.3.4 Defining Process Improvement Measures 24

3.4 Developing and Sustaining a Process Improvement Infrastructure 26 3.4.1 Introduction 26 3.4.2 Staffing and Organizing the PI Effort 26 3.4.3 Developing and Sustaining Process Improvement Team Members 27 3.4.4 Establishing Improvement Infrastructure to Support and Sustain Process

Improvement 30 3.4.5 Establishing and Evolving a PAL 32 3.4.6 Establishing and Evolving a Measurement System/Repository 33

3.5 Defining/Describing Processes 34 3.5.1 Introduction 34

ii | A FIELD GUIDE FOR IMPROVING PROCESSES IN SMALL SETTINGS (DRAFT)

3.5.2 Performing Model-Based Business Analysis 34 3.5.3 Performing Different Types of Process Analysis 34 3.5.4 Developing Process Support Guidance (Templates, Checklists, etc.) 35 3.5.5 Connecting Process Definition/Support Documents to the PAL 37 3.5.6 Defining Processes in Different Definition Contexts 38 3.5.7 Collecting and Incorporating Lessons Learned from Improvement Activities 48

3.6 Deploying New and Improved Processes 49 3.6.1 Introduction 49 3.6.2 Communicating with Stakeholders 49 3.6.3 Working with Consultants 50 3.6.4 Deploying Practices to the Targeted Organizational Scope 51 3.6.5 Supporting Change Management Needs of Stakeholders (Soft Skills) 53

3.7 Determining Improvement Progress 56 3.7.1 Introduction 56 3.7.2 Selecting a Progress Determination Philosophy 56 3.7.3 Appraisal Methods for Different Reference Models 56 3.7.4 Alternative Progress Determination Activities 57

Appendix A: SEPG 2008 Presentation on IPSS 59

References/Bibliography 63

SOFTWARE ENGINEERING INSTITUTE | iii

List of Figures

Figure 1: Example Swim Lane chart (created in MS Visio) 46

Figure 2: Example Visio Swim Lane Being Modified in Process Definition Session 47

Figure 3: Consulting Role Grid 51

iv | A FIELD GUIDE FOR IMPROVING PROCESSES IN SMALL SETTINGS (DRAFT)

SOFTWARE ENGINEERING INSTITUTE | v

List of Tables

Table 1: Drexler-Sibbett Team Performance Model Summary 29

Table 2: Information Mapping Information Types 36

Table 3: Readiness Checklist for Defining Local Processes-in-Use 40

Table 4: Materials Checklist for Paper-Based Definition Techniques 40

Table 5: Materials Checklist for Computer-Based Definition Techniques 40

vi | A FIELD GUIDE FOR IMPROVING PROCESSES IN SMALL SETTINGS (DRAFT)

SOFTWARE ENGINEERING INSTITUTE | vii

Preface

To help organizations in small settings pursue process improvement, the Software Engineering Institute (SEI) is developing this document, A Field Guide for Improving Processes in Small Set-tings, with how-to guidance, examples, templates, checklists and other information. This incom-plete, prototype version of the field guide represents the work completed in phase one of the IPSS (Improving Processes in Small Settings) project.

For some time now the SEI has heard about the need for the information and guidance presented in this guide. If you work for a small business, participate on a small team, belong to a small busi-ness unit, or work on small projects, then you work in a small setting and are likely familiar with the challenges of process improvement in these contexts.

The SEI began to actively explore this arena in 2003 and 2004, with a pilot study in Huntsville, Alabama. The study resulted in new knowledge and ideas for how to accelerate implementation of one improvement methodology—Capability Maturity Model Integration (CMMI®)—in small businesses [1, 2]. This was followed by an insightful workshop in October 2005, involving re-searchers from around the world [3].

Based on this work and recommendations from the International Process Research Consortium, the SEI launched the Improving Processes in Small Settings (IPSS) project, in collaboration with University of Pittsburgh Medical Center (UPMC) and Lockheed Martin Corporation (LMCO). Why would UPMC and LMCO—whose employees number in the tens or hundreds of thou-sands—be interested in a project for small settings? Because, like many large organizations, they are amalgams of many small projects and business units, with myriad small business partners and suppliers.

The field guide is not constructed like CMMI or any other process improvement model or frame-work. The field guide is a collection of how-to guidance for process improvement in small set-tings, independent of the process model or standard used. We intend it to help fast-track the im-provement effort and convey the scope of effort and skills involved at each step so that the small-setting practitioner may be a smarter consumer of process improvement products and services or be better at doing it themselves, whichever they choose.

We expect that this field guide will evolve. Our plan for populating the field guide includes col-lecting real-world experiences from experts across the process community who can provide knowledge, techniques, examples, checklists, scripts, and other artifacts to help others succeed in small settings. The guidance will include step-by-step tasks for various situations and constraints of the small setting.

We welcome the involvement of small settings experts, citizens, and their stakeholders to help accelerate the development of the field guide. For more information on the Field Guide and the Improving Processes in Small Settings project, please visit the project website at http://www.sei.cmu.edu/iprc/ipss.html.

viii | A FIELD GUIDE FOR IMPROVING PROCESSES IN SMALL SETTINGS (DRAFT)

SOFTWARE ENGINEERING INSTITUTE | ix

Acknowledgments

The IPSS team would like to thank and acknowledge the following individuals who contributed to or reviewed the content of earlier versions of the prototype:

• Yoshihiro Akiyama, Next Process Institute Ltd. • Sebastian Cazacu, TenStep Romania • Min Chen, Alcenit • Michael Dedolph, CSC • Ivaylo Gueorguiev, European Software Institute Center Bulgaria • Orhan Kalyaci, XPI • Patrick Kirwan, Software Engineering Institute, Carnegie Mellon University • Claude Y. Laporte, Department of Software and IT Engineering, École de Technologie Supé-

rieure • François Ouellette, LogiQual Inc. • Malcom Patrick, Process Advantage Technology Inc. • Pascal Rabbath, S-3 Consulting • George Wilkie, Center for Software Process Technologies, University of Ulster • Rawdon (Rusty) Young, Software Engineering Institute, Carnegie Mellon University

We would also like to thank the participants of the Huntsville pilot projects, both consultants and company team members, and the members of the SEI’s International Process Research Consorti-um for their commitment to supporting improvement of the small setting.

http://www.logti.etsmtl.ca/

http://www.etsmtl.ca/

http://www.etsmtl.ca/

x | A FIELD GUIDE FOR IMPROVING PROCESSES IN SMALL SETTINGS (DRAFT)

SOFTWARE ENGINEERING INSTITUTE | 1

1 Introduction

People, process, environment, and technology—these are the major determinants of cost, quality, and schedule in today’s software-intensive systems and services. Of the four, process is often re-garded as the glue that holds the organization together, or the tracks that guide the train. However you phrase it, good processes are critical to getting the most from the investment organizations make in their people and technologies. But to be most effective, these processes must fit the envi-ronment the processes will be performed in.

The Software Engineering Institute (SEI) has studied processes and process improvement (PI) approaches since 1984, working with organizations around the world that are industry leaders in software and system development, acquisition, and maintenance. Through these collaborations the SEI has learned much, and has developed guidance to help individuals, teams, and organizations understand what comprises good processes and how to develop them to suit each organization’s unique goals, objectives, strengths, and weaknesses. This is reflected in the SEI Personal Software ProcessSM (PSPSM), Team Software ProcessSM (TSPSM), Capability Maturity Model® Integration (CMMI®), and People Capability Maturity Model (People CMM) technologies. But, because larg-er rather than smaller organizations have had more resources and finances to work with the SEI over the years, these technologies have inherently favored the organizational infrastructures of large organizations. As a result, small organizations have complained that these technologies are too big, too complex, too costly, and too time consuming for the small business, small project, and small organizational unit, and they’ve asked the SEI for help. These “small settings” seek the ben-efits of process improvement, just as the “big guys” do, but many feel intimidated by the current offerings. This is not to say that small settings can’t undergo incredible transformations as well as the large settings do. It has been done and it continues to be done, and insights from some of those success stories are incorporated into this guide. But very often the SEI hears that small settings want to improve but don’t feel as though they have the resources, time, or skills to do so. This is the starting point for this field guide.

1.1 WHO SHOULD USE THIS GUIDE

If you own or work for a small business, belong to a small team or small business unit, or work on small projects, this guide is for you. Consultants, coaches, and mentors of process improvement may also find the information useful and may choose to incorporate the content into their own practices. And while larger organizations may find the information helpful too, the real target for this guide is the person in the small setting; someone with an interest or responsibility for improv-ing performance. This is a process improvement field guide for the small setting.

What can you expect to gain from this guide? We intend it to help individuals, teams, managers, and executives in small settings achieve efficiencies in their work and improve the quality of their products and services. This guide is about minimizing the limitations of small settings while max-imizing the benefits when approaching process improvement. It is about gradual, progressive pro-cess improvement, just-in-time training, minimal learning curves, reduced overhead, minimal up-front costs, uncomplicated artifacts, and improvement rather than certification. It’s more about the

2 | A FIELD GUIDE FOR IMPROVING PROCESSES IN SMALL SETTINGS (DRAFT)

competencies needed to successfully start and sustain any kind of improvement effort than about any particular reference model or standard.

This guide is also a work in progress. It is the start of a living document; we will add to it as we learn more and gather experiences, data, templates, checklists, and other guidance to benefit the small setting. You are welcome to submit thoughts and ideas at any time through the SEI’s Customer Relations department ([email protected]).

1.2 WHAT IS “SMALL” ANYWAY?

Which of the following criteria are used to define small settings?

• number of employees • sales • investment level • total net assets

The answer is all of them. Around the globe, a variety of criteria are used to define a small setting, particularly a small business. There is no standard, but the most commonly used measurement today is the number of employees. That may change as more research is conducted to understand and compare the relative importance of small businesses from country to country.

So, if number of employees is the most commonly used measurement for a small business, which of the following is considered the maximum size to be called a small business?

• 250 employees • 100 employees • 50 employees • 10 employees

The answer is all of them. Again, there is no internationally agreed-upon measure for a small business. To help address this, the labels “micro” and “mini” have been proposed, to account for the really small. Yet, even there the definitions vary.

What about small projects? Some projects are considered small when their duration is between one day and 12 months. Others, however, consider 12 months to be a large project. It’s all rela-tive, at least for now.

For the purposes of this guide, we leave open the question “what is small” from a measurement standpoint. From a practical perspective, we consider small to be any business unit for which the typical activities and approaches of process improvement could cost more than ten percent of the annual operating budget. Ten percent is something of an arbitrary number, but in talking to many organizations about their overall costs related to process improvement, this seems to be a “break point” beyond which it’s difficult for an organization to justify the expense without a strong, usu-ally external, incentive. What really matters is the challenges you face and how this guide can help address them. The next few sections provide more ideas on the characteristics of small set-tings in the context of process improvement.

mailto:[email protected]


1.3 WHY PROCESS IMPROVEMENT MATTERS TO SMALL SETTINGS

There are many reasons that small settings get involved with process improvement. Efficiency is one reason. Small settings can rarely afford to waste time or effort. Consistency is another reason and one that can impact efficiency. When roles change, new people are hired, or a new project starts, work can be done differently. Understanding what quality means or what a “good” product is in your environment can also cause an organization to start a process improvement initiative.

To some degree, your reasons will determine your particular strategy in approaching improvement activities. The three categories of forces described below are the most common in our experience of small settings. The bottom line is, whichever of these motivates you, you will need to find strategies to support your process improvement needs that stay within your limited resources while still meeting your business goals.

1.3.1 Market Forces

Small settings are subject to market constraints that are similar to those of large organizations. Increasing pressure for better quality, lower cost, and quicker time-to-market are now global mar-ket drivers. Large organizations, which now outsource more and more work to small businesses, are pushing for demonstrated process capability from their small suppliers. If you are part of a small business then you know that you face the pressure of either developing your own processes or being forced to use those of your customers, a situation that can be problematic if you have multiple customers. What about market and regulatory pressures? Are you facing more and more obstacles to performing your core business because of external standards you must comply with? The global market offers both an opportunity for growth and challenges from more competition. Around the globe, small projects, business units, and businesses are looking to process improve-ment to help them respond to swiftly moving market forces.

1.3.2 Internal Forces

A common theme in small settings—in fact, one definition of a small setting—is that the amount of resources is small, and individuals often perform several roles in the organization. Operational efficiency is critical in these environments, where reducing the time spent fixing clients’ problems translates into more time available for other revenue-producing activities. If you reduce the amount of time dedicated to overhead activities, you have more time for software or system pro-duction or service activities (i.e., the core business of your organization). Common across the small settings we’ve worked with is the goal to improve processes in order to reduce risk and re-work and improve customer satisfaction.

1.3.3 National and Global Forces

National forces, such as economic development, are pushing small businesses to consider process improvement, though those businesses may not have been aware of the field or its benefits. While this guide focuses on small businesses, small projects, and small organizational units, there is worldwide interest at the national government level in improving the competitiveness of regional small businesses [3]. The potential impact is profound, since small businesses are the major contributors to economies around the world, including the United States where 99.7% of all employer firms have fewer than 500 employees [4]. (We know that in many countries 500 is not considered small. Most of the techniques in this guide are geared toward much smaller business


units.) Governments are looking to their small businesses, as major sources of economic growth, to reduce unemployment and improve their nations’ competitiveness in the global market. As such, they often offer subsidies and other incentives to small businesses to offset the up-front investment in process improvement, and they are investing in developing process models for their particular countries.

1.4 WHY PROCESS IMPROVEMENT IS CHALLENGING FOR SMALL SETTINGS

If you’ve tried process improvement and struggled, or if you shied away, thinking that you lack the skills, talent, or resources to pull off a sustained process improvement effort, then you’ve ex-perienced one or more of the most common challenges we’ve heard. If you’ve had problems re-lated to the following factors, you’re not alone:

• Cost. This can be a bigger issue for small businesses than for small business units or small projects that reside in larger organizations. In small businesses, process improvement usually represents a larger portion of revenue than in larger organizations—at least when done by conventional means.

• Shortage of human resources. Improving your processes will take some time, and that’s time away from your day-to-day core business activities. Unfortunately, we’ve never found a way to improve or change without some amount of learning and practice. So if you’re a small setting, and if your staff is already working at maximum capacity, where do you find the time or the resources? This guide suggests ways to break learning and practice into small, manage-able pieces, providing you with enough understanding of process improvement that you’ll feel more comfortable knowing what you can do yourself and when to seek outside help. There may be times when you need and want to acquire outside products and services.

• Shortage of needed skills. The previous comments about a shortage of human resources ap-ply here too. But in addition to the needed labor, many small settings have little experience with quality concepts, which are foundational to process improvement. There are skills asso-ciated with many of the techniques of process improvement that also must be acquired. One study found that one of the most common barriers to adopting new practices or technology in small IT organizations was lack of access to internal skills and no training or consulting budget to get them [5].

• Paradox of choice. Have you ever heard of CMMI? How about Six Sigma? COBIT? ITIL? Sarbanes-Oxley? EFQM? ISO/IEC 12207? ISO 9000? SPICE? There are now so many stand-ards, methods, approaches, and generally helpful folk trying to make our lives easier that we’re swimming in a sea of choices (and acronyms). Small settings are particularly impacted, because multiple customers often have different preferences for the improvement standards that they encourage in their suppliers. This takes us back to the cost issue—learning multiple standards and synthesizing them into a coherent approach is typically more challenging for small settings than for large settings.

• Understanding the benefits. As we mentioned, many small settings have little experience with quality concepts, and thus, with process improvement. So why do it? What are the bene-fits? A study conducted by the SEI showed a four- to eight-fold return on every dollar invest-ed in process improvement [6]. The return was primarily through cost savings from reduced

Commented [bjw1]: Hi, Suz. I've deleted the "[ref]" marker for this version. If you find the reference for this item, let me know. Thanks. Barbara


rework—in other words, improved processes. Efficiency, effectiveness, higher quality prod-ucts and services, improved customer satisfaction, long-term and sustained business excel-lence—those are the goals of process improvement. However, measuring these benefits and having confidence in those measures implies that you have baselines related to the efficiency and effectiveness of your current processes. The practice of measurement is even less preva-lent in small settings than in larger ones.

With all these challenges, you may despair of ever reaping the benefit of process improvement. But there is good news. Small settings benefit from closer communications, tighter social net-works, and a short chain of command, all of which can lead to rapid improvement under the right conditions. Therein lies an advantage for the small organization, and this guide can help you cre-ate the right conditions for success.

In a recent study from Australia [7], 93% of small business officials interviewed said they could not adopt process improvement (not that they would not or should not, but that they could not). Compare this with 46% of officials from medium to large organizations who felt similarly, and it is clear that small settings need more help in getting beyond the perceived and actual barriers to successful process improvement. This guide is a first step in that direction.

One more important perspective of this field guide is that it assumes the decision has been made to embark on a process improvement effort. It is not intended to help you make the decision, it is intended to help you make process improvement happen once you or your organization has decid-ed it’s time to do so.

1.5 BEFORE STARTING A PROCESS IMPROVEMENT EFFORT

This guide will provide you with a multitude of tips, techniques, checklists, and friendly advice. We’ve tried to make it as simple as possible while still providing you with the benefits that pro-cess improvement provides. Bear in mind that process improvement is important and is, to quote Dilbert, “no place for wimps.” But then again, neither is the business world!

How do you know it’s the right time for starting a sustained improvement effort? Every organiza-tion answers this question differently. One way to decide is to ask yourself, “Is the pain of getting the results I’m currently getting enough to put serious effort into fixing them?” This implies a problem-solving focus for your improvement effort, which we have consistently found to be pro-ductive, especially in small settings. If you’re not experiencing some significant discomfort in terms of your current or near-term business results, you’re not as likely to push through the initial challenges we introduced above.

You will be successful if you treat your process improvement efforts as an essential strategic ele-ment of the whole organization, and one that you are prepared to carry out as a project with dead-lines, milestones, and checkpoints. Here are some other general tips for success (the field guide has many more specific ideas):

• Keep it clear and simple. Conduct your improvement project as a life cycle with clear and simple phases. We’ll show you some examples elsewhere in the guide. Provide checklists wherever possible. Checklists are the most often requested tool in our experience.


• Expect some storming. There’s a well-known model of team development originated by Bruce Tuckman in 1965 that he proposes all teams must go through to become effective: forming, storming, norming, and performing. As models go, it’s a simplification, but it has proven useful in characterizing the top-level behaviors that we often observe. While your teams may not be new (forming), you will be introducing new practices and that may generate some of these behaviors. Don’t expect change to happen overnight, nor without some con-sternation (storming). But always listen if there is discontent with the changes. There may be good reason and you may want to rethink the change. Throughout the guide, we’ll introduce several models and approaches for managing and sustaining teams (norming and performing).

• Understand your starting conditions. Do all the people in your small business, small busi-ness unit, or small project have a software or systems engineering background? Do they have strong engineering knowledge? That isn’t always the case, so don’t compare the time it takes you to improve with that of other organizations, unless their starting conditions are compara-ble to yours. Remember that the purpose is to increase your effectiveness, efficiency, and quality in relation to where you started. External benchmarks provide an approach for meas-uring adherence to a set of norms, but you’re the only one who can determine what improve-ment that adherence really represents.

• Leverage prior improvement work. A history of bad experiences with change or improve-ment initiatives can have a negative impact on your future efforts at the start. Acknowledging prior mistakes and demonstrating how you intend to learn from them goes a long way toward improving your organization’s confidence. You’ll need to show how it will be different this time. We will present some techniques in the guide that can help determine the kinds of adop-tion risks you face this time. On the other hand, if you’re lucky enough to have had prior suc-cess with improvement, be sure to leverage what has worked in the past.

1.6 WHAT THIS GUIDE IS AND ISN’T

This guide focuses on what we consider to be the six major competencies for process improvement [8]:

• building and sustaining sponsorship and ownership • developing and measuring realistic goals • developing and sustaining a process improvement infrastructure • defining and describing processes • deploying new or improved processes • determining improvement progress

If your small business, business unit, or project is going to improve, you will have to develop these competencies or buy them, or both, although not all at once! We hope that this guide will provide you with enough information to understand what it takes to improve; you can decide when to do it yourself and when to use outside products and services. In the latter case, the infor-mation in the guide should give you a better understanding of what you’re paying for.

The competencies comprise a collection of knowledge, techniques, examples, checklists, scripts, and other artifacts that the authors and other members of the process improvement community


have used and recommend to help small settings improve their efficiency, effectiveness, products, and services—in other words, to do process improvement.

In this field guide you will find discussions of some models and standards such as Capability Ma-turity Model Integration (CMMI), ISO 9001, Sarbanes-Oxley, Information Technology Infrastruc-ture Library (ITIL), Six Sigma, and others. Describing how all these fit together is a development project in itself, but we will do our best to give you just enough information to make some straightforward choices. This guide will work for you independent of whichever process model or standard you choose to implement, because it focuses on all the things you need to do regardless of which model or standard you use.

Just as there are many process improvement models and standards to choose from, there are also multiple process improvement life cycles. Future versions of this guide will include overviews of popular improvement life cycles, explanations of how the field guide can be used with those life cycles, and suggestions for choosing an appropriate life cycle. We recognize that this means a bit more work on the part of a new user, because you’ll have to choose the life cycle that fits your context. However, a strong aspect of our experience is that the particular life cycle you use, which is where sequencing of activities typically occurs, must be chosen based on your business and operational context more than on the reference model you use as a basis for your improvement.

So, regardless of which collection of best practices (such as CMMI), or which improvement life cycle (such as DMAIC, which stands for define-measure-analyze-improve-control) or other pro-cess model or standard you choose to implement, you must develop some or all of the six compe-tencies listed above at some point in your improvement effort. This guide is intended to provide you, in the small setting, with much of the knowledge that you need to be successful.

1.7 CONTINUING TO EVOLVE THIS FIELD GUIDE

This guide is a reflection of its contributors. It leverages their experience as practitioners, teach-ers, and consultants to small settings around the world. The guide represents decades of process improvement experience, both successes and hard-learned lessons. It is meant to be a how-to ref-erence that is

• practical • easy to use • informative • evolving

Your feedback is important to making the guide all of these things. Through use and feedback from users like you, we will learn what content is most useful, what provides the most return on investment, what is easiest to use, and what helps you solve unique problems. This guide will evolve along with the community and in response to tomorrow’s challenges.

1.8 CONVENTIONS USED IN THE GUIDE

There are several kinds of information included in the guide, even at this prototype stage. The ones marked with T plus a number (e.g., T1.1.1) indicate tasks that we have, or intend to, elabo-rate with detailed guidance on how to perform the task. The exemplar for this in the prototype is


T4.5.1, Defining Local Processes in Use. Appendix A contains a presentation on the IPSS project given at SEPG North America 2008. This presentation lays out the architecture of the guide and shows the contents of the template that will eventually be populated for each of the tasks.

Commented [smg2]: Should we bring these diagrams up front? (they don’t exist in the current version, but I have them ready to dump in when I get to the end of the document….


2 Scenarios

The IPSS Field Guide scenarios are a key strategy for preventing the guide from becoming over-whelming to an individual in a small setting who is approaching process improvement for the first time. The scenarios provide a method for connecting your problems to the part of the guide that is likely to provide a solution.

Some scenarios are fairly complete narrative stories, similar to a case study. Others are mini-scenarios that deal with one or two aspects of a particular situation.

In this first prototype of the field guide we present two mini-scenarios. These connect to different parts of the IPSS competencies section. However, we’ve also provided the initial list of scenarios that we believe will be useful, to illustrate the possible scope of our scenarios. We anticipate that this will be one of the areas that grows the most as we move forward.

As of this writing, scenarios are organized by the role of the person likely to be the “star” of the scenario. The architecture of the scenarios section will likely evolve as we get more content in this area and can see what kinds of patterns emerge. The two roles we’ve identified so far are the “process champion” and the “process improvement (PI) sponsor.”

2.1 PROCESS CHAMPION SCENARIOS

The process champion is the person who often brings the idea of process improvement into the organization or project. Even if this person is not the source of the idea, he or she is enthused about it and is willing to go beyond normal duties to help make something good happen.

The process champion is also the person on whom will fall much of the work of getting a process improvement effort going. You will see this reflected in the character of the scenarios included in this section. Two scenarios are more fully described in Section 2.1.2. All others are for future work in this evolving field guide.

2.1.1 Scenario Topics for Process Champions Not Elaborated in Phase 1 • Choosing an improvement life cycle/approach • Building a business case for PI • Preparing for a conformance appraisal

− CMMI − ISO 9001

• Moving a PI team from a philosophy of “here’s what’s wrong” to “here’s how I can help” • Pushing back on scope creep on the improvement effort without getting fired!

− oh, why don’t you help us with all our tool selections? − how to stay focused

• Reinvigorating a stalled improvement effort − some progress has been made, but interest is waning from both participants and sponsors

• Getting buy-in from the people who have to make the changes


• Sponsor is on board, but staff is resistant • Keeping a PI team focused on process deployment instead of tool development (e.g., PAL or

measurement repository) • Setting expectations for what effort is needed to plan and manage PI “projects” • Deciding if/when you need external help

− for training − for consulting − for appraisal

• Communicating with a potential sponsor for the first time − what do you talk about? − what do you not talk about? − what should your expectations be? − what about when you hold multiple roles within the improvement?

• Figuring out what baseline metrics should be − the ones you’re going to ask people to collect

• Dealing with multiple roles for one person in an improvement effort − sponsor champion = PI specialist = project manager = engineer

2.1.2 Understanding How You Want New Processes to Work

Related Competency: T4.5.2 Developing definitions of local desired processes

The Historical Archives of Smalltown (HAS) web development project received a grant to hire three web developers to help write the software and manage the content of a website. Three months into the project, the team realized that one of the key attributes of the project—allowing individual citizens of Smalltown to contribute documents and stories to the site—would involve a significant challenge, which the developers termed a “configuration management nightmare.” One of the developers, Sandra Connery, suggested getting some potential users from the town council to participate with the team in a workshop to define the processes that the users would see when interacting with the system, followed by an internal workshop for the development team to define how the contributions would be processed once received from users. She suggested using the IPSS field guide’s guidance for the competency “Defining and Describing Desired Local Process-es” as an approach to conducting the workshop. After looking at the material in the guide, the team decided that the flip chart/post-it technique suggested in the guide would be the most usable option for the participants.

2.1.3 Understanding How Processes Currently Work

Related Competency: T4.5.1 Developing definitions of local processes-in-use

This scenario links to the scenario T4.5.1 Developing definitions of local processes-in-use

Sandra Connery of the Historical Archives of Smalltown (HAS) web development project was frustrated. She had tried to get the potential users of the website and team members of the project to define how they wanted to apply configuration management of community contributions (such as documents, scanned images, and stories). Every time they seemed to be getting somewhere, someone would say, “But we’ve always done it this way.” This would devolve into a conversation


that had nothing to do with the project, but everything to do with how people were accustomed to interacting with the Smalltown town council.

After looking around the IPSS field guide site, Sandra decided to send a question to the IPSS field guide mentor, someone who was assigned to answer questions from the field. “When you get bogged down in ‘what we used to do’ in trying to define a new process, how do you deal with it?” The IPSS mentor on duty wrote back, “Maybe you should try getting them to describe how their current processes of interacting work now—we call that the local process in use—and then you can see what kinds of issues that process raises in relation to the goals you have for the new pro-cess. Giving the users recognition that you understand their current process and are taking it into account is one of the ways to improve buy-in to changes that you need to introduce. Try looking at our Defining Local Processes In Use task in the field guide. It’s under the Defining/Describing Processes competency.”

Sandra did as the mentor suggested and looked at the site. She noticed that the techniques were similar between processes in use and desired processes, but that the goals and some of the out-comes were different.

The second meeting of the team and users went much better. Sandra explained how the definition of the process in use would be used, with the users’ help, to define a new process that would meet the goals of the project while preserving as much as possible of the processes that people current-ly liked.

2.2 PROCESS IMPROVEMENT SPONSOR SCENARIOS

The process improvement sponsor is the individual who provides the resources (both labor and non-labor) and the leadership and vision for the improvement effort. In small settings, this role often gets merged with the process champion role, but not always. The scenarios in this section deal with aspects of sponsorship that relate to understanding why the improvement effort needs to happen and making sure that productive improvement activities can actually take place. None of these have been elaborated in Phase 1, and we know that there are many more sponsor scenarios that will need to be elaborated.

• Choosing a model as the basis for improvement • Finding the “right” success measures for your environment when you don’t have history • Dealing with PI risks explicitly • Breaking old patterns of management behavior • Deciding if it’s the right time for an improvement effort


3 IPSS Competencies

3.1 INTRODUCTION TO USING THE COMPETENCIES

Different people approach a new competency in different ways. Some prefer to “see the whole picture” and plan how they will use the different competencies within specific phases of an im-provement life cycle. Others prefer to look at the competencies from the viewpoint of what prob-lem each competency solves. Some want to focus on matching the competencies to their antici-pated progress along scales like maturity levels. And still others prefer to look from the viewpoint of skills they already have versus skills and knowledge they need to add to their repertoire.

Over time, it is our intent that the IPSS competencies section of the field guide will satisfy all of the above modes of use. This prototype focuses primarily on describing the basic competencies and providing an example elaboration of a task within a particular competency, which should fa-cilitate some skill gap analysis. It also demonstrates how scenarios can be used to match a particu-lar competency to a common process improvement problem area. The prototype does not attempt to map the competencies to improvement life cycles, but we hope to have at least some of that work done in the near future.

3.1.1 Applying Improvement Life Cycles

Although it may be tempting to think about the IPSS competencies as a sequence of things you do, one after another, their use is likely to be different from that approach. The competencies will be returned to again and again as you progress on your improvement journey. The way you se-quence your journey depends on many factors, including the model you choose to guide your im-provement effort, the culture of your organization, the goals of your improvement effort, and the skills, experience, and knowledge already present in your people.

In the future we plan to provide examples of how you might apply the IPSS competencies within some well-known improvement life cycles, such as IDEAL (the SEI’s process improvement life cycle, which expands to Initiating-Diagnosing-Establishing-Acting-Leveraging/Learning).

3.1.2 Applying Scenarios: Matching Problems and Solutions

We have included a list of scenarios and mini-scenarios in Section 2 that characterize many of the problems we have observed as people in small settings undertake improvement activities. As the guide evolves, we will connect elements of the scenarios to places in the field guide where you are likely to find solutions or elements of solutions that address each scenario problem.

Rather than deciding which task in which competency you should address first, you have the op-tion of scanning our scenarios for problems that match or resonate with the ones you’re currently experiencing.


3.1.3 Your Use Will Change as You Learn and Progress

As you work on process improvement activities, the things you attend to will change as you pro-gress and learn, even though the task at hand, at the conceptual level, is the same. There are some patterns we have observed in the way learning during process improvement activities tends to evolve.

Stages of Learning We’ve Observed

The following stages of learning, drawn from Capability Maturity Models, are typical of organiza-tions as they improve their processes and their capabilities mature. The following description is drawn from the CMMI Survival Guide [8]:

• “Individual learning. Knowledge resides within individuals and may be informally shared with others in an ad hoc fashion.

• Group learning. Knowledge is explicitly collected and shared within groups such as teams or projects, supporting better performance within the group.

• Organizational learning. Group-based knowledge is collected and standardized, and mecha-nisms exist that encourage its use across related groups.

• Quantitative learning. The organizational knowledge transfer and use are measured, and deci-sions are made based on empirical information in addition to qualitative information. Shared knowledge is deep and wide enough to determine where quantitative methods make sense within the organization.

• Strategic learning. Knowledge collection, transfer, and use are rapid across the organization; strong, deep, and wide channels for applying innovation are available, and their use is intrin-sic in the organization’s behavior.

The first four stages generally focus on improving the operational effectiveness of the organiza-tion. Operations, as used here, are not limited to managing the manufacturing plant’s resources or maintaining the software; we mean improving the effectiveness of the day-to-day operations of whatever it is you’re doing. For many software organizations, improving operational effectiveness is mostly about improving the processes they use in software product development. The fifth stage is a bit different. It’s about using what you know about your operational capabilities to respond flexibly and effectively to changes in your environment: market changes, organizational changes, key personnel changes, and so on. One of the reasons we believe maturity models are so popular is that most individuals and groups recognize the learning stages reflected here as reasonable and appropriate. Another reason is that maturity models explicitly contain mechanisms for encourag-ing the improvement of the targeted processes with relation to this learning viewpoint” [8, pp 10-11].

It is likely that a particular competency might change in character as the organization, project, and individual learn, based on the stages described above. If you are using more of a binary approach, like ISO 9001, or a non-model-based approach, this perspective may help you to understand how your focus might shift from one increment to the next of your improvement cycle.


3.1.4 Finding and Filling Skill/Knowledge Gaps

A natural use of the IPSS competencies is to look at your own skills and knowledge in the area of process improvement against those called out in the competencies and decide how, and whether, you want to go about closing the gaps you find.

To support that use of the field guide, wherever possible we will include references to SEI and other resources in future versions of the guide, to make it easier for you to fill the gaps you choose to.


3.2 BUILDING AND SUSTAINING SPONSORSHIP AND OWNERSHIP

3.2.1 Introduction General notes on this competency

Building and sustaining sponsorship and ownership may seem like an odd “competency” to in-clude in a field guide for process improvement. But trust us, this is the competency that often makes or breaks an improvement effort, regardless of the size of the business unit being im-proved. This is because improvement tasks take time and resources away from the primary tasks at hand, and unless people are sure that prioritizing an improvement activity above something else is “okay” they will be reluctant to make that decision.

The kinds of topics covered by this competency include:

• finding the right kinds of sponsors for your effort • communicating effectively with sponsors (especially if you’re not part of their peer group) • exhibiting appropriate behaviors if you are yourself a sponsor

We also include the concept of “ownership” in this section, because in small settings, the sponsor is often also the champion, the implementer, and the adopter.

3.2.2 Seeking Sponsors

Seeking sponsors is about finding the individuals with sufficient power and authority within your business, organization, or project to provide resources and attention for the PI effort.

To accomplish this, you typically should be able to understand the informal and formal power structures that are relevant to your effort, and to discern the likelihood that a particular candidate will be a suitable sponsor, This also implies that you have sufficient knowledge about what it will take to support your process improvement effort and that you can effectively match a candidate to your needs.

In small companies or organizations, the sponsor for PI may also act in the role of process cham-pion or process implementer. As you look through these competencies, you will see competencies that are quite different. One of the challenges unique to small settings is that incorporating multi-ple roles (sponsor, champion, implementer) in one person means that one person must have a wide variety of skills and competencies to be successful in all of them.

T1.1.1 Finding the Right Sponsor for Your PI Effort (If You Even Need One!)

This task will be elaborated in future versions of the guide.

Applying Sales Concepts to Building and Sustaining Support

One of the skills useful in looking for sponsors is the ability to “sell” concepts to potential spon-sors, as well as to other stakeholders. Many people who become process champions come from the technical arena, and are quite disparaging about sales techniques and people who are in the


sales field as a career. However, if you think about sales from the viewpoint of “the art of persua-sion,” then you can appreciate that the skill of persuasion is one that a process champion needs to develop [9]. A useful approach, called Solution Selling, is summarized in CMMI Survival Guide, excerpted below:

When you look at sales concepts and techniques as persuasion techniques, their fit in process improvement efforts becomes obvious. First, you have to persuade potential sponsors that it’s worth their time and effort to sanction the effort. Then you have to persuade key staff to participate in improvement activities. And then you have to persuade the group to actually adopt the new processes and practices that have been developed. That’s a lot of persuading going on! And if you’ve been educated as an engineer, you’ve most likely been taught that the primary tool for persuasion is your data set. The data set for engineering decisions is a good bit different from the data set for organi-zational improvement decisions. And often, the most persuasive data isn’t available until after improvement activities have taken place. So the alterna-tive is a priori persuasion, which relies on analogy and anecdote. Solution Selling techniques provide a nice series of understandable models to aid building and sustaining sponsorship. We’ll introduce a few of the con-cepts here but strongly suggest that you add the Solution Selling book to your reading list if you’re going to be one of the people trying to persuade your leadership to begin an improvement effort. Key concepts from Solution Selling include • Sales strategies are problem-solving strategies. The same kinds of issues

that come up in facilitating a buyer’s acquiring a product come up in fa-cilitating the introduction (“sale”) of a new technology into an organiza-tion.

• Pain-Impact-Vision Cycle. The things you need to do to be successful in sales are similar to those you need to do in building sponsorship: − Understand the buyer’s/sponsor’s need—the “pain” they are trying

to overcome. − Help the buyer/sponsor move from a “feeling” of pain to an under-

standing of the business impacts of the pain. − Help the buyer/sponsor create a vision of “what could be different”

if the new practices were adopted.

Buyer’s Risk Cycle. This cycle explains what’s important to buyers at differ-ent points in their buying cycle and is very insightful when you’re looking at a sponsorship decision cycle.

T1.1.2 Creating a PI Business Case for Funding

Creating a business case for process improvement funding is a core competency for successful change agents. Understanding how to characterize both costs and benefits in a way that potential sponsors will find compelling is the main competency involved. This is particularly challenging in organizations that have no history of effective measurement of the attributes that would normally be included in a business case.


3.2.3 Communicating With and Sustaining Sponsorship of Organizational Leadership

In Section 3.6, Deploying New and Improved Processes, we discuss general skills and competen-cies related to communicating with the variety of stakeholders involved in a PI effort. We call out communicating specifically with sponsors because there are some special considerations when communicating with this constituency.

In particular, communicating with sponsors often means condensing your communication to a much smaller timeframe than what you would spend with peers. Concepts like “elevator speech-es” (what you would say to someone who asks you about your work in the time of a typical 10-floor elevator ride) become important, as well as creating succinct executive summaries of larger documents.

So the competency here involves creating and delivering communications to your sponsor that will enable the sponsor to correctly understand your point, as well as listening effectively to spon-sor feedback, regarding both your content and your manner of presenting it.

T1.2.1 Typical Communication Activities with Sponsors

There are both formal and informal opportunities for communicating with sponsors. Future ver-sions of the guide will elaborate three areas in particular to help you with this type of communica-tion:

• Rules of thumb for communicating at the executive level • Elevator speeches • Using scenarios to communicate a PI vision

T1.2.2 Sustaining Sponsorship Once You Have It

Sustaining sponsorship is about retaining the productive attention of your sponsors. Competencies here involve determining and providing useful ways for your sponsors to frame your work to their superiors, as well as their peers. It also involves giving them tangible, productive ways to be in-volved in changes being made. One of the ways we have seen this accomplished is by providing sponsors with relevant process questions to include in different kinds of review and evaluation activities.

Giving Sponsors “Good” Questions to Ask

As we all know, everyone pays attention to the questions that senior managers ask in meetings. Junior staff, in particular, notice the kinds of questions being asked and try to prepare for them. This provides an opportunity for the sponsors of an improvement effort to influence behavior by changing the character of questions being asked in reviews. If a sponsor asks questions about the effectiveness of processes being used in project outcomes, this provides staff with a signal that they need to pay attention to their processes, not just their project milestones. This implies that sponsors develop the competency of understanding process implications in their projects and are able to evaluate answers to process questions appropriately [10].


3.2.4 Being a Sponsor

If your role is to be a sponsor of a process improvement effort, you will be relying on traditional competencies like leadership, strategic planning, and evaluation. You will also need to develop knowledge related to the approaches that are available to you, and you will need to commit to the sponsorship behaviors associated with your chosen path. Some of these are highlighted below.

In small settings, we sometimes see the process owner and process sponsor embodied in the same individual. As mentioned earlier, when this happens, that individual will also need to embody process implementation competencies.

T1.2.3 Typical Tasks for a Sponsor/Owner of a Process Improvement Effort

The tasks for an improvement sponsor include those related to the ramp up that is typical of any initiative: communicating your vision, finding the right staff to champion the vision, organizing within the available resources, etc. In addition, tasks related to influencing the organization in the direction of new behaviors are critical for sponsors.

This includes things like figuring out the “new questions” that need to be asked in periodic project and operations reviews, figuring out how your incentive structure needs to be changed to support new behaviors, and understanding how the skill base of the organization is likely to need to change to support implementing new processes.

This area includes

• Understanding how incentives/reward systems affect performance • Applying appropriate incentives and rewards • Understanding cycles of change


3.3 DEVELOPING AND MEASURING REALISTIC GOALS


One of the easiest ways for an improvement effort to flounder is for it to be working against unre-alistic or inappropriate goals. It’s easy to set goals that relate to the process improvement frame-work you are working with; for example, “Let’s be CMMI Maturity Level x by date i.” But what connection does a goal like that have to your actual business? Establishing goals that explicitly relate to your business is one part of this competency. The other parts are making those goals real-istic and actually collecting measures and data that show whether you are making progress in achieving them. Being realistic about your goals implies that you understand both the goal and your current state in relation to that goal. Measuring progress appropriately often means looking at the leverage points you have with existing measures rather than burdening employees with col-lecting more measurements.

The coverage for this competency includes

• Aligning your proposed goals against your sponsor’s objectives (if you’re the sponsor, this means aligning with your objectives for the business unit)

• Understanding the current state of the business unit • Defining the measures and infrastructures needed to collect the measures you’ve chosen

3.3.2 Setting Goals and Success Criteria Aligned with Sponsor Objectives

The purpose of setting goals and success criteria aligned with sponsor objectives is to ensure that the goals related to software process improvement actually have meaning for the business. It is very easy to adopt goals that are related to the reference model you’ve chosen (like “achieve ma-turity level x”) but are not well-connected to the needs of the business. In this section we feature three of the competencies required to help you succeed in selecting goals that align with your business objectives:

• Creating PI goals • Selecting a reference model for your PI effort • Aligning chosen reference model practices with business needs

T2.1.1 Creating Process Improvement Goals

One of the techniques that will be featured in future versions of the guide is:

• SMART goals

SMART goals are: • “Specific. It’s something where successful completion can clearly be determined.


• Measurable. The measure could be a specific value (average 500 widgets/day over 3 months), binary (yes/no), or scaled (10 percent versus 50 percent), but the measure must be appropriate for the goal.

• Achievable/Attainable. It’s something you can actually do something about. • Realistic/Relevant. Even though it may be a stretch, it’s something you truly believe is within

the capabilities of your staff and the constraints of your environment, and is something whose achievement will be beneficial to you.

• Time-Based/Tangible. For some goals, a time factor is necessary; otherwise, the goal is OBE (overcome by events). Goals that are not time-based should be tangible and observable, so that an objective evaluation of its satisfaction is feasible” [8].

T2.1.2 Selecting a Reference Model for Your PI Effort In future versions of the guide, the following considerations will be elaborated: • Considerations in using CMMI • Considerations in using Six Sigma • Considerations in using multiple improvement models concurrently

T2.1.3 Aligning Chosen Model Practices with Business Needs

In future versions of the goals, various techniques will be covered to help with alignment, includ-ing:

• Model-based business analysis [8] • Strategic visioning/planning • Scenario-based planning [11]

3.3.3 Understanding the Current State of the Organization

The purpose of understanding the current state of the organization is to ensure that, once you have set goals, you sufficiently understand where you’re starting from to make good choices of how to proceed with your PI effort. You need to understand things like

• where you are in relation to the reference model you’ve chosen • how well the reference model fits with your organizational culture • how well it fits as a source of solutions for your current business problems

It is typical for organizations to do the first of these, but not as typical for them to do the other two. This frequently leads to false starts and sometimes to sufficient lack of visible progress that the PI effort dies before it really gets started.

Small organizations, in particular, need to understand all three of these dimensions, to ensure that they do not waste precious overhead resources.


T2.2.1 Understanding Fit of Proposed Model/PI Approach to Your Business Problems

The main technique that will be elaborated related to this task in future versions of the guide is

• Model-based business analysis [8]


T2.2.2 Understanding Fit of Proposed Model/PI Approach to Your Organization’s Culture and Norms

The main technique that will be further elaborated related to this task in future versions of the guide is Readiness and Fit Analysis. It is summarized below via an excerpt from CMMI Survival Guide.

When deciding on your readiness to start a model-based improvement effort, we believe it’s best to go into it with your eyes wide open. One of the implications of this philosophy is that as part of approaching process improvement, you should look at the “fit” of your organization’s condi-tions with the assumptions that are built into whichever model you’re planning to use. For the discussion of this technique, we’ll use CMMI as the model we’re comparing to.

A prerequisite to this technique is that you understand the assumptions of the model (or product; this technique is also useful for evaluating the fit of a par-ticular support product to your organization).

The organizational factors that are covered in this technique involve non-technical factors that have historically affected (positively or negatively) adoption of practices/technologies similar to the one being contemplated. Several of these factors are derived from Paul Adler’s work related to updat-ing a company’s technology base, and they are supplemented by SEI research related to managing technological change in organizations [12]. Areas con-sidered in the technique include

• Business Strategy. How well aligned is the model being contemplated with the overall business strategy of the organization?

• Reward System. How well has the organization constructed reward sys-tems that encourage use of the new practices and discourage continua-tion of old practices?

• Sponsorship. How well does sponsoring management for new practice adoption “walk the talk” by recognizing and reinforcing use of the new practices?

• Work Practices. How easily does the organization historically implement work practice changes related to adoption of the model? (Note that the primary method of assessing this with a model like CMMI is to do some kind of practice-based gap analysis.)

• Values. How well does the organization match its own company values to the values implied by practices it has adopted in the past?

• Skills. Does the organization traditionally ensure that employees have relevant technical experience and/or project management experience re-lated to adopting new practices?

• Structure. How well has the organization historically recognized the (po-tential) need for new roles and responsibilities when new practices were implemented?


• History. What lessons has the organization internalized (for good or ill!) related to past history of new practice adoption?

Understanding your organization’s historical pattern in these nontechnical risk areas can help you avoid choosing an improvement model as the basis for your improvement effort that is likely to play to your organization’s weak-nesses versus its strengths [13].

T2.2.3 Appraising Conformance to a Model or Standard

In future versions of this guide, this task will provide guidance on doing an initial evaluation of how your business or organization conforms to your chosen reference model or standard. Section 3.7 of this guide provides information on using conformance appraisals as a progress measure. This task will cover the differences between a progress appraisal and an initial conformance ap-praisal.

3.3.4 Defining Process Improvement Measures

The purpose of defining PI measures is to ensure that you take the steps necessary to understand your progress towards your PI goals. There are, at minimum, three aspects to measure:

• Adoption progress: how broadly and deeply have the practices been adopted? • Project and organization progress measures: are we able to understand the project and organi-

zational progress we are making toward our business goals? • Business success: once the practices have been adopted, have they helped us achieve the suc-

cess that was envisioned for the business as a whole?

Many organizations, large and small, focus on the business success measures without realizing how much those measures depend on understanding (1) if new practices are actually being used, and if so, to what extent, and (2) how the projects that make up the business’s portfolio are actual-ly progressing toward their local goals.

T2.3.1 Establishing Adoption Progress Measures

In future versions of the guide, two adoption progress measures will be described: [8]

• Infusion • Diffusion

T2.3.2 Establishing Business Success Measures

In future versions of the guide, the following techniques will be elaborated to help small organiza-tions analyze business success:

• Goal question indicator metric (GQIM) approach [14] • Balanced scorecard approach [14] • Removing pain/solving known problems (using model-based business analysis) [8]


T2.3.3 Establishing Project & Organization Progress Measures

In future versions of the guide, this task will be elaborated. Section 3.7, which covers determining progress against goals, will leverage information from this task.


3.4 DEVELOPING AND SUSTAINING A PROCESS IMPROVEMENT INFRASTRUCTURE


There is no doubt that this is the scariest improvement competency for many small settings. And there is no question that some infrastructure is needed to support an ongoing improvement effort. However, you don’t need that much infrastructure right away, and there are often ways to lever-age your investment in infrastructure. This is an area where there is a great deal of creativity being seen throughout the world. In some regions, government entities are supporting the creation of open measurement repositories and process asset libraries. In others, groups of small companies pay membership dues to a consortium and share training and other resources [3].

What do we mean by improvement infrastructure? This actually covers a fairly wide range of top-ics (which is one of the reasons it’s scary!), including:

• staffing and organizing your effort • figuring out how to budget and account for your effort • establishing training capabilities (which could easily be purchased training services, not just

internal capabilities) • managing events related to your effort, like user conferences • establishing and evolving some kind of process asset library • establishing and evolving some kind of measurement repository

The timing for when you add infrastructures to your improvement effort is important. As you can see from the list above, many of these infrastructure elements will require investment. If you in-vest too soon, you may have to wait longer than you can afford for a return; if you invest too late, you won’t get the benefit possible from that investment. As you go through this competency, think about your business unit’s capability to get the most out of a particular infrastructure in-vestment. And be sure to prioritize your infrastructure investments in ways that make sense for your business goals.

3.4.2 Staffing and Organizing the PI Effort

Staffing and organizing an improvement effort is about finding the appropriate improvement life cycle and deciding what kind of infrastructure will work best for your situation.

The competencies needed to accomplish this are primarily related to understanding the typical cycles of process improvement and knowing how to apply them in different situations. However, you also need competency in analyzing your organizational situation realistically, both in terms of the style and amount of infrastructure your organization can deal with, and in terms of the re-sources—especially skilled personnel—to apply to the improvement effort.


Selecting PI Team Members for Different PI Tasks

This task involves understanding the strengths and weaknesses—skills, attitudes, and knowledge—of the staff available for you to support improvement tasks. It is also about under-standing the different kinds of process improvement tasks that need to be done. The purpose of understanding both of these areas is to enable you to match the tasks and people in a way that im-proves your chances of success. Some individuals use workshops and analytic tools like Meyers-Briggs personality typing to gain insight into attributes of their colleagues that will help them in their improvement tasks. Some people rely on the mental model that they have evolved through their own experience. The bottom line is that making good matches between people and tasks in process improvement, just as in other areas of your business, is a significant success factor.

Choosing an Improvement Life Cycle

There are many choices for improvement life cycles if one looks at the literature. However, often you’ll come into an organization that has already adopted an improvement life cycle, or has creat-ed its own.

The competency required to accomplish this task is to understand the life cycles available to the organization in terms of their fit with the organization’s characteristics. Popular improvement life cycles include IDEAL (used by the SEI) and DMAIC (promulgated within the Six Sigma im-provement community). These and other life cycles that become prominent will be elaborated in future versions of the guide.

Deciding How To Organize Your PI Effort

Organizing your PI effort has many dimensions. One of the most important decisions, one that influences many of the decisions that follow, is how much infrastructure to put in place, and how permanent you want that infrastructure to be.

For example, do you want a permanent staff of full-time process improvement specialists? Or a single PI coordinator supported by temporary teams that form to complete specific tasks?

The competency required for this task requires that you understand how to organize teams for optimum effectiveness within the constraints of the organizational characteristics related to influ-ence and resource allocation. You must decide whether to have

• permanent Infrastructure • temporary Infrastructure • no/minimal Infrastructure

Future versions of the guide will discuss implications of each of these choices.

3.4.3 Developing and Sustaining Process Improvement Team Members

Developing and sustaining PI team members involves understanding the skills represented by the staff you have available to you, and knowing the skills you must develop in your teams to accom-plish your process improvement goals.


The competencies involved here are skill evaluation, matching skills to tasks, and discerning the development activities your staff needs to improve their process improvement skills.

Developing a Team

There are several areas of a PI effort that require developing and using teams. These include de-veloping core process-improvement organizational teams, developing technical working groups that are typically temporary in nature, and possibly developing steering group teams that advise the PI effort.

The competencies involved in developing teams include matching skills and personalities to tasks, chartering and establishing ground rules, helping the teams navigate through typical team evolu-tion cycles and helping teams come to closure. There are several useful team models. The Drexler- Sibbett Team Performance Model is one that has been in use for over 25 years and pro-vides significant guidance on evaluating the state of a team and providing effective interventions to improve team performance [15] . (More detail on this model is excerpted below from CMMI Survival Guide.)

Table 1 shows the stages of the Drexler-Sibbett model and the key questions that are answered at each stage of the model.

The model is supported by a set of books and tools that are 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 re-source for trained team facilitators, because most of the knowledge needed to effectively use its models is captured in a set of guidebooks and job aids available directly from the website at a reasonable price.

In Table 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 cause 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 plan-ning 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 1: Drexler-Sibbett Team Performance Model Summary1

TPM Stage Key Question Contribution to Team Performance

1. Orientation “Why am I here?” Understanding the purpose and meaning provides a core for all sub-sequent activities.

2. Trust Building “Who are you?” Do you have mutual regard, forthrightness, and spontaneous inter-action?

Concern with trust occurs in direct proportion to the need for interde-pendence within the team. The lower the interdependence, the lower the need for trust. It deepens through repeated interaction and will be most visible in later stages of the team’s cycle.

3. Goal and Role Clarification

“What are we doing?” Specific goals, objectives, and a clear understanding of roles are necessary to move forward effectively. Clarity is often a challenge, because people vary widely in their understanding and use of language.

4. Commitment “How will we do it?” When goals and roles are clear, teams automatically begin to ask how to get into action. The creative tension between the vision of the goals and the constraints of resources and op-erational decision-making is prevalent in this stage.

5. Implementation “Who does what, when, and where?”

Scheduling and sequencing activities is necessary to create coordinated action.

6. High Performance “Do we have flexibility, intuitive communication, and synergy?”

When working in a state of flexibility, intuitive communication, and synergy, the team is likely to produce results beyond expectations. You may be a successful team if you navigate the Implementation stage successfully, but you’ll be a high-performing team only when these attributes come into play.

7. Renewal “(Why) should we con-tinue?”

The obvious time to ask this question is when the team has achieved its objective; however, there can be other major changes that would imply a need for renewal, including policy shifts, organizational changes, or taking on new members.

1 Adapted from Grove Team Leader’s Guide, www.grove.com. Accessed March 2008.


Building Skills for PI Transition Agents

Beyond developing the team itself, there is also a need to build the process improvement compe-tencies of your PI staff, both permanent and temporary staff.

The competencies in this guide provide a good starter list of competencies that might be needed by various staff. No single person will master all of these, nor will they need to.

Building Skills for PI TWG (Technical Working Group) Members

Technical Working Groups are temporary structures that are generally composed of a combina-tion of dedicated PI staff and project staff who hold temporary, usually part-time, assignments to support the TWG. Future versions of the guide will describe the types of skills usually needed by these participants in your PI effort.

Transitioning PI Team Members In or Out of the Main Organization

One of the challenges in large organizations is that individuals who are assigned to PI teams, es-pecially on a full-time basis, are often forgotten by their projects. When they are ready to transi-tion back into a project role, they find that their position has been taken by someone else, and the time spent in PI may have put them behind their peers in terms of technical skill development. This is not as common a problem in small organizations. For one thing, you rarely have the oppor-tunity to work full time on the PI staff unless you’re the leader—there just isn’t enough overhead for that. Secondly, the social networks in small settings tend to be much tighter than in larger ones, so “being forgotten” is a bit harder to accomplish. Some ideas of how to manage this transi-tion productively will be covered in future versions of the guide.

3.4.4 Establishing Improvement Infrastructure to Support and Sustain Process Improvement

Establishing improvement infrastructure to support and sustain process improvement involves deciding what kinds of infrastructure you need, how much of it you need, and when you need it. Some elements of infrastructure are needed right away (like having the capacity to manage PI projects), and some will benefit from thinking about them early on (like how you are going to ad-dress training needs). But not all are needed at the same time or in the same quantities. Typical aspects of infrastructure that are needed, even in small settings, include infrastructure for

• estimating and obtaining a PI budget • establishing training capabilities (likely to be outsourcing in a small business; in a small pro-

ject or organization, you may have access to your parent organization’s training capabilities) • establishing and managing PI projects • developing transition mechanisms (communication and implementation support mechanisms

tuned to your context) • establishing and sustaining recurring PI events (like annual PI forums or symposiums, or

monthly PI practitioner meetings)


As with many other competencies, conceptually the need for the above elements is the same in small settings as it is in larger ones. How those needs get fulfilled is usually the difference. The topics featured in this competency will address both the need and potential solutions tuned to small settings.

T3.3.1 Defining What PI Infrastructure is Necessary in Your Context

Future versions of the guide will elaborate this task.

T3.3.2 Estimating and Obtaining a PI Budget

This task will be elaborated in future versions of the guide. Two areas in particular that will be covered are:

• Traditional sources of funding (budgets allocated from the organization/business) • Creative financing (grants, etc)

T3.3.3 Establishing Training Capabilities

As you can see from the variety of competencies described in this guide, there is likely to be a need for training of some sort to build knowledge and skills in different areas. This can occur ei-ther through the PI staff building training and skill development activities, or obtaining courses, etc from outside the organization. Future versions of the guide will discuss both situations. For those who want to build their own events, the following topics will also be covered:

• Workshop design − Adding creativity while retaining strong connections to the work [8]

- CSI technique - Chaos cocktail party

• Course design/delivery • Curriculum design

T3.3.4 Establishing and Managing PI “Projects”

Many, though not all, of the activities needed for successful process improvement can be run as projects, and trying out new project management approaches that you’re thinking of asking the organization to adopt is a great way to “walk your talk.” This buys you credibility with other members of the organization, and also gives you an opportunity to do some fairly robust testing of the new practices, at least on a cooperative audience. Some of the topics that will be covered in future versions of the guide include:

• Selecting PI projects based on business goals • Estimating a PI project • Selecting a project life cycle • Creating PI project plans • Monitoring PI projects


T3.3.5 Developing Whole Product Elements/Transition Mechanisms

Transition mechanisms are the things that get added to a product to make it easier for people who are not experts in the topic area to get benefit from the product. For example, the “XYZ for Dummies” book series is a transition mechanism that makes it easier for beginners in many dif-ferent subjects to become more familiar with them, and sometimes even to build some skills. A group of transition mechanisms can contribute to what is called “the whole product,” in contrast to the “core product” for a particular technology. These concepts from technology diffusion and high-tech marketing turn out to be very useful for defining the things that need to be developed and used to support adoption of new practices by your staff. Future versions of the guide will fo-cus particularly on the following foundation to applying transition mechanism and whole product concepts: [8]

• Applying the adoption commitment curve

T3.3.6 Establishing/Sustaining Recurring PI Events

Future versions of the guide will elaborate the different kinds of events that can support a PI ef-fort. In particular, we will address conducting

• Internal PI conferences

3.4.5 Establishing and Evolving a PAL

The purpose of establishing and evolving a Process Asset Library (PAL) is to ensure that

1. process guidance is treated like an asset, in that it is properly invested in and protected

2. the process guidance that is worth investing in is securely stored and managed and made ac-cessible to organization members when and in the forms needed

Small settings have some unique considerations with regard to this competency. They are proba-bly less able to tolerate the overhead needed to develop a sophisticated PAL internally, and they may not have the financial resources to buy a commercial PAL (which was not even a choice 15 years ago, but is viable today!). This is actually a place where grant funding might be used to good effect, since many small business grants favor acquiring tangible assets as a type of grant.

This competency addresses the various decisions needed to effectively establish and sustain a PAL: [8]

• understanding typical requirements for PALs • establishing selection criteria for a COTS PAL • developing a PAL internally • sustaining and evolving a PAL

Each of these is a task that will be described in future versions of the guide.


3.4.6 Establishing and Evolving a Measurement System/Repository

The asset library for process guidance is not the only repository type of asset that is needed for a sustainable PI effort. Establishing and evolving a measurement system and repository is another necessary component. One of the biggest problems with organizations—large or small—starting out in process improvement is that they’ve never measured important project and process attrib-utes. Because of that, when they start trying to determine if performance has improved, they have nothing to compare the performance attributes of new practices against.

Why don’t small organizations measure the things that are needed to determine improvement in performance? There are many reasons, most of which come down to the fact that measures typi-cally must be collected in addition to the work being done, which is a huge barrier. It is also true that many small organizations don’t have the kinds of security in place to ensure that measures that are collected aren’t used inappropriately. This is particularly difficult in small settings when there is only one person who holds a particular role in the organization.

So it becomes important to think about a measurement system early on that minimizes double entry of data by process performers and ensures that the data is securely stored and appropriately used. To accomplish this, this competency features

• understanding requirements for measurement repositories • establishing selection criteria for a COTS measurement repository • developing a measurement repository internally • using measures appropriately • designing your measurement repository to make reference model conformance appraisals or

evaluations easier Each of these bullets will be elaborated as a separate task in future versions of the guide.


3.5 DEFINING/DESCRIBING PROCESSES

3.5.1 Introduction

General notes on this competency

This is the most obvious of the competencies, in many ways. If we’re going to improve processes, then at some point we have to describe what we mean to improve. And that’s the basic task of this competency. However, there are lots of ways to go about defining and describing processes, and there are some not-so-obvious aspects of defining processes for which small settings need to plan.

The main challenge of process definition is to describe a process in sufficient detail that a knowl-edgeable (in the domain) new employee should be able to understand the gist of how to perform a process even if they don’t know the details of the particular tools and techniques you use in exe-cuting it. We call that “creating useful process guidance.” The emphasis is on useful; otherwise you probably don’t have the time or resources to invest in it!

Topics covered in this competency include

• performing analyses to figure out which processes need to be defined • developing useful process guidance • actually defining processes for different contexts • connecting your definition activities to other activities that will use them • collecting and incorporating lessons learned from actual use into your definitions

3.5.2 Performing Model-Based Business Analysis

Performing model-based business analysis appears here as well as in the setting goals and measures competency. In that competency, its purpose is to ensure that the chosen reference mod-el can actually help with the problems of the business. In this competency, assuming that the an-swer to the above is yes, this analysis (possibly a follow-on to the event used to establish the fit of the reference model) is used to determine where the process guidance should be created or updat-ed to support the PI activities that have been planned. This is particularly important in small set-tings where you must always keep a close eye on the connection between your PI efforts and business imperatives.

3.5.3 Performing Different Types of Process Analysis

Performing different types of process analysis is about using the right process analysis tools at the right time for the right purpose. Two competencies are featured and will be elaborated in future versions of the guide:

• static process analysis • dynamic process analysis (process simulation)

One of the reasons that we include dynamic process analysis is that the tools and techniques for creating credible process simulations are finally emerging, making it conceivable to simulate how different process choices in a project and organizational setting are likely to affect different pa-rameters of the project.


However, many small organizations, especially those just starting in PI, will start with static pro-cess analysis, where static diagrams of various types (and sometimes text documents) are ana-lyzed to find particular kinds of connections and relationships. For a small organization, even this amount of use of process description and measurement data may sound like too much.

3.5.4 Developing Process Support Guidance (Templates, Checklists, etc.)

The purpose of developing process support guidance is to ensure that people involved in defining processes don’t get caught up in the diagrams and analyses to the point that they forget the pur-pose of all those definitions–to guide the practitioners of the process being described. This may sound trivial, but this purpose of process definition is a key to the difference between organiza-tions with vibrant process improvement efforts and those who are just “studying for the test”.

The kinds of support guidance we’re talking about varies from context to context, but it usually involves providing people with meaningful templates for required document types, giving them checklists that act as reminders (even for experts) of the steps that are required to adequately complete a process, providing procedures that help the “new kid” on the block to understand the boundaries of their roles and responsibilities, etc.


Information Mapping2

Information Mapping® (IM) is a system for planning and implementing structured documen-tation that can be used for many purposes [16]. It has been used for over 50 years as a meth-od for creating usable procedural information of various types. Aspects of Information Map-ping that are useful to process improvement are excerpted below from CMMI Survival Guide.

Information Mapping …uses a structured set of information types and has a set of representation rules that provide a useful set of heuristics for set-ting up different types of process guidance. There are separate IM guide-lines 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 2 illustrates the information types and some suggestions for making them easily distinguishable in your writing.

Table 2: Information Mapping Information Types

Information Type

Typical Contents

Guidance

Principle Includes things like policies, rules, con-straints, and strong guidelines

-Use strong, active language. -Use a label that clearly indicates the intended use of the information in the document/section. -Often include “why” information to motivate ac-ceptance of the principles.

Procedure “How to” information on completing steps in a task or process element, including defining the different decision points; usually very action fo-cused.

-Begin each step with an action (verb). -Make sure steps are distinct. -Make decision points/resolutions clear. -Make tables and flowcharts in typical formats. - Avoid “lists” of steps; although common, these are less effective.

Process Description of what needs to happen that focuses on characteriz-ing the vision for getting to a goal, as well as the relationships among roles and controls and measures

-Use third-person language and active voice. -Make cause/effect relationships clear. -“Flow” should move forward over time. -Stay away from “how to.” -Use diagrams to provide overview. -Tables are often useful for grouping information.

Structure Includes elements of a topic and their relation-ships, and (if appropri-ate) architectural and/or reference information

-Diagrams are a good way to communicate high-level and detailed relationships. -“Parts/function” tables provide links between definitional and structural information.

Concept Includes definitions, examples, nonexam-ples, and critical attrib-utes of a topic

-Illustrate the critical attributes in a definition with an example and, where feasible, a nonexample. -Identify relationship of the concept to the larger topic it supports.

2 Information Mapping is registered by IMI, Inc in the U.S. Patent and Trademark Office.


Fact Includes data relevant to understanding a con-cept, construct, and/or structure of a subject

-Clearly label the information as to its relationship to the relevant aspects of the topic that are cov-ered in other areas of the document.

Classification Includes list, hierarchies, and other schemes for organizing the topics

-Introduce your lists with context information. -Place most important sorting factor on the left. -Use “parallel language” throughout the list (same type of grammar/language for each level in the hierarchy).

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 infor-mation type.

• Hierarchy. Break the information into chunks in a way that allows read-ers 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 devel-opment 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 Infor-mation Mapping, Inc., courses. (See www.infomap.com for more infor-mation.) They are offered all over the United States, as well as outside North America, and come in a variety of formats.

3.5.5 Connecting Process Definition/Support Documents to the PAL

Connecting process definition and support documents to the PAL involves ensuring that all the resources of the PI effort are working harmoniously, especially when you look at how much time and effort and cost goes into investing in developing, storing, protecting, and effectively accessing corporate process information. Future versions of the guide will elaborate considerations and common issues in accomplishing this connection successfully.


3.5.6 Defining Processes in Different Definition Contexts

Defining processes in different definition contexts involves understanding the different situations that benefit from process definition and using the appropriate techniques to meet the needs of those situations. So the first part of this competency is about understanding both the text-based and diagram-based techniques that are available for process definition.

There are some pre-defined contexts for defining processes that are covered in this competency:

• Developing definitions of local processes-in-use. Local here usually means the project or the “local” work group that is performing a task; processes-in-use are the “as is” processes that are actually performed by the practitioners, regardless of what current process documentation says.

• Developing definitions of local desired processes. In contrast to processes-in-use, the desired processes are the ones that reflect how the organization wants to behave or needs to behave in the future.

• Developing organization-wide standard processes. Once local processes are understood, standard processes (note the plural) are defined that reflect agreements made among leader-ship and practitioners and are the “default” for processes that fit the context for which the process was defined.

• Developing standard process-tailoring guidance. This accounts for the fact that, no matter how good our intelligence is, something in our environment will change or differ from the an-ticipated context for our standard processes. This necessitates changing the standard process. This competency is about documenting and performing that change in such a way that it min-imizes the disruption of the utility of the standard process for which the tailoring guidance is provided.

Future versions of the guide will provide details on at least the following approaches to process definition:

• Text-based process definition techniques − Information Mapping [16]

• Diagram-based process definition techniques − swim lanes (Rummler-Brasche) [17] − IDEF [18] − Graham process mapping [19] − Box-arrow simple process flows

T4.5.1 Developing definitions of local processes-in-use

See also the Scenario: Understanding How Processes Currently Work

(Note: We envision that, when the guide goes into an evolvable web-based form, this would be an example of an active link to another place in the guide.)

T4.5.1a Purpose of Task The general purpose for defining a local process-in-use is to understand the current process well enough to make appropriate changes to meet the group’s current goals. We call this a “local” process because we’re assuming that you will be applying this to a small team or a project. The process-in-use as described is only expected to apply to


the team or project that is defined as being the scope of the process.

How big a task is this? This depends on how many processes need to be defined, based on the business needs of the organization, and how well the processes being used by the team are understood and documented already. “A” process usually has multiple roles and results in meeting a definable goal through multiple steps. Many times a pro-cess is decomposed into subprocesses to provide better guidance to one or more of the roles involved. The proce-dures related to this task could be used at either the top level process definition or at the subprocess level.

See “Defining a Standard Desired Process” for information about defining a process that is meant to be used by multiple teams or projects. By definition, the standard process would be a desired process, since it will have to be tailored with specific information about the project to be usable as a process- in-use.

T.4.5.1b Considerations Before You Begin

When to Perform This Task This task will be performed many times as you go through an improvement effort. You will want to define local pro-cesses-in-use anytime you are ready to

1. work on improving a particular process (for example, your effort planning process) and

2. the knowledge of how that process is performed is mostly found in the heads of the people doing the task

When beginning a model-based improvement effort, often defining processes-in-use is done to understand the gaps in conformance from the process-in-use and the model (e.g., CMMI) of interest.

When NOT to Perform This Task Defining local processes-in-use should not, and cannot, be performed if there is no process being used for a particu-lar topic. For example, if an organization has always been a software-coding-only organization, and its responsibility expands to include design and requirements, there is no process-in-use for eliciting requirements. In this case, you would need to refer to the Defining a Local Desired Process description to get guidance.

The other time you may consider skipping this step is if adequate documentation of the process- in-use exists to meet the need for understanding. This may be a case where there are very informal checklists or diagrams that are not standardized, but communicate enough information to allow you to understand what’s happening. Be careful, though! You still need to verify that the process- in- use is the same as what is in the documentation you’ve been given. Often people write down what they think should be happening rather than what does happen.

How Much Is Too Little/Too Much? This question begs to be given the (in)famous “it depends” answer! But there are some guidelines we’ve found use-ful.

(1) Ask someone whom you expect knows the process well to write down the most important steps in performing the process, and observe how much they write and how coherent it is.

A: If they can/do write multiple pages with a lot of detail, chances are this is a well-understood process (at least by that person), and it should be easy to get the detail needed for your analysis/communication task just by guiding the knowledgeable people with questions or diagramming techniques.

B: If the process expert can only write a very sketchy description—less than a page with very little detail—chances are it’s a process that is not performed often or is not performed by people who know the process well. In this case, you will want to spend more time and probably get more people involved in trying to figure out what really happens when the process is performed. You will probably have to ask more leading questions and provide more guidance in the definition sessions.

T4.5.1c Typical Goals of an Organization Performing the Task When defining processes-in-use, organizations, projects, or teams usually have one of the following goals:

• to understand the process-in-use well enough to safely change/improve it


• to understand the process-in-use well enough to build training materials for it for new performers of the process • to understand the process-in-use well enough to communicate it to stakeholders, such as process improvement

group members (who might want to use it as a source for standard processes or tailoring guidelines) or ap-praisal team members (who will be asked to make a judgment about how well the process-in-use conforms to CMMI or other model guidelines).

T4.5.1d Typical Inputs/Entrance Criteria

To help you to prepare for a process definition activity, here’s a checklist that you can use to decide if you have all the necessary conditions in place to successfully complete this task.

Table 3: Readiness Checklist for Defining Local Processes-in-Use

Done? Entrance Criteria Notes Process(es) to define have

been chosen. Especially for your first effort, try not to choose a really large process. (Doing a complete process definition of “our product development process” is probably a bit ambitious!)

Goals for definition activity are clearly articulated and com-municated to participants.

If the people involved don’t know what’s expected in the activi-ty, they are likely to be unprepared for the level of detail they’re expected to contribute.

At least two people who have performed the process have committed to the definition activity.

If the process is only performed by one person, then that will have to do. Even then, you may want to use the definition activity as a way to start training someone as a backup, in case your primary performer is not available.

A technique for defining the process has been selected.

Be sure to match the technology you use to what’s familiar and accessible within your environment.

People who know the select-ed technique have committed to the definition activities.

You may have to train people internally or you may be able to find external consultants/facilitators who understand the model you’re using as the base for your improvement and the defini-tion technique you’ve chosen.

Table 4: Materials Checklist for Paper-Based Definition Techniques Have? Material(s) Notes Mural Paper You *could* use flip charts lined up together if you can’t get

mural paper, but it’s usually a bit of a mess. A good source of mural-style paper if you don’t have an art store handy is HP plotter paper, usually available at your local office supply store.

Sticky Notes Multiple, bright colors; at least one of the techniques requires different colors of sticky notes that are coded to different aspects of the process

Felt Markers Flair brand markers are a favorite since they write thickly enough to be seen from a bit of a distance but are still a comfortable pen for most people to use.

Masking Tape To tape up the mural

Cellophane (clear) Tape To tape down the sticky notes until you get a chance to tran-scribe the process at the end of your session

Table 5: Materials Checklist for Computer-Based Definition Techniques Notes Laptop with selected

software installed This could be one of the diagramming techniques’ specific soft-ware, visual graphics software like MS Visio, Powerpoint tem-


plates, Word templates, etc. Whatever you’re using, be sure to have someone who knows the software running that machine.

Projector One that will connect to the laptop; these have gotten very small and light in recent years, so you may even be able to buy one dedicated to this purpose and bring it with you.

Screen Either permanent or free-standing.

Notepad /pen for taking handwritten notes

Often you will want to jot down a note about a reference # or page # that you want to go back to.

T4.5.1e Before You Start: Before starting your process definition activities for process-in-use, decide the following:

• Choose which process(es) you want/need to define at this time. If you’re unsure how to scope the bounda-ries of the process, selecting a process that creates a major deliverable for your project is often a good starting choice, and will lead you to other processes that need definition.

• Determine which of the goals listed in our Typical Goals section you are trying to achieve. If the answer is none of them, what is the reason you’re performing this task?

• Make a list of the people who have recently performed the process under scrutiny. It’s ideal to have at least two viewpoints of how the process is performed when doing the definition activities. If no one accessible to you has performed the process before, then you should think about using the “Defining Local Desired Process-es” context instead of this one.

• Choose a technique for describing the process and get someone who knows how to facilitate the tech-nique committed to the project. If no one knows how to facilitate the technique you think would be best, then you can either train someone in your team/project in the technique or hire someone who knows how to facilitate the technique. If you’re going to do lots of definition activities over a longish period of time, you may find that training someone internal is more cost effective. One way of getting this started is to hire someone who facili-tates the initial definition activities and mentors someone internal in facilitating the definition sessions.

If necessary, get approval from your local process improvement sponsor to conduct the definition activity.

T4.5.1f Materials You’ll Typically Need Each technique has a different style of collecting information. Many of the diagramming techniques involve data gathering using walls of mural paper or flip charts and sticky notes. We call these “paper-based” definition tech-niques. Others rely on direct documentation into electronic files. We call these “computer-based” definition tech-niques.

Typical Materials for Computer-Based Definition Techniques (also see notes in the checklist above):

• Laptop to record captured information during or after the session. • Process definition support software (could be as simple as MS Visio and MS Word, or could be a dedicated

process diagramming software package) • Laptop projector to show already-described portions of the process and to facilitate review after the process

definition has been transcribed • Printers that go up to at least 11-by-17-inch paper size to print diagrams large enough for people to read them • MS Live Meeting or similar web conferencing software that allows remote participation and/or review. • Electronic repository with defined information architecture for storing process fragments as they are collected. Typical materials for Paper-Based Definition Techniques

All of the above, plus:

• Mural paper. (Rolls of paper designed for use in large printers are an easy source for mural paper that is actual-ly carry-able.)

• Sticky notes. 3-by-3-inch (or metric equivalent) notes are good for task and deliverable descriptions; 1-by-2-inch notes are good for role assignments, measures, etc. Different colors can be used to add meaning (e.g., pink for tasks, green for deliverables, blue for roles, orange for tools). You’ll need one package per color per definition team, which should do quite a bit of process content.

• Felt markers. These should be of sufficient pen width for writing to be visible from a few feet away, but not so


thick that it’s difficult to get more than a couple words on a 3-by-3 note. Flair is a brand that works pretty well in the U.S. (Stay away from the smelly ones; they usually annoy people in short order.)

• Tape to hold up mural paper. Usually artists tape or masking tape works fine. Tape to hold down sticky notes. Usually clear cellophane tape works best for this purpose. (Why do this? So when you take down the mural/flip charts for transcription, you don’t lose the placement of the sticky notes, which often has meaning in the diagram.)

T4.5.1g Typical Roles Involved Defining processes-in-use assumes by implication that there are at least two roles: that of the definer, which we call the Process Definition Facilitator (PDF) and that of the individual(s) who understands how the process is being per-formed, which we call the Subject Matter Expert (SME). We also include a third role, the Process Improvement Sponsor (SP). This role generally provides a supportive environment and encourages participation in the process definition activity by the appropriate subject matter experts. In particular local situations, other roles such as a Quality Assurance Engineer or a Metrics Specialist might also get involved. We only describe what we consider to be the typical set of roles, rather than the complete set that could possibly be involved.

Subject Matter Expert (SME) Subject Matter Experts are individuals who understand how a process-in-use occurs, primarily because they are currently performing it or have performed it in the recent past. For many processes, you will need more than one Subject Matter Expert to get a complete view of the process. That is typical, since most processes include the inter-action of multiple roles to achieve the goal or purpose of the process.

When selecting Subject Matter Experts, the following criteria may be helpful. Often you won’t be able to meet all these criteria with the available pool of Subject Matter Experts, but at least if you know what you’re missing, you can try to make up for that lack with reviewers.

Desired Attributes of a Subject Matter Expert for Defining a Process-in-Use:

• Clear understanding of the purpose and goals of the process • Understanding of how this process fits with other related processes, especially those in its customer-supplier

chain • Able to separate out and separately articulate steps that are performed in a sequence from decisions and their

alternative paths • Comfortable with whatever diagramming/recording conventions the Process Definition Facilitator is using • Able and willing to spend at least an hour discussing/diagramming the process at any one time • Can articulate process steps, deliverables, etc at the level of abstraction established by the Process Definition

Facilitator

Process Definition Facilitator (PDF) The Process Definition Facilitator role is one that is usually held by one or two people. The two major responsibilities of the Process Definition Facilitator are to generate and sustain the discussion with Subject Matter Experts that re-veals how the process-in-use occurs, and to record the relevant elements of the discussion in the agreed-upon pro-cess definition style. Often the recording portion is handled by a different individual than the conversation flow por-tion, but not always. Sometimes a Process Definition Facilitator likes to do both so that he or she can test understanding of a process step by recording it in a particular way to get validation/contradiction from the Subject Matter Experts.

Desired Attributes in a Process Definition Facilitator for Defining a Process-in-Use:

• Ability to accurately interpret from conversations with multiple people an understandable diagrammatic or textu-al format at a consistent level of abstraction

• Strong ability to “see” holes in a process flow fragment and postulate feasible intermediate steps or work prod-ucts

• Ability to quickly find a useful level of abstraction for describing the process-in-use (detailed enough to see in-teraction of roles, but not so detailed that the overall flow is lost)

• Ability to manage the conflict that often arises when multiple Subject Matter Experts perceive aspects of a pro-cess being performed differently and insisting on “their” expression of its performance

• Ability to translate among different process definition approaches without losing relevant information • Strong sense of when to move from one interview topic to another (knows when a vein is “tapped out”)


Process Improvement Sponsor (SP) The Process Improvement Sponsor is the role responsible for making sure that the Subject Matter Experts who are needed to create the process-in-use definition are able and willing to participate fully. Depending on their other roles in the organization, they may have cost-center authority and be able to provide financial support, or may have more of an influence relationship with project managers who will have to release the Subject Matter Experts to participate in the definition activities.

Desired Attributes of a Process Improvement Sponsor with Regard to Defining Processes-in-Use:

• Access to and influence or power over the managers who have authority to release the appropriate Subject Matter Experts from their duties to participate in process definition activities

• Provides visible support to the process definition effort by, for example, including process definition progress in process improvement progress reports and visibly using results of the process definition activities

• Consults with Process Definition Facilitators to understand what barriers to completing the process definition activities are present and offers to intercede where appropriate

T4.5.1h Typical Steps to Accomplish Purpose Abbreviations:

• SME=Subject Matter Expert • PDF=Process Definition Facilitator • SP=Process Improvement Sponsor • DP=Defining Processes Prerequisites:

• A process definition technique has been selected and the requirements for capturing information to support the technique are understood by the Process Definition Facilitator

• The Process Improvement Sponsor individual or group has conceptually approved the process definition activi-ty.

Role Task Typical Outcome

PDF DP1.1. Determine proposed scope of processes-in-use that need to be defined

List of process topics that are candidates for process definition

PDF DP1.2. Get approval from the SP and other stakeholders as required (e.g., a PI Steering Group) on intended process definition scope

Approved list of process topics for process definition

SP DP1.2a. Understand the purpose of the process definition activities and provide requisite approval for the appropriate scope

Approved list of process topics for process definition

PDF DP1.3. Plan the process definition sessions in terms of required Subject Matter Experts, recorders, materials (e.g., mural paper, sticky notes, flip charts), equipment (e.g., laptop, projector), facilities (e.g., a room large enough and with the right equipment for the style of activity chosen), number of topics per session, etc.

Draft matrix of process topics and resources needed to support the activities Draft schedule of process definition activities

PDF/SP DP1.4. Work together to understand the proposed resources and schedule. When any issues that come up are resolved, approve the resource requirements and schedule, and obtain any approvals needed to proceed (i.e., the line managers of the Subject Matter Experts to be included)

Approved Draft process definition resource matrix Approved Draft process definition schedule


PDF DP1.5. Communicate the intended schedule and resources to relevant stakeholders (those who are named in the resource matrix and the schedule) Make any adjustments needed based on feedback

Revised process definition resource matrix Revised process definition schedule

PDF DP1.6. Get approval from relevant stakeholders on revised resource matrix and schedule

Approved process definition resource matrix Approved process definition schedule

PDF (or designate)

DP1.7. Schedule facilities, Subject Matter Experts, and other resources according to the approved plan

List of planned attendees, list of facilities mapped to sessions, and checklist of materials to be present at each process definition

SME DP1.7a. Respond to process definition invitations and arrange commitments so that you can attend the ones appropriate to your topic

Personal calendar adjusted to reflect participation in process definition ses-sion(s)

PDF DP1.8. Send out read-ahead materials on definition technique being used, including an example complet-ed definition work product

Read-ahead package emailed or other-wise made accessible to session partici-pants

SME DP1.8a. Read package sent out by PDF and perform any requested pre-work (typically to think about and gather artifacts for the processes to be described)

SMEs understand the process definition approach and have gathered potentially relevant process artifacts

PDF DP1.9. Conduct required number of process definition sessions to meet the approved scope of the definition activity

Flip charts, murals, Word documents, Visio diagrams, PowerPoint charts, MindManager maps, etc. (whatever the raw outputs are from your chosen tech-niques)

SME DP1.9a. Actively participate in the process definition sessions you’ve committed to

Better understanding of the process-in-use

PDF DP1.10. Translate the raw data captured in the ses-sions into the agreed-upon electronic form to support future analysis and post to the established repository using the agreed-upon information architecture

Process definition data organized into the established repository

PDF DP1.11. Arrange and conduct reviews of process definition work products as agreed upon in the plan (typically either in review sessions or via electronic review)

Reviewed versions of process definition work products

PDF DP1.12. Revise process definition work products con-sistent with comments from reviews

Revised versions of process definition work products

PDF DP1.13. Create summary briefing/report (whatever form they desire) for PI sponsor(s) and present to them for feedback

Process definition activities summary briefing

SP DP1.14. Arrange for and sponsor summary briefing of process definition activities with relevant stakeholders

Meeting to review process definition activities with relevant stakeholder

PDF DP1.15 Process any comments from sponsor sum-mary briefing and post revised documents into reposi-tory

Sponsor-reviewed versions of process definition work products

T.4.5.1i Possible Techniques to Support the Task This section provides several techniques for supporting process definition that we expect to be useful in small set-tings. Some of these are minimally described and referenced, where there is a publicly available reference on the technique; some are (or will be, in future versions) described more completely if we couldn’t find a reference that was publicly available.

The techniques we’ve highlighted for defining local processes-in-use are:

• one-hour process description method


• Information Mapping • Team Software Process scripts • swim-lane diagrams • interview techniques

One-Hour Process Description This technique is a “flip chart and sticky notes,” low-tech technique for describing processes that are well-understood by the performers. Subject Matter Experts work in teams of two to describe a process in terms of role (who performs a particular step), task (what the step in the process consists of), and deliverable (the event or artifact that is the expected outcome of the step). The technique prescribes approaches to organizing, staffing, and running the pro-cess definition session. This technique is documented in CMMI Survival Guide, pages 238-245 [8].

The results of the technique can be documented as either diagrams or tables. It can be an input either to Information Mapping techniques, TSP-style scripts, or swim-lane diagrams.

Information Mapping Information Mapping is a text-based technique for organizing information and has been used for decades to capture and communicate procedural information. A tutorial describing the principles of Information Mapping can be found on the Huntsville pilot toolkit site [20] and a brief description is also found in CMMI Survival Guide, pages 182-186. There is also a website with more information on the technique [8, 16].

Swim-Lane Diagrams Swim-lane diagrams are a simple process mapping technique that involves dividing a diagram’s rows by role, then documenting the tasks and deliverables for each row going across the diagram. The technique makes visible the handoffs between different roles and is often used to help understand bottlenecks in a process. A good public source for this technique is Rummler-Brasche’s Defining the White Space in Organizations. An example and a longer de-scription of the technique are also found in CMMI Survival Guide, pp. 186-188 [8, 17].

Interview Techniques Any of the above techniques require eliciting information from people who are actually performing a particular pro-cess. This implies that you’ll be interviewing either groups or individuals. Future versions of the guide will describe useful interview techniques and resources.

T4.5.1j Typical Expected Outcomes This section of the guide is meant to contain community-contributed (and referenced) examples of different tech-niques, and different situations within a single technique. Obviously, in document form this could get quite cumber-some. For this prototype, only one example for each technique is provided.

Example Swim-Lane Diagrams


Figure 1: Example Swim Lane chart (created in MS Visio)

Example Role-Task-Deliverable Flip Chart To be supplied in future versions

Example Information Map To be supplied in future versions

Example TSP-Based Script The “Typical Steps to Accomplish Purpose” table in this section is an example of a TSP-style script.

Typical Exit Criteria Process definition work products of the agreed-upon level abstraction have been created, reviewed, and approved within the agreed-upon scope of the definition activity.

Typical Progress Measures • Number of definition sessions held vs. number planned to date • Number of definitions held vs. number planned in total • Effort-hours expended to date vs. planned to date • Effort-hours expended to date vs. planned total

Typical Success Measures • Average percentage attendance per definition session • Percentage of sessions where desired Subject Matter Experts did not participate • Number of “hits” per month on definition work products (especially before there is a desired state process defini-

tion) • Number of requests for additional processes to be defined

Typical Critical Success Factors • High skill level of Process Definition Facilitator in the techniques to be used • Good fit of technique to be used with prior definition activities and local approaches to communication of pro-

cess data (i.e., text-focused vs. diagram-focused) • High level of active sponsorship for the activity • Low interference by line managers in pulling away required Subject Matter Experts

Example Artifacts from Performing this Task


Figure 2: Example Visio Swim Lane Being Modified in Process Definition Session

T.4.5.1k Applicability Differences Between Small Businesses, Small Organizational Units, and Small Projects There shouldn’t be many differences in the actual performance of this task based on whether you’re a small busi-ness, organizational unit, or project. However, there is likely to be some difference in the resources available to each of these stakeholder groups to perform this task:

• Small projects or organizational units may be asked or required to use a particular technique or process de-scription format that has been standardized by the enterprise.

• Small projects or organizational units may have access to a larger set of electronic tools to document the results of process definition activities if there is process definition activity going on in the larger enterprise.

• Small projects or organizational units may have access, at low cost or no cost, to trained Process Definition Facilitators to support this activity.

• Small projects or organizational units may have access to process definition training through their larger organi-zation.

T4.5.2 Developing definitions of local desired processes

See also the scenario: Understanding How You Want New Processes to Work

This task will be described in future versions of the guide.

T4.5.3 Developing organization-wide standard processes


T4.5.4 Developing standard process tailoring guidance



3.5.7 Collecting and Incorporating Lessons Learned from Improvement Activities

Collecting and incorporating lessons learned from improvement activities acknowledges that pro-cess definitions and their supporting guidance are not likely to be perfect when created, and even if they were, the organization’s circumstances are not static. As the organization changes, so too must the processes. To do this in a disciplined fashion that creates the least disruption to practi-tioners requires that lessons learned from the processes-in-use are collected effectively, followed by making good judgments about where different process assets need to be changed.

Some of this activity is actually easier in small settings than in large, because there are typically fewer instances of any single process being used at a particular time than there are in a larger set-ting. This makes collecting lessons learned easier, but this same lower activity rate of process use means that you may want to wait longer in between process asset changes to make sure that you’re not changing a process because of an anomalous condition.

There are two (related) competencies that are recommended to support practitioners learning and following new/improved processes:

• converting specific examples into teaching examples • converting specific examples into teaching NON-examples

Although the skills are similar for each, the purpose of teaching examples and non-examples is different.

Teaching examples are used to give a reader a quick overview of “what it’s like” to perform a particular process correctly. Good teaching examples allow the reader to identify with the context, communication, and outcomes related to the process. To build a good teaching example usually requires multiple specific examples so that the context, and other matters, can be usefully sani-tized into something that can be shared outside the original context.

Teaching non-examples are used to help practitioners understand what it’s like to perform the process incorrectly, including possible consequences of the process being mis-performed in dif-ferent ways.

Teaching examples are fairly common in process types of training, but non-examples are cited by many students as being more powerful, so a mix of both is usually a good choice.

Converting Specific Examples into Teaching Examples

This competency will be more completely described in future versions.

Converting Specific Examples into Teaching Non-Examples

This competency will be more completely described in future versions.


3.6 DEPLOYING NEW AND IMPROVED PROCESSES

3.6.1 Introduction


In many ways, this is the competency where, to use a U.S. expression, “the rubber meets the road.” In other words, you can do many of the other competencies well but still fail in your over-all effort if no one actually behaves differently than they did before you started.

Being ready for and able to effectively deal with deploying process changes into your environ-ment is actually the point of several of your infrastructure investments. But infrastructure alone will not be enough. This competency is, in many ways, the reason there is a large consulting community supporting process improvement. Many people—especially in small organizations—don’t feel able to adequately perform the change-management activities that are necessary in this competency, nor are they interested in building those skills. On the other hand, many of the neces-sary elements of this competency are learned relatively easily and go back to good management skills. Yes, just like the project or organization you’re preaching to, you need to build decent management skills!

This is another competency with a good deal of topical diversity. Topics include:

• communicating with your stakeholders • planning and managing pilot projects (both technical and adoption feasibility) • working with consultants • planning and managing organizational rollout projects • supporting change management needs of stakeholders throughout deployment

3.6.2 Communicating with Stakeholders

Communicating with stakeholders focuses on activities that communicate different aspects of the improvement effort to different stakeholders. Elements of this competency include:

• identifying the classes of internal and external stakeholders relevant to the success of the PI effort

• planning the communication mechanisms that are relevant to the PI effort • actually communicating, both formally and informally, with stakeholders • evaluating the effectiveness of communication mechanisms in use

In small settings, some of these activities can be more informal than in larger organizations. How-ever, ignoring communication activities just because the setting is small is as big a mistake for small settings as it is for large.

T5.1.1 Communicating with Internal Stakeholders

This task will be described in future versions.


T5.1.2 Communicating with External Stakeholders

Although there are many similarities between communicating internally and externally, there are a couple of situations that need to be dealt with differently when dealing with external stakeholders. These will be described in future versions. They include:

• Finding appropriate venues for success stories/lessons learned • If you’re in a supply chain or network and need to communicate about PI to your customer...

3.6.3 Working with Consultants

Working with consultants is a competency that bridges business and technical skills. There are multiple points in your improvement journey where you might want or need to work with consult-ants. In small settings, one situation where you will almost always hire an external consultant is when you want objective appraisal of your conformance to a model (like CMMI) or standard (like ISO 9001).

Regardless of the situation that leads to a decision to work with consultants, being successful with the relationship involves understanding what kind of relationship you’re expecting to have, and finding a consultant who can meet those expectations. It also involves effectively communicating your expectations to the consultant and, of course, selecting a consultant based on relevant evalua-tion criteria that are consistently applied across all candidates. One of the most useful models for managing both internal and external consulting relationships comes from Peter Block:

• Block model of consultancy life cycle [21]

There are several contexts for working with consultants. Several are described here that are com-mon

T5.2.1 Working with Consultants for Appraisal Activities


T5.2.2 General Considerations in Working with Consultants

This task will be further described in future versions. Here we present brief discussion of a con-sulting roles matrix used by the SEI that is useful in helping to define the relationship between the organization and the consultant, excerpted from CMMI Survival Guide: [8]

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. Figure 3 briefly describes the roles for each block of the grid.


Figure 3: Consulting Role Grid

T5.2.3 Working with Consultants for Training Activities


T5.2.3 Working with Consultants for Improvement Consulting


3.6.4 Deploying Practices to the Targeted Organizational Scope

Deploying practices to the targeted organizational scope involves a variety of competencies, de-pending on the organizational scope, and on the practices to be deployed. When the organizational scope is narrow and the difference between current and new practices are small, then the compe-tency primarily required is mapping a new process to a process-in-use, and identifying the chang-es in training and other infrastructure that are needed to support integration and practice of the new process.

If the targeted organizational scope is broad, or the difference between current and new practices is significant, then the competency needed grows in scope and includes defining and implement-ing one or more PI projects, complete with all the project management competencies that are then implied.

In addition to basic project management competencies, competency in change management and transition management is also important.

This is an area that can be easier in small settings than in large ones. The reduced number of indi-viduals who need to adopt a new practice also reduces the sophistication of deployment practices that are typically required.


T5.3.1 Figuring out the Most Useful Scope for a Particular Deployment

This task will be described in future versions. It will include discussions of several techniques that can help you to choose the right scope for your PI pilots and rollout [8].

• Understanding your adoption population (Everett Rogers-based) • Readiness/fit analysis • Value networks

T5.3.2 Managing Process Improvement Deployment Projects

Managing process improvement deployment projects involves traditional project management skills, such as planning, resourcing, scheduling, and monitoring. It also involves skills and compe-tencies specific to the process improvement context. These competencies include:

• technology adoption planning and management • transition mechanism development • organizational change management

T5.3.2.1 Defining and Managing Pilot Projects


T5.3.2.2 Defining and Managing Organizational Rollout Projects

Defining and managing organizational rollout projects is akin to portfolio management vs. project management. While many of the skills and competencies are the same, there is also a strategic element that is involved.

In addition to managing individual projects, the manager of rollout projects must attend to one or more of the following, depending on the organizational context:

• development of global (to the deployment scope) transition mechanisms • understanding the value network of the deployment scope to ensure that the rollout sequence

provides anticipated value • planning for both technical and adoption feasibility pilots • including feedback cycles from technical and adoption feasibility pilots • accounting for different adopter types, project types, and beams dynamics across the deployed

scope • managing both full and part-time PI staff • using appropriate adoption measurement techniques to track progress


3.6.5 Supporting Change Management Needs of Stakeholders (Soft Skills)

Supporting the change management needs of stakeholders is subtitled “soft skills” because many of the competencies used for this element come from the social sciences, often referred to as “soft sciences.” The irony of this characterization is that most engineers who get involved with process improvement consider this area the “hardest” part of the job. For most people, especially those educated in a similar fashion as engineers, this experience holds. This is because the competencies and skills involved primarily focus on human behavior and attitude change, and humans remain much more complex and unpredictable than the product systems that engineers are trained to deal with. Having said that, our experience is that many engineers can develop competency in this ar-ea, even if it is not their natural inclination.

The competencies highlighted and described in this section are not exhaustive, but they do repre-sent a good range of the competencies that are needed by change agents working in process im-provement. They include:

• Conflict resolution • Process facilitation • Understanding the cycle of change • Understanding communication styles • Understanding organizational “personality”

Conflict Resolution

Conflict resolution is a competency that involves being able to identify that a conflict is actually occurring (you’d be surprised how many people have to learn that skill), and having multiple techniques at hand for helping the participants negotiate through the conflict. Some of the tech-niques are analytical in nature, such as using force field diagrams to help participants visualize the forces “for” and “against” their position. Others are more psychologically based, ensuring that all participants in the conflict can visibly see that their point of view is being both heard and attended to.

For many, negotiation skills courses offer a path to acquiring these types of skills. Especially use-ful are courses where a strong element of role-play is included.

Process Facilitation

Process facilitation is a competency needed by all change agents at some point in their PI activi-ties. By process facilitation, we mean the process of facilitating a group’s journey to achieve a specific goal. This could be accomplished in a single meeting, or may involve a series of work-shops, meetings, and offline activities.

The skills involved in process facilitation include but are not limited to

• identifying a process to achieve a group’s goal • applying techniques for goal establishment, information elicitation, information analysis, con-

sensus building, and process evaluation


• planning and executing appropriate activities and timings for activities required to achieve the goal

• focusing on the group’s process vs. getting embroiled in its content • time management • conversation facilitation • effective listening

Many people acquire these skills initially through experience-based courses, followed by mentor-ship (and lots of practice!) with a skilled facilitator.

For process improvement, some particular kinds of meetings/tasks a change agent may be asked to facilitate include

• process description meetings • strategic planning meetings • working group chartering meetings • improvement team brainstorming meetings • PI kickoff workshops • executive steering group meetings

This is a selective list, but does provide some idea of the range of process facilitation contexts you can expect.

Understanding the Cycle of Change

Understanding the cycle of change is more of a knowledge area than a skill. It involves applying relevant psychological and sociological frameworks to a particular PI context to gain an under-standing of the stumbling blocks that are present and the enablers that are relevant when individu-als and groups are going through the process of identifying the need for change and then acting on that need.

There are many useful frameworks for helping an organization navigate a changing environment. One that has been fairly extensively used in the software process improvement context is Virginia Satir’s change cycle, which is summarized in Gerald Weinberg’s Quality Software Management Vol 4: Anticipating Change [22]. It will be described more fully in future versions of the guide.

Understanding Communication Styles

One of the primary purposes of describing and documenting processes is so that they can be communicated to and used by different stakeholders in the process. However, communication styles, both verbal and written, vary widely among different educational backgrounds, ethnic cul-tures, and individual personalities.

This competency involves applying relevant communication models to group interactions to un-derstand the potential for misunderstanding, and if it occurs, having techniques at hand to help resolve the misunderstanding. Skills and techniques related to communication style are often found in courses on consulting skills, as well as sales and marketing communication courses.

Satir Communication Model


The Satir Communication Model attempts to help people understand both their own and other peoples’ communication styles both in stress-neutral and stressful situations. Its use for process improvement is probably best expressed in Gerald Weinberg’s Quality Software Management Volume 3: Congruent Action [23].

Understanding Organizational “Personality”

In recent decades, organizational and group “personality” has been studied in addition to individ-ual personality characterization. Although there are fewer systems to study, similar caveats apply in terms of avoiding misuse of these systems. One of the more widely known of these organiza-tional systems was developed by Larry Constantine, who, as a practicing computer scientist lead-ing teams, decided that he needed a deep understanding of psychology to succeed. So he went back to university and obtained a second doctorate in family therapy. After actually practicing in that field for some years, he came back to software engineering and used his learning to character-ize team preferences along multiple dimensions to help them optimize their performance. His model is one that has been useful in many settings. It will be described in future versions [24].

• Constantine Organizational Paradigm


3.7 DETERMINING IMPROVEMENT PROGRESS

3.7.1 Introduction


Although in one sense monitoring improvement progress is a general part of managing the overall improvement effort, it’s worth considering as a separate competency because the resources re-quired for giving your sponsors definitive evidence of progress toward improvement goals can be quite significant. Generally speaking, this is also an activity that occurs more or less within its own life cycle, a life cycle that can be somewhat interruptive of other activities. Managing the activities related to determining progress as a life cycle can help you to integrate the activities related to determining progress along with your other improvement activities.

Topics covered in this competency include:

• selecting an approach or philosophy for periodically determining progress against your im-provement goals

• planning and managing a cycle of improvement progress determination events • preparing for and conducting improvement progress activities, such as process audits and

model conformance appraisals

3.7.2 Selecting a Progress Determination Philosophy

This competency will be described in future versions.

T6.1.1 Selecting an Appraisal Philosophy When You Need to Externally Market Results

Appraisals that test your conformance to a reference model are one of the ways you can externally market your progress. How to effectively use them in this way will be covered in future versions of the guide.

T6.1.2 Selecting a Progress Determination Philosophy When Progress is for “Internal Use Only”


3.7.3 Appraisal Methods for Different Reference Models

To be supplied in Phase 2.

T6.2.1 Preparing for and conducting appraisals that measure conformance to a set of practices/norms

This task will be described in future versions of the guide. It will at minimum cover the following types of conformance appraisals.

• CMMI-based


o SCAMPI family SCAMPI A SCAMPI B SCAMPI C

o ARC-compliant non-SCAMPI methods • ISO 9001-based

o Initial registration audits o Periodic external audits o Periodic internal audits

T6.2.2 Preparing for and conducting appraisals that measure “goodness” in relation to a set of attributes

This task will be described in future versions of the guide. At minimum, it will describe preparing for the following:

• EFQM/Malcolm Baldridge Award

Understanding the Resources Needed to Plan/Conduct Progress Determination—Especially Appraisal—Activities

It may seem that all that is required to determine progress is to assign someone to track which practices of the reference model of interest are in use. If it were that simple, there wouldn’t be a consulting industry that has built up around appraisals, particularly conformance appraisals. Be-sides skilled labor to conduct and prepare for determining your progress against a reference mod-el, you will also need various resources to accumulate and organize the evidence that each method requires. Any method that involves certification or registration of a result involves some kind of documentation review, which means that there will be resources required to gather and organize that evidence.

This competency will be more fully described in future versions of the guide.

3.7.4 Alternative Progress Determination Activities It is critical to note that the current depiction of the field guide for this competency outlines addressing CMMI-related appraisals. This is not the end of this competency, rather just the beginning. There are various reasons for starting with the conformance appraisal approaches. They include: • the initial contributors’ experience and expertise in CMMI and SCAMPI appraisals

• the publicly prescribed and readily-available approaches of the SCAMPI method

• the anticipated audiences’ familiarity with CMMI and SCAMPI

There are numerous strategies and approaches for measuring improvement progress, and not just for software. In fact, some of these may be a little more abstract and thus more difficult than a SCAMPI appraisal. They also can be less intrusive to the improvement lifecycle while still


achieving the goals of this competency. The field guide intends to capture some of these other methods and approaches through the contributions of process improvement community.


Appendix A: SEPG 2008 Presentation on IPSS

This appendix provides the summary slides of the IPSS project as of March 2008, at the end of Phase 1. It includes both explanatory material about the architecture of the guide and background information on the project. It also provides some indication of the vision of the project as it moves forward.

Slide 1

© 2008 Carnegie Mellon University

Slide 3

3SEI - IPSS Field GuideSEPG North America 2008© 2007 Carnegie Mellon University

Slide 5


Slide 2


Slide 4


Slide 6



Slide 7


Slide 9


Slide 11


Slide 8


Slide 10


Slide 12



Slide 13


Slide 15


Slide 17

Slide 14


Slide 16



References/Bibliography

URLs are valid as of the publication date of this document.

[1] M. B. Chrissis, M. Konrad, and S. Shrum, CMMI: Guidelines for Process Integration and Product Improvement. Upper Saddle River, NJ: Addison-Wesley, 2007. http://www.sei.cmu.edu/publications/books/process/cmmi-process-int-prod-improve.html

[2] S. Garcia, “Highlights from Piloting CMMI with Two Small Companies,” in First International Researcher’s Workshop on Process Improvement in Small Settings, Pittsburgh, PA, 2006. http://www.sei.cmu.edu/publications/documents/06.reports/06sr001.html

[3] S. Garcia, C. Graettinger, and K. Kost, “Proceedings of the First International Researcher’s Workshop on Process Improvement in Small Settings,” in First International Researcher’s Workshop on Process Improvement in Small Settings, Pittsburgh, PA, 2006. http://www.sei.cmu.edu/publications/documents/06.reports/06sr001.html

[4] United States Government Printing Office, “The Small Business Economy for Data Year 2006: A Report to the President,” 2007. http://www.sba.gov/advo/research/sb_econ2007.pdf

[5] I. Richardson and C. Gresse von Wangenheim, “Why Are Small Software Organizations Different?” IEEE Software, vol. 24, pp. 18-22, January/February 2007. http://portal.acm.org/citation.cfm?id=1262538.1262586&coll=GUIDE&dl=ACM

[6] D. L. Gibson, D. R. Goldenson, and K. Kost, “Performance Results of CMMI-Based Process Improvement,” Software Engineering Institute, Carnegie Mellon University, Technical Report CMU/SEI-2006-TR-004, 2006. http://www.sei.cmu.edu/publications/documents/06.reports/06tr004.html

[7] M. Staples, M. Niazi, R. Jeffery, A. Abrahams, P. Byatt, and R. Murphy, “An Exploratory Study of Why Organizations Do Not Adopt CMMI,” The Journal of Systems and Software, vol. 80, pp. 883-895, June 2007. http://portal.acm.org/citation.cfm?id=1234494

[8] S. Garcia and R. Turner, CMMI Survival Guide: Just Enough Process Improvement. Upper Saddle River, NJ: Addison-Wesley, 2007. http://www.sei.cmu.edu/publications/books/process/cmmi-survival-guide.html

[9] M. T. Bosworth, Solution Selling: Creating Buyers in Difficult Selling Markets. Burr Ridge, Ill.: Irwin Professional Pub., 1995. http://www.loc.gov/catdir/description/mh022/94010543.html

[10] S. Garcia, “Integrating Process Maturity Review into Project Management Reviews,” in PMI World 1999: Project Management Institute, 1999. http://www.pmi.org/Marketplace/Pages/ProductDetail.aspx?GMProduct=00100384300&iss=1

http://www.sei.cmu.edu/publications/books/process/cmmi-process-int-prod-improve.html

http://www.sei.cmu.edu/publications/books/process/cmmi-process-int-prod-improve.html

http://www.sei.cmu.edu/publications/documents/06.reports/06sr001.html

http://www.sei.cmu.edu/publications/documents/06.reports/06sr001.html

http://www.sba.gov/advo/research/sb_econ2007.pdf

http://portal.acm.org/citation.cfm?id=1262538.1262586&coll=GUIDE&dl=ACM

http://www.sei.cmu.edu/publications/documents/06.reports/06tr004.html

http://portal.acm.org/citation.cfm?id=1234494

http://www.sei.cmu.edu/publications/books/process/cmmi-survival-guide.html

http://www.loc.gov/catdir/description/mh022/94010543.html

http://www.pmi.org/Marketplace/Pages/ProductDetail.aspx?GMProduct=00100384300&iss=1

http://www.pmi.org/Marketplace/Pages/ProductDetail.aspx?GMProduct=00100384300&iss=1


[11] K. Van der Heijden, Scenarios: The Art of Strategic Conversation. Hoboken, NJ: John Wiley & Sons, 2005. http://www.loc.gov/catdir/toc/ecip0421/2004018710.html

[12] P. Adler, “Adapting Your Technological Base: The Organizational Challenge,” In Sloan Management Review, pp. 25-37, Fall 1990.

[13] S. Garcia, “Managed Technology Adoption Risk: A Way to Realize Better Return from COTS Investments,” in International Conference on COTS- Based Systems, Redondo Beach, CA, 2004, pp. 74-83.

[14] W. Goethert and M. Fisher, “Deriving Enterprise-Based Measures Using the Balanced Scorecard and Goal-Driven Measurement Techniques,” Software Engineering Institute, Carnegie Mellon University, Technical Note CMU/SEI-2003-TN-024, 2003. http://www.sei.cmu.edu/publications/documents/03.reports/03tn024.html

[15] “Team Performance System,” The Grove Store, San Francisco, CA, 2008. http://store.grove.com/grovehome/Team-Performance-System

[16] “The Method,” Information Mapping, 2008. http://www.infomap.com/index.cfm/TheMethod

[17] G. A. Rummler and A. P. Brache, Improving Performance: How to Manage the White Space on the Organization Chart. San Francisco, CA: Jossey-Bass, 1995. http://www.loc.gov/catdir/toc/wiley041/94048105.html

[18] “IDEF3, Process Description Capture Method,” East College Station, TX: Knowledge Based Systems, Inc., 2008. http://www.idef.com/IDEF3.html

[19] “Graham Process Mapping,” The Ben Graham Corporation, 2008. http://www.worksimp.com/articles/process-improvement-articles.shtml

[20] “CMMI in Small Settings Toolkit,” Software Engineering Institute, Carnegie Mellon University, 2008. http://www.sei.cmu.edu/cmmi/publications/toolkit/

[21] P. Block, Flawless Consulting: A Guide to Getting Your Expertise Used. San Francisco, CA: Jossey-Bass/Pfeiffer, 2000. http://www.loc.gov/catdir/bios/wiley043/99006430.html

[22] G. M. Weinberg, Quality Software Management Volume 4: Anticipating Change. New York, NY: Dorset House Publishers, 1991. http://www.dorsethouse.com/books/qsm4.html

[23] G. M. Weinberg, Quality Software Management Volume 3: Congruent Action. New York, NY: Dorset House Publishers, 1991.

[24] L. Constantine, “Work Organization: Paradigms for Project Management and Organization,” Communications of the ACM, vol. 36, pp. 35-43, October 1993. http://portal.acm.org/citation.cfm?doid=163430.163435

http://www.loc.gov/catdir/toc/ecip0421/2004018710.html

http://www.sei.cmu.edu/publications/documents/03.reports/03tn024.html

http://store.grove.com/grovehome/Team-Performance-System

http://www.infomap.com/index.cfm/TheMethod

http://www.loc.gov/catdir/toc/wiley041/94048105.html

http://www.idef.com/IDEF3.html

http://www.worksimp.com/articles/process-improvement-articles.shtml

http://www.sei.cmu.edu/cmmi/publications/toolkit/

http://www.loc.gov/catdir/bios/wiley043/99006430.html

http://www.dorsethouse.com/books/qsm4.html

http://portal.acm.org/citation.cfm?doid=163430.163435

A Field Guide for Process Improvement in Small Settings · Pascal Rabbath, S-3 Consulting ...

Documents

Transcript of A Field Guide for Process Improvement in Small Settings · Pascal Rabbath, S-3 Consulting ...