While many people who are interested in RACI, there is literally no definitive source of knowledge on this topic. Unlike SOA, which has the OASIS SOA Reference Model RACI has no normative definition. This blog post will help explain why and how this can be mitigated.
This blog is not trying to become that authority however, we will continue to share what we know as it evolves. Think about this as a point of reference. You can use it as a common resource to explain your own definition of RACI or DACI. If you disagree with some of the content on this site, at least you have a point of common reference to start with to explain how your definition varies. We also encourage your interaction by leaving comments to help the community change it’s thinking This pattern can be best described as a reference model requirements process.
In order to define RACI, there are really a few different components. In no certain order, here are the concepts.
1. The Roles – RAC is a role assignment matrix. the roles are used within a process of problem solving (ie – decision making). A normative definition of roles would be an integral part of any RACI definition.
2. The RACI process – when solving processes, there are specific methodologies and processes that may emerge as best practices. We have our ideas but invite others to help define this. Much like UML as a two dimensional syntax and a methodology (even Rational Rose makes this distinction with the Rose Unified Process or RUP), RACI has a process and methodology that make it much more useful.
3. Specifications and constraints for software – RACI does not have a normative specification. Most commercial off the shelf (COTS) software is developed based on a specification. Sometimes this is done as a reference implementation of a specification. Compliancy experts usually go through a formal specification and look for IETF RFC 2119 keywords such as “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” and use these words to create formal constraints and test conditions that any compliant software must be capable of supporting. Since RACI does not have that level of granularity defined, commercial and enterprise RACI software for RACI such as Whispr, do not have the luxury of that level of speciosity, the authors had to develop their software based on their perceptions.
4. The cardinality of the roles and the rules governing how they are assigned. For example, can a “Consulted” party also assume the role of Approver? This is not specified. Over the next few months, we will attempt to share our experiences of trying this different ways. Again, our ways are not correct, we will just share them with you via this blog.
5. The nuances and effects based on the size of the problem tackled. It has already become apparent that the use of RACI is much different when trying to account for a decision in a 10 person company with 3 people making the decisions than a 5,000 person enterprise with 3,000 contributors.
6. Best practices and implementation notes. As with any standard or idea, there are associated best practices that emerge as practitioners learn from their experiences.
To be transparent we, the writers of this blog, have developed our own software for RACI named Whispr. We are not trying to push our software in this blog, rather trying to help others discover the benefits of RACI and allow all RACI consultants to advertise their services on this forum. The reason we developed the RACI software is that we noticed after leaving a consulting gig for RACI, customers tended to fall back into their old patterns. The software, Whispr, helped keep them in their practice on a daily basis.
While we will write about Whispr, we will also offer to write up information about any other RACI or DACI software that exists. This blog is not our exclusive forum to promote what we have done, rather an independent forum for all RACI and DACI practitioners to share their experiences and wares in this area.
After all, business as usual is no longer an option as email inboxes continue to grow while productivity flails.
This blog is not trying to become that authority however, we will continue to share what we know as it evolves. Think about this as a point of reference. You can use it as a common resource to explain your own definition of RACI or DACI. If you disagree with some of the content on this site, at least you have a point of common reference to start with to explain how your definition varies. We also encourage your interaction by leaving comments to help the community change it’s thinking This pattern can be best described as a reference model requirements process.
In order to define RACI, there are really a few different components. In no certain order, here are the concepts.
1. The Roles – RAC is a role assignment matrix. the roles are used within a process of problem solving (ie – decision making). A normative definition of roles would be an integral part of any RACI definition.
2. The RACI process – when solving processes, there are specific methodologies and processes that may emerge as best practices. We have our ideas but invite others to help define this. Much like UML as a two dimensional syntax and a methodology (even Rational Rose makes this distinction with the Rose Unified Process or RUP), RACI has a process and methodology that make it much more useful.
3. Specifications and constraints for software – RACI does not have a normative specification. Most commercial off the shelf (COTS) software is developed based on a specification. Sometimes this is done as a reference implementation of a specification. Compliancy experts usually go through a formal specification and look for IETF RFC 2119 keywords such as “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” and use these words to create formal constraints and test conditions that any compliant software must be capable of supporting. Since RACI does not have that level of granularity defined, commercial and enterprise RACI software for RACI such as Whispr, do not have the luxury of that level of speciosity, the authors had to develop their software based on their perceptions.
4. The cardinality of the roles and the rules governing how they are assigned. For example, can a “Consulted” party also assume the role of Approver? This is not specified. Over the next few months, we will attempt to share our experiences of trying this different ways. Again, our ways are not correct, we will just share them with you via this blog.
5. The nuances and effects based on the size of the problem tackled. It has already become apparent that the use of RACI is much different when trying to account for a decision in a 10 person company with 3 people making the decisions than a 5,000 person enterprise with 3,000 contributors.
6. Best practices and implementation notes. As with any standard or idea, there are associated best practices that emerge as practitioners learn from their experiences.
To be transparent we, the writers of this blog, have developed our own software for RACI named Whispr. We are not trying to push our software in this blog, rather trying to help others discover the benefits of RACI and allow all RACI consultants to advertise their services on this forum. The reason we developed the RACI software is that we noticed after leaving a consulting gig for RACI, customers tended to fall back into their old patterns. The software, Whispr, helped keep them in their practice on a daily basis.
While we will write about Whispr, we will also offer to write up information about any other RACI or DACI software that exists. This blog is not our exclusive forum to promote what we have done, rather an independent forum for all RACI and DACI practitioners to share their experiences and wares in this area.
After all, business as usual is no longer an option as email inboxes continue to grow while productivity flails.
