Section 3.5. Establishing the Process Team | Process Improvement Essentials: CMMI, Six SIGMA, and ISO 9001

3.5. Establishing the Process Team

You may need a process team to help carry out your initiative. Or you may not. It all depends on the scope of your program, on what you're trying to achieve. In this section, I'll present a generic look at what you might typically see in a traditional process team. You can establish the process improvement team by either appointing people within the organization or hiring from the outside. But either way, the job of the process team will (in general) encompass a threefold responsibility:

Interact with organizational stakeholders to shape a set of processes and procedures into a formal process program.
Set the program into place within the organization.
Monitor its long-term use throughout the organization.

All three of these are important jobs. They'll require that you put together a team composed of people with the process management skills required to get the jobs done and who have the ability to work together as an effective team.

Note: Because I'm presenting the considerations in this chapter sequentially, you might be wondering about a slight chicken-or-egg question at this point. The activities I've described earlier may benefit from the use of a team. On the other hand, you may not find need for a team until your organization is further along into the process. For some organizations, it may not be until more work is completed that you'll know the scope of you program and therefore the kinds of people you'll need long-term on your team. On the other hand, if you don't bring someone onboard earlier, you may not have resources to apply to the original design and scoping.The point is to not take the sequencing a rule. Rather, use the descriptions I provide of the team as a way to understand what kinds of people you may require to further your initiative, and then make a judgment as to when is the best time to bring them onboard.

When it comes to putting the team together, there are not a lot of fixed rules. In the field of process improvement, there are no specialized titles you must represent on the team. There is no set team size. There is no single proven structure. The size, makeup, and structure of your team is going to depend on several very qualitative traits, including the scope of your quality program, the resources that have been allocated to the team, and the current process maturity of your shop. There are, however, some guidelines you might follow.

It's helpful to remember that creating a process program is not administrative work. That's not to disparage administrators. But on more than a few occasions, I have been in situations where management moves to assign this work to office administrators. The best that I can think is that these people are looking at the process program from the outside in: as a stack of paper to be filled in and maybe sorteda forms-based task. This most recently happened to me at a company called IdeaMall. ^[*] The head of the project management officethere was even a PMI on his business cardsuggested to our design team that the group's administrative assistants be given process development duties as an "off-peak" job assignment. The administrative assistants I work with are typically tossed a lot of odd jobs in an organization, and most of them catch pretty well. But creating a quality program is not an odd job or an off-peak assignment. It is a specialized effort, and so it requires a specialized team. I still can't figure out why this misstep is so common, but I want to mention it here because it is so prevalent.

^[*] The name of this company and the names of the people associated with it have been changed.

When you begin to form your process team, you don't have to take on certified process engineers (but that's not a bad idea), and you don't have to bring in high-end consultants. But you do need to assign people who demonstrate an aptitude for the task at hand. They should show an interest in process improvement, have some working knowledge of process development, and know generally how the organization works. It's also a plus if those you select have sound writing and organizational abilities and can communicate well with other people.

The second guideline is this: there's a valid temptation in all organizations to first make the process team assignments part-time. That approach is easy to understand. I have been in a lot of IT shops, and just about all of them are as busy as they've ever been. They would like to avoid staff fluctuations as much as possible. So there's always an effort up front to see if the work can be handled by existing resources.

Many times, membership on the process team can be a part-time job. That's the smart path to take. It can work well that way. But before you make the assignments part-time, make a sincere effort to make sure the job is part-time. Naturally, you'll need to use your judgment here. If you plan to begin with a very targeted and limited process program, you may be able to take it on as a part-time project. If your goals or needs are more ambitious, then recognize that the team will probably need a full-time focus for its tasks. Without that focus, the team and its efforts could easily evaporate in deference to other duties.

3.5.1. Team Roles

Here's a calculation you may run across in mature configuration-management shops: you need 1 system administrator for every 100 or so programmers. There's a similar yardstick for web-centric test teams: for a normal test cycle, 1 tester for every 25 screens. I don't know how useful those formulas prove to be, but I do know that we don't have any guides like that yet for process initiatives. That begs the question, what size team do we need? And, what kind of team do we assemble?

