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:
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.
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.
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:
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:
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:
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.