Communications – RASCI approach

I am currently reading the book The Art of Scalability by Marty Abbott and Michael Fisher, both of them ex-eBay executives. An approach they have described to make sure the entire product development team stays on top of things caught my attention. The model they recommend to use is called the RASCI model. It stands for:

R – Responsible – Individual(s) responsible for a task, project or initiative.

A – Accountable – Individual(s) to whom R is accountable to for the completion of the task, project or initiative. This individual(s) will need to approve the task, project or initiative before it gets underway.

S – Supportive –  Individual(s) that will need to support the task by providing resources towards completion of the task, project or initiative.

C – Consulted – Individual(s) that may need to be consulted because they may have data or information that will be useful to complete the task, project or initiative.

I – Informed – Individual(s) that need to be notified or kept informed of the progress of the task. They do not need to be consulted or asked to provide input to the task, project or initiative.

I believe that communications is a root cause for many of the organizational problems. For whatever reason, there is a tipping point in an organization’s growth where communications is ignored because it is taken for granted – “of course everyone knows” is a bad assumption that often gets made – and the net result ends up to be big surprises, annoyances, discontent and frustration.

Given that we as software product managers have to communicate with most of the other departments in the company, I thought the RASCI approach would come in very handy. I have previously written a post where I believe that if there is no head or a date associated with any task, it is not getting done.

About the book

Full disclosure – I was send a free copy by Michael Fisher so that I can read it and write a review here. While I am still reading it, I like the novel approach they are recommending for creating a scalable company. Given that both of the authors are highly technical, I expected the book to be about how to architect your software such that it can scale and not have any performance degradation as the number of users grow. Instead, the book is more about how to create an organization that will scale when business grows. Based on what I have read so far, I do recommend that you check this book out.

Have any of you read the book? If yes, what are your thoughts and comments?

If you enjoyed this post, please consider leaving a comment or subscribing to the feed to receive future articles delivered to your feed reader or by subscribing by email via the text box in the right column.