Building a Defensible Project RACI Matrix

Why This Matters: The Silent Killer of Engineering Projects

Walk onto any Special Purpose Machinery (SPM) build floor — a special-purpose machine project line for confectionery, a CNC cell for defence component machining, a robotic welding station for armoured vehicle hulls — and ask five engineers the same question: "Who owns the sign-off on design changes?" You will get five different answers. That ambiguity is not a personality problem. It is a governance defect, and it is one of the most reliably lethal risks in heavy engineering project delivery.

The supplied source applies a one-accountable-owner convention to each activity. When accountability is shared, it is owned by no one. When roles are implied rather than documented, the first change request becomes a political negotiation rather than a controlled process.

This handbook treatment uses a source scenario — the construction of a special-purpose machine project (a depositing machine used in confectionery manufacturing) — and walks through how to build a defensible, supplied sixth-edition process framework-aligned Responsibility Assignment Matrix (RAM) using the RACI model. We will correct common first-draft errors, translate the structure into controlled governance language, and show how the artefact can strengthen role clarity and audit evidence.

Core principle: A RACI matrix is a governance record that makes action, decision, consultation and information responsibilities visible. It may form part of audit evidence, but it does not replace contractual delegations or approved role descriptions.

The "What": RACI, Defined Properly

The Responsibility Assignment Matrix (RAM) is a governance tool described in the supplied source that maps project work packages (from the WBS) against project roles. The RACI variant is the most widely adopted form, and each letter carries a precise, non-interchangeable meaning.

RACI role meanings used in the supplied source:

• R — Responsible: The person(s) who performs the work. Can be multiple.
• A — Accountable: The single person answerable for the correct and thorough completion of the deliverable. This handbook applies one per row; confirm the approved local convention.
• C — Consulted: Subject-matter experts whose two-way input is required before a decision is made.
• I — Informed: Parties kept up-to-date on progress or completion, typically after a decision, via one-way communication.

A Word on "L" (Lead)

It is common to see first-draft matrices include an "L" for Lead. This is not part of the standard RACI model and should be avoided in formal project documentation. If a person leads an activity, they are the R (Responsible). If they also own the outcome, they are the A (Accountable). Additional letters can create ambiguity unless they are defined, approved and reconciled with contractual role descriptions.

The special-purpose machine project: Case Context

The scenario under analysis is the build of a special-purpose machine project depositing machine for the food manufacturing industry. Each special-purpose machine project is constructed by a core team drawn from a small engineering firm, with the following key players:

Reporting Lines (as drafted)

Note the dual reporting line to the executive sponsor. This is a classic weak-matrix organisation (as described in the supplied source) where the Project Manager has limited authority over technical resources — a structure common in SME heavy engineering firms but one that carries specific RACI risks we will address below.

The "How": Building the special-purpose machine project RACI, Step by Step

Step 1: The Original Draft

The initial source submission proposed the following matrix:

This is a reasonable first pass, but it contains four defects that a PMO assessor or applicable contract framework contract administrator would flag immediately.

Step 2: Defect Analysis

Defect 1 — Non-standard letter "L": The "Lead" designation appears twice. In formal RACI, lead = R. Remove.

Defect 2 — Misplaced Accountability for Project Statement: The executive sponsor is marked A for both the Project Statement and Requirements Plan. Under supplied sixth-edition process framework, the Project Manager is accountable for the Project Charter and scope baseline. The executive sponsor (as sponsor) approves but is not accountable for delivery. The sponsor's role is typically A only for the initiation decision, not the document's content.

Defect 3 — Split Accountability on "Develop/Test/Inspection": project manager is marked A while engineering manager is R. This is defensible only if project manager has genuine technical authority. In a weak matrix where engineering manager reports directly to the executive sponsor on technical matters, engineering manager should be A for technical deliverables, with project manager as I (Informed) for schedule/cost impact.

Defect 4 — No Sponsor (executive sponsor) visibility on Installation: The executive sponsor is marked I on installation/tryouts, which is acceptable, but Customer/Client is entirely absent from the matrix. For an SPM delivered to an external food manufacturer, the customer acceptance signature is the single most important governance event in the project. It must appear.

Step 3: The Corrected, Publication-Grade RACI

Note the key structural changes:

• The Customer column is introduced, with A on Site Acceptance Test — the contractual ownership of "done".
• project manager (PM) is A for scope, change control, and closure coordination — the governance spine of the project.
• engineering manager (EM) is A for all technical deliverables — reflecting the weak-matrix reporting reality.
• executive sponsor (executive sponsor) is A only for Charter approval and formal closure — the classic sponsor footprint.
• No cell contains "L". No row has more than one A.

