Structuring the PAT (Process Action Team) - Indus Net Technologies

We've been helping companies grow for over a decade! Check our success stories


Structuring the PAT (Process Action Team)

April 27, 2007 by Mainak Biswas under CMMi1,283 views
Share with your friends


The most important step that an organization faces while starting its process improvement effort is to decide on the right structure of its quality management system. Once that it done, the job of writing the processes starts which involves selection of process action teams who will be doing the documentation work.

The most common approach

The easiest to think way to do this, is to organize the team as following:


In this approach, you nominate one person (or a group of two) to take care of one individual process area. This seems like a good approach but there are a few problems:

  1. Since all process areas are interrelated to each other, it will lead to lot of confusion as it will not be clear how each document should relate the other documents within the QMS. 
  2. Creating 18 different procedure manuals, one for each process area does not sound like a good approach. On top of the 18 manuals, I reckon there will be several other manuals and guidelines and the structure itself looks messy. 
  3. The coordination amongst the team members will be very difficult as it is almost impossible to set out the dependencies between processes at the beginning of process writing stage itself.
  4. The possibility of duplication of work is very high.  

In order to address the problems, I started out by trying to define the interrelationship between the process areas. The diagram below represents, how (according to CMMI v 1.2) the process areas are related to each other.

Dependencies between process areas (PA)

It is very clear from the above diagram that there is very heavy interdependency between the process areas. Thus, allocating the responsibility of each process area to one individual will not work and it will lead to many “holes” that will surface only when the QMS is rolled out.

Thus, a better approach is required that will allow a team to work on group of processes that can be treated in greater degree of isolation. To do this, I tried to analyze the dependencies across rows and columns and found out that PI is the area that has the maximum number of dependencies across the rows and RD and PP has the maximum dependencies across the columns.

Based on analysis I think that instead of creating a team 11 individual players, it will be better to create 4 independent task-forces and each of task force will take care of a group of related process areas. Here is my recommendation for the same:

Task Force 1: RD, TS, PI, RM, VER, VAL
Task Force 2: PP, PMC, RSKM, IPM, DAR, SAM
Task Force 3: OPF, OPD, OT, MA
Task Force 4: PPQA, CM

I have documented the extent of dependencies below.

Task Force 1: RD, TS, PI, RM, VER, VAL

Process depencies within this group on other PAT:

  • RD on CM
    a.Ensuring that key work products are controlled and managed as per CM manual
  • TS on DAR
    a.Formal evaluation of alternative solutions must be done as per DAR
  • PI on SAM
    a.Information on acquiring product components or integration environment
  • PI on RSKM
    a.Identifying risks and the use of prototypes in risk mitigation
  • PI on CM
    a.Managing changes to interface definition
  • PI on DAR
    a.Formal evaluation for appropriate integration sequence
  • RM on PP
    a.How plans reflects the current requirements
  • RM on PMC
    a.Tracking and controlling activities and work products
  • RM to CM
    a.Configuration of changes to requirements
  • RM to RSKM
    a.Handling of risks related to requirements

Task Force 2: PP, PMC, RSKM, IPM, DAR, SAM

Dependencies with other teams

  • PP on RD
    a. Developing product requirements that define product and product component requirements
  • PP on TS
    a. Transforming requirements into solutions
  • PP on RM
    a. Managing requirements for planning and re-planning
  • IPM on OPD
    a. Information on organizational process assets and work environment
  • IPM on Verification
    a. Information on Peer Reviews

Task Force 3: OPF, OPD, OT, MA

Dependencies with other teams

  • OT on PP
    a. Training needs identified by project
  • OT on DAR
    a. How to determine training approaches

Task Force 4: PPQA & CM

Dependencies : None

Benefits of this approach

I see quite a few benefits of this approach:

  • The dependencies between processes are known at the outset and hence process writing will be more effective
  • Each task force can have an appointed head from the EPG who can then coordinate with heads of other task-force and iron-out dependencies
  • Although the organization can/will have many templates, checklists etc but at the core level there will be only 4 procedure manuals.
  • It may seem that the task forces are looking like 4 threads of CMMI i.e. Project Management, Process Management, Engineering and Support but this is a pure coincidence.


Share with your friends