Those aren't questions anyone can answer straightaway. There are too many variables attached to a specific answer. I can offer some advice. Your process initiative should be treated, by and large, like almost any technology project. And so you'll need to account for some well-defined roles. Let's take a looka very brief lookat what these key ones might be.

Job roles and titles vary greatly across organizations. Even seemingly standardized job types like "Java developer" or "software designer" don't mean much outside a specific work environment. This is especially true with process improvement jobs. Job titles, and the subsequent job descriptions that go along with them, haven't really become standardized. At the same time, when you begin to staff your process team, you'll need to assemble something of a hierarchy of talent to ensure that the right blend of skills and the right capabilities are in place to carry your program forward. To help with this, here is a basic list of some traditional process-team job roles, together with a general description of typical skills and experience.

Note: The following descriptions are presented to give you a feeling for the kinds of jobs that can be accounted for on a process team. If you find them helpful, use them. But don't think that you are required to explicitly assign these roles to your process team. Bottom line, look for people with good communication skills (especially writing skills), good analytical skills, and the ability to work well in a team.

Process architect

This is a senior position on the process team, a technical one that requires both strategic and tactical abilities. Process architects are the people who will design the form and function of your process program. If you are creating a program to fit a certain modellike ISO 9001, CMMI, or Six Sigmathe architects will need to be well versed in the model's components, requirements, and implementation methods. Process architects also need to work with a solid understanding of the current business environment, as the program they design will need to exist within that environment. Additionally, process architects should posses the attributes of any good strategist: solid communication skills, sound analysis and synthesis abilities, good management and planning skills, and the ability to work with varied levels of management.

Process engineer

The job of a process engineer is to take the program design and turn it into a series of discrete yet integrated program components. This requires an understanding of the architecture at large; an understanding of the goals, objectives, and scope of the process initiative; and the ability to assign a series of clearly identified assets and artifacts needed to realize the goals and objectives. Process engineers need the ability to work well with focused teams, interface with a variety of stakeholders, and manage activities across independent work groups.

Process analyst

A process analyst usually deals with delineating the detailed steps required to effectively execute processes and procedures, and then turning these into effective process tools via descriptions, flowcharts, forms, templates, etc. Operating under the direction of a process engineer, the analyst will manage a set of process activities, work with organizational stakeholders and users to elicit needs, formulate the data into initial artifacts, and then review these artifacts for refinement and (ultimately) approval and acceptance.

Technical writer

Many people make the mistake of thinking that creating a process program is a documentation job. As we'll see later on in this chapter, that's something of a narrow view. However, the job of documentation is an important one. The success of your process program will rely heavily on the quality of the documentation you create to realize it and support it. Appointing technical writers to your team can help you manage the documentation you'll need to publish. This can take three general forms: paper-based manuals, templates, and forms; electronic reference material; and training, overview, and presentation materials.

A good technical writer will show developed written communications skills, good investigative abilities combined with interpersonal skills, a sense of layout and design, and proficiency in a set of publishing, presentation, and support tools.

3.5.2. Defining an Improvement Charter

When organizations set up a process improvement initiative, I like to see management officially define the project through some type of charter. A charter is a document that formally establishes the mission, makeup, and purpose of the project. In my opinion, all focused group activities in a company should be guided by a charter. Charters can be helpful for several reasons, which I outline next:

It is an agreement between you and management: A charter will help you understand the mission of the process initiative from management's perspective. In many ways, it can be seen as a contract between you and management. And because the charter is in writing, it is an agreement that can be commonly understood by both you and management. This is a real advantage. If you begin an initiative with only a verbal understanding of the task, there is a strong chance that as the mission progresses over time, understandings can drift apart. If the charter is there for both parties to reference and fall back on, you and management will likely be able to stay in sync as the project evolves.
It defines the boundaries and goals of your mission: One of the main benefits of a charter is that it can define the purpose of the initiative, establishing the boundaries of your activities and the goals you are expected to achieve. In other words, the charter can help you define what success will mean for your initiative, and what resources will be committed to help you achieve that success. This is especially helpful in a process initiative because progress early on can be somewhat intangible, hard to pin down. Without the benefit of a fixed focus, process efforts can be prone to shift in both scope and purpose. A charter will help you fix that focus to everyone's mutual agreement.
It serves as an official authorization mechanism: The best value of the charter may be in its power to serve as official authorization for your process initiative. You may be asked to create the charter for your project, but management will ultimately need to endorse it. And this endorsement makes the project "real" to everybody in your shop. In the absence of this endorsement, the project may float about the company as an idea, or it may roll through the organization as a potential, but it probably won't have the traction it needs to really get rolling. The charter can give it the traction it needs.

