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.