Resillion
Internal cheat sheet
RACI & Roles Cheat Sheet
A quick reference for clarifying who owns what across delivery, QA, product, engineering, governance, and stakeholders within Resillion engagements. Use it when a piece of work feels fuzzy, slow, or blocked by unclear ownership.
Role clarity
Decision support
Handoffs
Escalation
1
How To Use RACI
RACI works best when it is tied to a real decision, deliverable, or handoff. If the item cannot be named clearly, the roles will usually stay vague too.
1
Name the activity
Example: approve release scope, write test strategy, triage defects, or sign off go-live.
Example: approve release scope, write test strategy, triage defects, or sign off go-live.
2
Assign one A only
If more than one person is accountable, the decision usually gets stalled or duplicated.
If more than one person is accountable, the decision usually gets stalled or duplicated.
3
Keep R narrow
Multiple people can help, but make the primary doer obvious.
Multiple people can help, but make the primary doer obvious.
4
Use C and I sparingly
Too many consulted voices slow decisions and blur ownership.
Too many consulted voices slow decisions and blur ownership.
2
Role Definitions
Delivery
Coordinates timelines, dependencies, RAID, and decision checkpoints. Usually the main glue between teams.
QA
Defines test approach, coverage, evidence, risks, and quality signals. Challenges unclear acceptance criteria.
Product
Owns business priority, scope trade-offs, and customer value. Confirms what good looks like from the user perspective.
Engineering
Builds the solution, estimates effort, resolves technical constraints, and owns technical fixes or rollback options.
Governance
Checks standards, compliance, controls, and approvals. Often the final gate for policy-based decisions.
Stakeholders
Receive updates, make business decisions, and provide input on impact, timing, and operational readiness.
3
Common Decision Points
Scope
Priority
Test strategy
Release timing
Go-live
Rollback
Comms
Scope
Product is usually accountable, with delivery coordinating and engineering/QA consulted on feasibility and risk.
Product is usually accountable, with delivery coordinating and engineering/QA consulted on feasibility and risk.
Test approach
QA is accountable for the approach, with engineering consulted on technical coverage and delivery informed of impact.
QA is accountable for the approach, with engineering consulted on technical coverage and delivery informed of impact.
Release go/no-go
Delivery typically drives the checkpoint, but product or governance may own the final business approval depending on policy.
Delivery typically drives the checkpoint, but product or governance may own the final business approval depending on policy.
4
Handoffs That Need To Be Explicit
Handoffs are where RACI usually breaks down. Make the trigger, the owner, and the expected evidence explicit.
1
Requirements to build
Product confirms scope, engineering confirms feasibility, and QA confirms testability before work starts.
Product confirms scope, engineering confirms feasibility, and QA confirms testability before work starts.
2
Build to test
Engineering signals completion with notes, evidence, or a build link so QA can start with confidence.
Engineering signals completion with notes, evidence, or a build link so QA can start with confidence.
3
Test to release
QA provides execution status, defect summary, and residual risk so delivery can make a release call.
QA provides execution status, defect summary, and residual risk so delivery can make a release call.
4
Release to support
Delivery or operations confirms monitoring, rollback, contacts, and comms before handover.
Delivery or operations confirms monitoring, rollback, contacts, and comms before handover.
5
Escalation Guidance
Escalate when:
ownership is unclear, a decision is blocked, a risk is not being accepted, or a deadline is moving without agreement.
First stop
Talk to the named accountable owner and the delivery lead.
Talk to the named accountable owner and the delivery lead.
If still blocked
Move to the relevant manager, product lead, or governance owner with the decision and options documented.
Move to the relevant manager, product lead, or governance owner with the decision and options documented.
Urgent escalation
Use when go-live risk, compliance exposure, or customer impact needs an immediate decision.
Use when go-live risk, compliance exposure, or customer impact needs an immediate decision.
6
Sample RACI Matrix
Use this as a starting point and adjust the A column to fit your team and governance model.
| Activity | Delivery | QA | Product | Engineering | Governance | Stakeholders |
|---|---|---|---|---|---|---|
| Define release scope | R | C | A | C | I | I |
| Create test strategy | C | A | I | C | I | I |
| Build solution | I | C | I | A / R | I | I |
| Approve go-live | R | C | A | C | C | I |
| Manage rollback decision | R | C | A | C | I | I |
| Communicate outcome | A / R | C | C | I | I | I |
7
Anti-Patterns To Avoid
More than one A
Shared accountability often means nobody can make the call.
Shared accountability often means nobody can make the call.
Too many Cs
If everyone is consulted, the decision becomes a meeting instead of an outcome.
If everyone is consulted, the decision becomes a meeting instead of an outcome.
Roles without actions
A role label alone does not say what needs to happen or by when.
A role label alone does not say what needs to happen or by when.
8
Reusable Prompt Template
Use this to turn a vague ownership problem into a sharper RACI conversation.
Prompt
For the activity "[activity]", identify the single accountable owner, the responsible doer, who must be consulted, and who only needs to be informed. Also note any decision point, handoff, and escalation path if the owner is unclear.
For the activity "[activity]", identify the single accountable owner, the responsible doer, who must be consulted, and who only needs to be informed. Also note any decision point, handoff, and escalation path if the owner is unclear.
Decision ownership
Handover clarity
Risk control