Section 4.5. 5. Support Compliance

4.5. 5. Support Compliance

I work pretty regularly with two process consultants, Kricket Ichwantoro and Nicole Whitelaw. I bring Kricket and Nicole in on lots of different kinds of jobs. They're great program developers, they're really strong at pre-assessments, and they know how to accurately gauge the scope of how much process is right for particular groups. But what I like to use them most for is what I call Project Quality Assurance. Depending on the improvement model or the industry it's in, Project Quality Assurance goes by other names: auditor, inspector, assessor, etc.

4.5.1. The Job of Project Quality Assurance

The job of Project Quality Assurance (PQA) is straightforward enough: keep the project team on process. (This role is directly called out both in ISO 9001 and in CMMI.) In the effort to institutionalize a process program, this may be one of the most neglected or least appreciated roles. People might logically assume that since a process program represents a way to do business, people should follow that way without much prodding. Or they may think that the addition of people to oversee the use of the program amounts to unnecessary overhead. Or that maybe it implies distrust.

While I can understand those attitudes (at least a little bit), I've got to maintain that they aren't completely accurate. Not only is the role of Project Quality Assurance essential to sustaining a process program, the job of the PQA analyst may be paramount.

Follow Kricket Ichwantoro and Nicole Whitelaw around on a project, and you'll see what I mean. The first job of the PQA analysts is to know the process program inside and out. Since they are key to making sure everyone on the project team is able to conduct their jobs according to the procedures and activities of the program, they will need a deep, workable understanding of the program.

Next, the PQA analysts actively help plan the project. The project manager probably takes a planning view that focuses heavily on budget, schedule, and resources. The PQA analysts can complement this view. Working with the project manager, they can help provide a compliance plan for the projectone that details what key activities will be monitored over the course of the project, what work products will be required for delivery, what artifacts will be expected to be produced. This plan represents a compliance contract for the project team. It defines what compliance means. And it serves as an aid to the project manager who is also responsible for following established processes.

Then, during the various project phases, the PQA analysts execute the PQA plan. They are involved with the project team. They announce scheduled audits well in advance, perform the audits in accordance with current standards, note issues of noncompliance, and then help the team get back into compliance where needed or document the valid reasons for being out of compliance. Regularly they release summaries of all their audit reports, noting areas of strong performance and areas where performance might be improved.

If every IT project had a Kricket or Nicole working with it, team members would quickly see that process, when well planned and designed, does not interfere with project work. It complements it. It promotes it. It serves as an aid to using consistent solutions for moving in predictable directions, along a clear-cut path.

When an organization supports its process program by instantiating the role of Project Quality Assurance analyst, it sets up a framework of dependability, one that different project teams can use to not only make sure they stay on process but also to help saturate process into their teams, so that over time the program becomes a naturalalmost unnoticedway of doing business.

4.5.2. Provide Coaches, Not Cops

A great way to help sustain your process program is by supporting compliance, but there are different ways of approaching this task, some not as effective as others. One term that the improvement industry has unfortunately picked up over the years is "compliance cop." That's the person you think of as always looking over your shoulder, checking up on you, auditing you on a whim. The spirit most often associated with the compliance cop is that of catch-and-correct: catch someone doing something the wrong way and then push them (usually by consequence) into doing it the right way. I guess in basic training that approach might workthere, it's probably the smart approachbut in the business world, that approach is not going to be very effective. It will probably backfire.

The better approach is to set up your PQA analysts as process coaches. They should be charged with helping your people gradually grow into the program, not in a passive, observational way but in an active way, while engaged in the program, while using it.

When your PQA folks are seen in this supportive way, the issue of compliance changes. It moves from being perceived (perhaps) as an intrusion to a tool, one that might need some getting used to, but a tool nonetheless. And the PQA analysts themselves begin to be seen as a visible sign of executive commitment to the program. These analysts are not, per se, linked to the project teams. They are part of the organization at large, and their willingness to help the teams move through process, engage in process appropriately, and realize the benefits of the program communicates management belief in the program.

The success of your process program will hinge on its long-term adoption by the people in your company. If the program has been designed well, it will probably meet the business needs of the organization. The key then is to get people using it until it becomes habit, until it is the natural modus operandi of the culture. A very effective way to help this come about is through the use of PQA analysts. By seeding these process coaches within teams across the organization, projects can stay on process, people can work with and appreciate process program elements, and the benefits of the system can begin to saturate the organization.