RASCI for Project Decisions

When Enterprises embark on large projects, they build out a Project Team. This team consists of Stakeholders, Project Manager(s), EA, TA, SA, Implementation resources and Operations. The challenge happens when Project Decisions need to be made - who makes the call ?

Enter the RASCI. It is a matrix of the key roles, and who should be:

• Responsible
• Accountable
• Supportive
• Consulted
• Informed

Assuming we use the RASCI members as defined in the PMLC, we would end up with a table like this:

	Stakeholders	Project Manager	Business Analyst	Enterprise Architect	Solutions Architect	Technical Architect	CoE	Operations
Budget	R	A	S	C	I
Timeline	R	A	S	S	S	I
RACI	I	R	I	I	I	I	I
Project Charter	A	R	S	S	C	I	I	I
Project Plan	A	R	S	S	S	S	C	I
Functional Requirements	I	I	R	A	A	A	C	I
Non-Fuctional Requirements	I	I	R	A	A	A	C	I
Conceptual Acrhitecture		I	S	R	A	A	C	I
Logical Architecture			I	S	R	A	C	I
Physical Architecture				I	S	R	A	I
Detailed Build Plans					I	S	R	A
Runbooks & SOP						I	A	R

Now that the "theory" is out of the way, let's take a look at a practical example:

The project is building out network infrastructure to support a new group being added to the Enterprise. So possible questions which might arise are:

1. A Stakeholder doesn't want to change the Firewall Rules. Who is authoritative ?
• The Technical Architect "owns" the Physical Architecture, including decisions about their use & configuration
2. Who should be informed of a change in Project Scope ?
• Since the Scope is part of the Project Charter, the Project Manager is responsible to inform every role on the RASCI with a corresponding letter in the matrix. So everybody.
3. What is the role of the BA in the Detailed Build Plans ?
• None - there is no corresponding letter in the matrix

As you can see, the roles & responsibilities are clearly defined, so that everybody on the project can determine who "owns" the decision. That's not to say that the project Stakeholders won't over-rule some decisions, but in general they don't.

Business Service Model for IT

IT exists for one purpose: to provide the tools necessary to enable Business Activities. Like we saw in the CLAP Framework, Business Capabilities are made up of a number of discrete Business Activities. But it is in the delivery of the Business Capabilties as a Service that IT provides value to the Enterprise.

The model for a Business Service is clearly defined by the ITIL framework. In short, it is composed of People, Process and Technology. Certainly, the framework also describes the meta-data, which includes the Service Owner, the Service Consumer and the Service Provider.

Once the functional and non-functional requirements of the Business Capabilities are mapped out, the application and its underlying infrastructure become straightforward to build out. As I have posted about previously, the Project Management Life Cycle can be easily applied to deliver these capabilities to the Enterprise. Of course, more than one capability can be provided by a single service. Often many services get grouped together to form a broader service.

There is also another relationship hidden in a simple model like this one. The degree to which a process is repeatable (and can therefore be automated) has implications to the People part of the equation. The more highly repeatable and automated a process is, the lower the required skill-set for the labour, which should in turn lower the cost of the Service to the Enterprise.

Posted with Blogsy