Responsibility Allocation Matrix – RAM

Responsibility Allocation Matrix – RAM (#10 in the series How to Plan and Organize a Project)
By Michael D. Taylor

The RAM is a matrix which relates the project OBS to the WBS to help ensure that each element of the project’s WBS is assigned to a responsible individual. The primary purpose of using a RAM is to avoid role confusion on projects.

There can be three RAMs on any given project, those being, a) the Key Stakeholder RAM, b) the Project Management Team RAM (illustrated below), and c) individual Team RAMs. In each case, responsibilities can be defined in various ways using a simple number system. For instance, a “1” on the RAM would indicate that the individual has primary responsibility, a “2” would indicate that the individual must be consulted by the person who has primary responsibility, a “3” might indicate that the person may be consulted by the person who has primary responsibility, a “4” would indicate that the person has signature authority, and “5” would indicate that the individual is a back-up to the primary individual, etc.

Responsibility Allocation Matrix - RAM

Figure 1: Responsibility Allocation Matrix – RAM
Another way to define responsibilities is the RASCI Method, where, R=Responsible, owns the problem/task, A=Accountable, someone who must sign off on work before it is effective, S=Supportive, can provide resources or play a supportive role, C=Consulted, has information and/or capability needed to complete the work, I=Informed, must be notified of the results, but need not be consulted.

While RAMs can alleviate many forms of project role confusion they can also create confusion if not constructed properly. Three rules must be followed when constructing RAMs.

Rule No. 1: Every row must contain only one “1.” To have more than this would result in having more than one individual with primary responsibility. Each individual might assume that the other is taking the responsibility and thus no one will fulfill this role, or the two individuals may be in conflict with each other, each wanting to meet the responsibility their way.

Rule No. 2: Every column must contain at least one “1.” If an individual plays a key role on the project yet has no primary responsibility assigned it may mean that either a responsibility has been omitted from the RAM, or the individual has only a supportive role to the project.

Rule No. 3: Support functions must be included (2, 3, 4, etc.). To omit all supportive functions will destroy needed project synergy. Individuals will see only their primary responsibility and will be, in effect, “licensed” to ignore other vital supportive roles.

MICHAEL D. TAYLOR, M.S. in systems management, B.S. in electrical engineering, has more than 30 years of project, outsourcing, and engineering experience. He is principal of Systems Management Services, and has conducted project management training at the University of California, Santa Cruz Extension in their PPM Certificate program for over 13 years, and at companies such as Sun Microsystems, GTE, Siemens, TRW, Loral, Santa Clara Valley Water District, and Inprise. He also taught courses in the UCSC Extension Leadership and Management Program (LAMP), and was a guest speaker at the 2001 Santa Cruz Technology Symposium. His website is www.projectmgt.com.

PMHut Team

PMHut Team

PMHut.com is a website dedicated to providing PM articles, detailed project management software reviews, and the latest news for the most popular web-based collaboration tools.

2 Responses

  1. March 10, 2009

    […] RAM (Team Level) […]

  2. June 11, 2010

    […] Team roles (RAM). Since the role of a PMT is different than that of the other project teams confusion can easily set in. The most pragmatic way to address this unique role is to develop a PMT responsibility allocation matrix. […]

Leave a Reply