Earlier this month in my post What is the Minimum Information You Need to Describe Your IT Projects? I mentioned that a “RACI” statement is a useful way to communicate project responsibilities:
Who has ultimate Responsibility, who has Authority to make decisions, who must be Consulted about major actions or decisions, and who must be Informed about major actions or decisions.
RACI is pretty standard stuff. It is especially useful when projects become more complex. A RACI analysis not only helps define responsibility, it also helps formalize relationship and communication patterns. Given that communication is a key element in any project, deciding who needs to know about what — and when — is always a Very Good Thing.
Another use for RACI analysis is for describing software applications in a corporate business application portfolio. If changes or upgrades are being contemplated for a business application, the RACI analysis helps management decide who needs to be informed and consulted about the changes. (Side note: if you are creating or formalizing an application portfolio or software asset management system and cannot locate who owns and/or is responsible for all applications taking up processing power, space, and support costs, you may be in for some trouble as you attempt to change or consolidate your application portfolio!)
RACI can also be used, according to Wikipedia, in service contracts associated with Service-Oriented Architecture (SOA) development. The concept of a service contract is relevant here since with SOA, according to Wikipedia, “…it is not how we execute the service that is the important aspect, but rather what that service does is most important.”
A RACI analysis helps to specify the network of individuals who impact — or are impacted by — the different elements of a move to a SOA. Here is how Wikipedia outlines the RACI portion of the SOA service contract (I like this description since it emphasizes communication):
- Responsible - The role is the person/team responsible for the deliverables of this contract/service. All versions of the contract
- Accountable - Ultimate Decision Maker in terms of this contract/service
- Consulted - Who must be consulted before action is taken on this contract/service. This is 2-way communication. These people have an impact on the decision and/or the execution of that decision.
- Informed - Who must be informed that a decision or action is being taken. This is a 1-way communication. These people are impacted by the decision or execution of that decision, but have no control over the action.
While many purely technical or architectural components of a corporate SOA may have little relevance or meaning to the business people that consume SOA based services, business people ultimately become involved as users — and owners — of the functionality and data provided to them. It is therefore likely that in many cases a SOA service contract will require that both business units and IT be included in the RACI network, and that the RACI analysis include rules that specify when business involvement is required.
Business unit involvement may be called for in system integration projects that address. among other things, data consistency and semantics, even if no direct user interface questions are being addressed. One possible example of this is cited by Chuck Allen of the HR-XML Consortium in his post titled Mashups and HR where he raises the issue of human resources data inconsistency that might have to be addressed at a more fundamental level than might be possible via a “mashup.”
Here is another hypothetical example: a manufacturing company wants to present to Web users a single view that combines a Google map with data on the geographic locations of the company’s local repair facilities. It knows it is possible to develop such an interface very rapidly using AJAX based methods to support a mashup of Google Maps with geographic data. But there are currently three different geo-coding methods used by different feeder systems in the company. Should the geo-coding data be standardized? How and where should the standardization of geographic coding take place? How closely should this standardization be coordinated by IT with with business units who might not use the web-delivered system but whose processes could be impacted by changes in how geographic information is maintained?
This type of issue, where data interchange, standards, and business process ripple effects all combine, is a good example of the value of undertaking a formal RACI analysis to make sure, from both functional and political perspectives, that the right people are involved with a project at the right time and place.
Copyright (c) 2006 by Dennis D. McDonald, Ph.D. Dennis is a Washington DC area consultant specializing in collaborative project management and new technology adoption. His clients have included the US Department of Veterans Affairs, the US Environmental Protection Agency, Jive Software, the National Library of Medicine, the National Academy of Engineering, Social Media Today and Oracle, and the World Bank Group. Contact Dennis via email at ddmcd@yahoo.com or by phone at 703-402-7382.