For your process program, you might find that a charter is good way to demonstrably fix what it is you want your initiative to achieve, and how you plan to achieve it. So consider working with management to define a charter for your process program initiative.

Charters should not be complex documents. In fact, it's better if they are brief and to the point. You can format your improvement charter using some points usually found in typical business charters. Consider defining the following for your project:

Purpose: The purpose statement should reflect the general strategic intention of your program. The scope statement (see next) can be more tactical. A purpose statement might read something like, "The purpose of the QED Process Initiative is to improve the organization's ability to meet regulatory deadlines, promote consistency across planning and release cycles, and provide mechanisms for measuring project performance across IT working units." That kind of statement is focused on the benefits the program is designed to deliver, and by tying these benefits to larger business objectives, the program becomes integrated into core business activities of the organization.
Scope: The purpose and scope statements you create for the charter may be closely related. In the scope statement, you might define the scope of the improvement program using a tactical description of the reach of the project. An example could be, "The scope of the QED Process Initiative is to design and implement procedures, tools, and controls to manage requirements definition, change control, and project planning activities in the IT Services organization." That's a pretty targeted statement, yet it allows for specific refinement at a later date. At this point in your program development, you'll probably have a similar idea of where you'd like to focus your program. Shape the statement around this expectation; you can refine it with greater detail at a later date if you choose as the project evolves.
Sponsor: Identifying the sponsor for the improvement charter is an important institutionalization step. So, consider documenting two sponsor traits here. First, attach an organizational position to the sponsor role. This might be something like Chief Process Officer, V.P. Quality Delivery, or Director of New Initiatives. Whatever is, the role links sponsorship to the organizational chain; it gives it a place within the structure of the organization. Second, and you might see this as being optional, you can identify the name of the executive holding the sponsorship position. This puts a known face to the role, and even though sponsors may change over time, it helps to give a sense of personality and ownership to your program.
Resources: You might also call this section "organization." Here in the charter, you describe how this initiative will be organized. Without going into great detail, you might describe the resources planned to support the program: team size, general team roles, and any special facilities needed. Describing the resources helps solidify executive commitment to the program. Without a firm commitment to allocating resources to the improvement program, the program might never materialize past the charter stage.
Effective dates: The improvement charter should not be thought of as a one-time, fixed document. The work it reflects is too evolutionary. So assign the charter an effective operational range: a start date and an expiration date. The expiration date will establish a benchmark for reviewing the charter and refining it as necessary.

A charter that contains the kinds of details described above will help solidify the initiative in the minds of management, you, and other members in the organization.

As mentioned earlier, you will probably be the one asked to come up with the charter if you think it's important for your project and your team. If so here are some general steps you can follow to instantiate it in your IT shop:

Work with your sponsor and executive management to define the details of the initiative (see the charter points described earlier).
Create a draft of the charter.
Review this draft with management and revise as necessary.
Seek official management approval of the charter.
Make the charter available to the organization at large.
Use the charter as a benchmark for ongoing project work.

At this point in establishing your process program, I've discussed key activities that can work to set the initiative on its way. I've discussed assessing the organization's current quality position and business objectives, as well as targeting potential improvement opportunities. Within this scope, I've discussed obtaining executive sponsorship for the program and, by implication, receiving corporate buy-in. I've looked at some typical process team roles you may want to accommodate as you formulate a process team. And now I've looked at a way to formally shape the program through an authorized organizational charter.

The improvement charter will help set in place the infrastructure you'll need to make your program a going concern in the enterprise. Just as important, it positions you to begin to take real improvement steps: sending your people out into the organization to assess targeted process capabilities.