EPG and PAT Member Qualifications

Process Action Teams (PATs)

How do the PATs work? An EPG member leads a specific PAT. The PATs are conducted like the EPG ( charters , agendas , behaviors, tracking action items, etc.). No one sits on a PAT without receiving training in the process area under development; otherwise , the PAT member does not really know what is expected, what he is supposed to do, and so he makes it up as he goes along, straying from the CMMI. PAT member qualifications are the same as for the EPG, that is, qualified and motivated individuals.

If the EPG has not developed templates, before beginning this effort, a PAT might be created to do just that so that all of the PATs follow the same structure, reducing the need to rewrite documentation. Search Web sites to get several examples of everything, including blank templates for procedures. It is OK to use a DoD-based Web site and examples, even if you are not working in a DoD-based organization. The CMMI brings structure to an organization. The DoD thrives on structure. It has good stuff and it is free take a look! Start with the Software Engineering Institute's (SEI) two Web sites: www.sei.cmu.edu and seir.sei.cmu.edu. The latter Web site requires a password and log-on ID; it contains a bulletin board and recent articles.

The PATs need to generate PAT Charters, PAT Plans, and a CMMI compliance matrix that tracks back to the practices for each process area they are developing. This matrix ties activities to practices and specific people and dates. The matrix is used for status tracking, and to check on the extent of the documentation produced. PATs generally write the procedures and processes for the organization.

If I am on a PAT, how do I determine where to start? The EPG will determine which process areas to focus on first, based on the results of the SCAMPI. The PAT Lead (an EPG member) will determine which practices and associated findings to attack in which sequence, by reviewing complexity, available staff, skillsets of staff, etc. The PAT Lead works with his group , determining work assignments and the sequence of the work. The PAT Lead, working with the PAT members and the EPG, will ask the following questions:

• Can a practice be combined with another practice or practices into one document instead of several?

• What are the dependencies between the other practices in that process area and with other process areas?

• How do these activities tie in with activities of other PATs?

• Do we need to write procedures for all of the practices in the process area?

• Are we going to have a separate Metrics PAT that focuses on the Directing Implementation common feature?

Here is an example. Each process area has some sort of requirement for "objectively evaluating adherence." Are you going to have each PAT write a procedure documenting how this will be done, or will you try to write one overall, generic procedure for how to perform this function for all of the process areas, and a checklist for those items to review per process area? You can do this in whatever way makes sense for your organization, as long as the practices for each process area are covered.

Consider having each PAT initially write procedures for evaluating adherence reviews and for Directing Implementation. Then stop, gather what has been written, and keep the best and discard the rest. Start writing a generic tailoring procedure that can be used when deciding which procedures and which part of the procedures to use for which parts of your organization. This approach helps sell the procedures to the organization. You might define a large, medium, and small project, and what tailoring can be done based on this definition. Include a tailoring section in each procedure. However, little tailoring will be necessary if you write your procedures for the most common business practices. For example, if you are a large company that writes automobile insurance policies for millions of customers, and the programs that support this effort were written in the 1970s in COBOL, do not try to write procedures for tracking customer complaints via your brand-new intranet Web site. You are not in the Web site business you are in the automobile insurance business. And the procedures you write must be specific enough to be followed. That means they must be detailed. You cannot write detailed procedures for Web site customer service that can be used by the rest of the automobile insurance departments. Another example: if you are building weapons systems using nuclear missiles, do not think you can use the same procedures written for tracking financial accounts payable.

So, get the PATs working. After they get some experience with the CMMI, get all the PATs together. Discuss who is doing what. Draw a chart on how the work is fitting together. Draw a chart on what needs to be done, and where the connections are. Don't get too detailed; and don't get too excited when you find duplication of effort or work deferred to other PATs.

Whatever you choose will be wrong and you will have to backtrack. The PATs love deferring work to another PAT. It is not always fair or workable to have one PAT write documentation for all of the PATs to implement. Remember: you should just choose an approach, start out doing it one way or another, and then stop and see what you have and whether it is working.