Monday, January 21, 2008

Affinity Matrix for Project Teams

If you have ever done programming for a large development project then you know about affinity matrixes that define degrees of interaction between parts of an organization, helping inform the design process and optimize spatial arrangement. Okay, that’s old hat to architect’s, interior designers, and FM’s. But what if we thought of the affinity matrix a bit differently? What if we used the same concept to help understand project team relationships or identify knowledge matches and misses? Let me give you an example of what I’m thinking about.

Let’s say you are the Program Manager for a large project. You have internal division VP’s as your customers, and architects, contractors, and PM’s on your team. At the beginning of your project you would want to make sure everyone understands the team’s interdependencies. You might, for example, want to make sure the architects and consulting engineers are all in synch on information sharing. One way to understand if they are or not would be to survey them independently and record and plot their responses on a matrix. You could use different symbols for matched interfaces, expected but not provided interfaces, and unexpected but provided interfaces (the former representing unmet information sharing needs and the latter representing unplanned but beneficial communications that are occurring organically).

This matrix would be very simple, listing all team elements on both axis. You then survey each team member and ask them who they expect to give information to and who they expect to get it from. Next you plot each element’s response, and finally overlay them together. Where the groups have properly understood the requirements you have expectation matches, one expecting to get information from one who expects to give it. Where they differ you will have either unmet or unplanned information transfers. These represent opportunities to catch and correct communication gaps before they do damage, and to take advantage of information that would have been available but unrecognized earlier.

Identifying the mismatches is important, but deciding how to cure them is even more important. Sometimes curing may require a different reporting relationship, new communication protocols, or finding a common technology. One suggestion would be to form small teams to investigate and advise on critical mismatches that are discovered and, of course, communicating the issues and solutions is key.

Large projects are fun but no two are alike. The challenges differ, the clients differ, the teams differ. Never assume everyone has the same goal or expectation. Exercises like this one can be beneficial in identifying opportunities for disappointment before they happen.

No comments:

Post a Comment