Common Pitfalls (and How to Avoid Them)

1. Multiple Accountables per row. The most frequent first-draft error. This handbook treats accountability as singular for clarity; splitting it is a governance vacuum.
2. PM marked A for technical deliverables in a weak matrix. If the PM lacks authority over engineering resources, they cannot genuinely be accountable for technical outcomes. Assign A to the functional manager and keep the PM as C or I.
3. Omitting the customer. If your project exists because someone is paying for an outcome, they should appear when their acceptance, consultation or information role is within scope — especially on acceptance activities.
4. Confusing C and I. Consulted is two-way and precedes the decision. Informed is one-way and follows it. Treating them as interchangeable destroys the communication plan.
5. No link to the WBS. A RACI floating free of the Work Breakdown Structure cannot be audited. Every row should map to a WBS element or deliverable.
6. Static documents. A RACI created during initiation and never revisited is soon obsolete. It should be controlled and reviewed whenever accountability changes and at agreed governance points.

Key Takeaways

• A RACI matrix is a governance artefact, not a formatting exercise. Every cell must be defensible under audit.
• One accountable owner per row is the convention applied in this handbook. Confirm the approved responsibility-matrix convention for the organisation and contract.
• Do not add letters such as L, S or V without an approved definition and a clear mapping to contractual responsibilities.
• In a weak matrix organisation, technical-deliverable accountability should be assigned to the role with the approved authority and control; in the source's weak-matrix example, that role is the functional manager.
• Include the customer on acceptance activities where the contract or approved governance assigns them an acceptance role; the controlling definition of completion remains the contract and acceptance criteria.
• The Project Manager's accountability footprint centres on scope, change control, integration, and closure — not on executing technical work.
• Every RACI row should trace to a WBS element. Traceability to a WBS element or controlled deliverable strengthens auditability.

Knowledge Check

1. In the corrected special-purpose machine project RACI, why is engineering manager (Engineering Manager) marked A for Factory Acceptance Test rather than project manager (Project Manager)?
2. What is the single structural error in the phrase "design engineer is Responsible and Lead for design changes"?
3. Under an applicable contract framework subcontract, which row of the RACI would an acquisition authority auditor examine first, and why?
4. If the executive sponsor (executive sponsor) insists on being marked A for all activities, what governance risk does this create?
5. Convert the original "Installation/Tryouts" row from the draft matrix into a two-row RACI split between FAT and SAT. Who is Accountable for each?

Applying the Guidance as a Controlled Practice

Use this subject as a decision aid, not as a label applied after the event. Start by defining the delivery problem, the people affected, the authority available and the consequences of a poor decision. Record assumptions before selecting an intervention. That simple discipline makes later review possible and prevents a preferred leadership style from being treated as the answer to every situation.

Six-Step Application Cycle

1. Define the trigger. State the decision, behaviour, team condition or delivery risk that requires attention. Separate observation from interpretation.
2. Map the context. Identify the project phase, task uncertainty, dependencies, stakeholder interests, time pressure, team capability and formal authority.
3. Choose a proportionate response. Select the smallest intervention capable of improving the condition. Explain why it fits the evidence and what alternatives were rejected.
4. Agree ownership and boundaries. Make decision rights, escalation points, review dates and non-negotiable safety or ethical limits visible to the people involved.
5. Act and observe. Monitor both delivery indicators and human signals such as challenge, information sharing, participation, trust and follow-through.
6. Review and adapt. Compare the result with the original intent. Retain, adjust or stop the intervention, and capture the learning for the next phase.

Evidence and Verification

Evidence should be proportionate to the project's risk and governance needs. A short decision note may be sufficient for a routine team adjustment; a high-consequence change may require sponsor approval, formal consultation, controlled records and a scheduled assurance review. Documentation must support judgement rather than replace it.

Review Questions

• What observable condition are we trying to change, and how will we know if it improves?
• Whose perspective is missing from the diagnosis or decision?
• Are authority, accountability and capability aligned, or are we asking someone to own an outcome they cannot control?
• Could the intervention suppress challenge, conceal risk or create dependency on one individual?
• What evidence will trigger escalation, adaptation or closure?

Practice boundary: Frameworks in this article organise thinking; they do not guarantee performance. Project context, contractual obligations, safety duties, workplace requirements and approved governance remain controlling.