Saturday, September 24, 2011

Who Does What? Using Extended RACI Charts

One of the challenges for any product manager is making sure that things that are supposed to be done actually get done. This is why I sometimes describe product managers as 'Chief Cat-herders'. Before you can start tracking that tasks are completed on time, you need to agree who is responsible for performing these task in the first place. Without this, the tasks will not be completed as everyone will be thinking that someone else is doing the work. This is where RACI charts are useful...

The term RACI is an acronym for Responsible, Accountable, Consulted, and Informed. One or more of these properties are assigned to each task that needs to be performed during the various phases of a product development and release cycle. That is, for each task, someone is responsible for performing that task, someone is accountable for the task being completed, one or more people might be consulted about the task, and one or more people might be informed about the task. Note that a given individual might be assigned more than one property for the task i.e. they might be accountable and responsible (they are accountable more the task being completed and they do the work to complete the task).

In addition to the assignments of RACI, I have found it useful to extend RACI to add a Verify and Sign off properties - hence the term 'extended RACI chart'. In the past, I have found that we have needed someone to verify the output of a task or that it has been completed fully. You could argue that the person accountable for the task should do this, but more than once I  found that a task was reported as complete and later it turned out that, although the task was technically complete, it was completed to the required quality. Therefore, we assigned someone to verify that the task was completed correctly. I also had a situation where the output of a task needed the approval of the company's executive team. An example of this is a product plan or a product release proposal document. So, I added a Sign off property to the task, indicating that it needed sign off approval by the appropriate person or persons.

The more formal descriptions of the extended RACI properties are:

R: Responsible The people who do the work to achieve the task. There is always at least one role of R, although this can also be delegated to others to carry out the work required, resulting in multiple R roles.
A: Accountable The person who is ultimately accountable for the correct and thorough completion of the deliverable or task, and the one to whom R is accountable. In other words, an A must approve the work that R provides. There must be one and only one A specified for each task or deliverable.
C: Consulted These are people whose opinions are sought. This is a two-way communication interaction.
I:  Informed People who are kept up-to-date on progress, often only on completion of the task or deliverable. One-way communication.
V: Verify The person (or people) who check whether the product meets the acceptance criteria set forth in the product description.
S: Sign Off Those who approve the the task completion.
Notes:   Sometimes the person responsible for achieving the task (the 'R' role) is also accountable for that task (the 'A' role). These instances are indicated by the letters 'AR' (accountable and responsible) in the appropriate cell.

I use a simple Excel spreadsheet to contain the extended RACI chart, with each product development and release phase put onto a separate tab. The phases I use are:
  1. Planning, Strategy, and Analysis - This phase contains all the tasks that are necessary for product planning, including requirement gathering and analysis, creating product plans, release plans, etc.
  2. Community Technology Preview (CTP) and Beta Programs - All the tasks associated with preparing for and running CTP ad Beta programs with selected customers.
  3. Product Release Readiness - All the tasks that need to be performed prior to the product being ready to ship to customers. This is not organizational readiness (which is covered by 4 and 5 below) but includes the tasks to prepare the product e.g. licensing agreements, physical packaging, printed documentation, bill of materials for shipping, SKUs in the sales and accounting systems, etc.
  4. Internal Readiness Program - This includes internal training of Sales, Support, Call Center staff, etc. as needed to prepare them for the new product.
  5. External Product Launch - Finally all of the tasks associated with launching the product to market e.g. press and analyst briefings, marketing and promotional materials, sales tools, whitepapers, etc.
For each of these phases, I put the list of tasks as rows in the spreadsheet and the list of roles as columns across the top. In my extended RACI chart I identify the following roles (by aware that this is from a software company and that the roles don't apply to all product activities):
  1. Executive Management
  2. Chief Technology Officer (CTO)
  3. Product Management
  4. Product Development
  5. Software Test (i.e. QA)
  6. Documentation
  7. Release Management
  8. Education Services
  9. Consulting Services
  10. Product Delivery (these are product installation and configuration consultants)
  11. Client Hosting Services (we ran SaaS hosted instances of the product on behalf of customers)
  12. Data Services
  13. Technical Support Services
  14. Project Management
  15. Sales
  16. Product Marketing
  17. Marketing Communications
  18. Business Development
  19. Beta Program Management
  20. Legal
  21. Finance
  22. Evangelism/Innovation
That's a big list of roles, but not every role is involved in each phase. This is my master list to ensure that every task is covered.

As you can imagine, the RACI chart can be quite large...in fact most of the sheets are too large to easily display a full sheet in this blog. However, here is an example of one of the sheets (the CTP/Beta Program sheet, in this case):






















Here you can see the task on the left hand side of the sheet (together with task IDs) and the roles on the top of the chart. From this single sheet it is easy to identify who is involved in the various tasks required to prepare and run a CTP program or a Beta program. You can identify who is accountable for the task, who is responsible for performing the task, who is consulted and who is informed. On this particular sheet there are no verify assignments, but there is a sign off assignment - the CTO has to sign off on the CTP Plan and Beta Plan.

If you can create extended RACI charts1 for your organization, detailing the tasks that need to be completed and the roles who are involved in these various tasks, it will help everyone understand their individual responsibilities to the product development and release process as a whole. Obviously, you need to sit down with the various department leads and walk them through the RACI chart and get them to agree their roles and assignments within the process. Once you get them to agree what they need to do, you also have a template list of tasks that can now be tracked to ensure that the product development and release is on schedule.


1 If I could attach a file to this blog, I would happily attach an example extended RACI chart spreadsheet to get you started. However, there doesn't seem to be a way of uploading files on Blogger.

Update (9/29) - I have uploaded the extended RACI chart spreadsheet to Google Docs and you can now view an example RACI chart. The CTP/Beta Program sheet is filled out as an example of what a RACI chart looks like. I have added conditional formatting to color code the cells according to the role assigned to them. The link for the spreadsheet is here. You can also download the RACI chart as an Excel spreadsheet, so that you can customize the tasks and stakeholders to suit your own organization.

2 comments:

  1. For a team trying to develop a new type of MEMS component, there are two main roles to fulfill: MEMS engineering and business. In this stage, a new technology has been created, a product opportunity has been identified, and a business is beginning to coalesce around the product opportunity. This is the point at which a start-up company would be incorporated, or a business unit team might be formed within an existing company. strategic thought leadership

    ReplyDelete
  2. The die-level integrated development costs are high because of many challenges. One is that the fabrication process of MEMS devices is different than that used for CMOS electronics. These two distinct wafer processes would need to be combined into a single fabrication process flow, which increases the total number of process steps, potentially adding risk and reducing overall wafer yield . Another challenge is that the MEMS and electronics are integrated, so they cannot be independently iterated and upgraded. A third is that the known good die problem cannot be addressed with test methods (more discussion below). thought leadership

    ReplyDelete