Fasil PM logoFasil PMProject & IT ConsultancyBook a call

Responsibility Without Authority Is the Oldest PM Trap.

Sprint velocity 33 percent below baseline. Two strong technical leads each accountable for the same gap. The RACI conversation that should have happened in Phase 1.

Programme
Project Falcon
Organisation
Atlas Bank
Phase
Execution
Template
RACI Matrix
AI prompt
RACI Draft (APE)
Post 11 of 22 following Project Falcon at Atlas Bank. Full program context is in Post 01. Previously, the July Status Report (Post 10) carried the M3a checkpoint as Red and the microservices platform as Amber, citing sprint velocity 32 points actual against a 48-point baseline for two consecutive sprints. The Red is in recovery via the R07 indexing work. The Amber needed its own diagnosis.

Two Sprints Below Baseline. Same Cause Both Times.

The microservices platform was the unsung star of Phase 2 until sprint 11. Sprints 7 through 10 had averaged 50 points, slightly above baseline. Sprint 11 closed at 32 points. Sprint 12 closed at 32. Two data points are not yet a trend. They are also not yet a coincidence.

Sprint Velocity, Microservices Platform
Story points completed per sprint, 2-week sprint cadence. Baseline = 48 points (capacity reference).
BASELINE 48
50
S07
52
S08
50
S09
48
S10
32
S11
32
S12
38
S13*
42
S14*
44
S15*
On baseline Amber (S11–S12) Recovery / Green (post-RACI) *Sprints 13–15 forward-projected at time of post; actuals confirm trajectory.

The PM booked forty-five minutes with Priya Raman (Technical Lead) and Jin-ho Park (Development Lead) on 4 August. The conversation did not need to be longer than that. Within fifteen minutes, both engineers had described the same root cause from their two different vantage points.

Raman: “Every sprint, we lose three to four days arguing about who owns the Splunk integration, who owns the Dynatrace dashboards, who writes the trace correlation IDs. There is no decision authority. Every call is a committee.”
Park: “We built fast through sprint 10 because the observability stack wasn’t exercising the cracks yet. Now that we are integrating across services, every cross-cutting concern surfaces an ownership question. The team is doing engineering for two days and politics for three.”
Velocity does not collapse from skill. It collapses from ambiguity.

The Falcon program had no RACI matrix. The charter (Post 02) had named decision authority at program level. The Stakeholder Register (Post 03) had tiered governance. But no artifact spelled out, at the activity level, who is Responsible for executing each piece of cross-cutting work, who is Accountable for the outcome, who must be Consulted, and who must be Informed. For the first ten sprints this had not mattered. By sprint 11 it mattered enough to cost 33 percent of velocity.

One Activity Was Actually Four.

The first instinct was to draft a RACI with one line called “Observability” and assign it to a single team. That was the wrong instinct, and the conversation with Raman and Park made it visible quickly. Observability on a 19-microservice platform is not one activity. It is at least four, and they have different natural ownership.

Observability Stack — Activity Decomposition
Each layer has a different natural owner. A single RACI line conflates them; four RACI lines resolve them.
OBSERVABILITY STACK

Logs Splunk Service-owned Per-service log shape, retention, redaction R: Park (Dev)

APM Dashboards Dynatrace Platform-owned Cross-service views, SLI / SLO definitions R: Raman (Plat)

Distributed Tracing Zipkin Shared ownership Platform: instrumentation Services: trace ID propagation R: Raman + Park

Quality Gates SonarQube Platform + Service Platform owns gates; services own compliance R: Raman

Logs are service-owned. Each microservice writes its own logs and decides what to log, what to redact, and how long to retain. The platform team can publish logging conventions, but the service team executes.

APM dashboards are platform-owned. Cross-service views require a single source of definitions for SLIs and SLOs. Asking each service team to define its own dashboards produces 19 incompatible dashboards. Platform owns this; services consume it.

Distributed tracing is shared. The platform owns the instrumentation library and the trace collector. Each service is responsible for propagating trace IDs correctly across its calls. Neither owns it alone.

Quality gates are platform-defined, service-enforced. Platform sets the gate thresholds. Each service team is responsible for keeping their service compliant. Platform cannot enforce; services cannot define.

Four activities. Four ownership patterns. One was being treated as one.

The decomposition was the unlock. Once observability was four lines instead of one, R/A/C/I assignments became obvious. The next morning the PM scheduled a working session with Raman, Park, Hassan, and Volkov to author the matrix.

Volkov’s Team Was Also Writing Microservices.

The integrator team was building several of the 19 services. The question that surfaced in the working session: do they own observability for their own services, or is it a platform-applied responsibility uniform across all services?

Volkov argued for the first. His position was contractual: the integrator scope is what is in the contract; observability for vendor-built services is what was scoped. Alemu argued for the second. His position was operational: Atlas Bank carries the readiness consequence at go-live; uniform observability is a precondition for production support, regardless of which team wrote which service.

Both were correct from where they sat. The resolution was procedural, not commercial. Vendor team gets a named role on the RACI matrix, distinct from Park’s development team. Where the contract scoped a vendor responsibility, the cell carries an explicit contract clause reference. Where Atlas Bank applied responsibility on top, the cell shows it as a platform-uniform requirement with the vendor as Consulted, not Responsible. The RACI did not relitigate the contract; it documented where contract met operational reality.

Five roles on the matrix, not three

Platform Team (Raman) · Development Team (Park) · Integrator Team (Volkov, with contract clause references where applicable) · CTO Function (Alemu, Accountable on cross-service concerns) · PMO (Hassan, Informed on operational matters; Consulted on governance changes).

Drafting the RACI

Prompt framework: APE

The prompt below uses APE: Action, Purpose, Expectation. Lightest framework used in the series so far. RACI drafting does not need elaborate context, audience segmentation, or worked examples; the activity is bounded (identify activities, assign roles), the structure is fixed (matrix), and the validation is operational (named stakeholders sign or push back). Framework complexity matching task complexity, extended principle: sometimes the right framework is the minimum framework.

Prompt
ACTION. Build a RACI matrix for the Project Falcon microservices platform covering activities where ownership ambiguity has been observed. Decompose Observability into four sub-activities: Logs, APM Dashboards, Distributed Tracing, Quality Gates. Add other cross-cutting activities the program is likely encountering: deployment to production, incident response, capacity planning, security patching, dependency upgrades. Five role columns: Platform Team, Development Team, Integrator Team, CTO Function, PMO. PURPOSE. Resolve the velocity drop attributed to ownership ambiguity (sprints 11 and 12 at 32 points vs 48 baseline). RACI must be operational, defensible at audit, and clear enough that any observer can identify who is Responsible, Accountable, Consulted, or Informed for any cell. EXPECTATION. RACI matrix as a structured table. Every cell has exactly one of R, A, C, I, or blank (not applicable). Distinguish R (Responsible, executes) from A (Accountable, owns the outcome). Tighten C (must be reviewed before decision) vs I (notified after decision). Where vendor responsibility is contractually scoped, indicate the contract clause reference. Flag any activity where the assignment is genuinely ambiguous and propose options for resolution.

RACI Draft, Extract

The AI produced a 12-row matrix. Three flagged items are shown below; the human edits resolved each before the matrix went to working session.

AI Response  ·  RACI Draft (Flagged Items)
Flagged for program manager review:

1. “Observability” treated as single row. Decomposition into Logs, APM, Tracing, Quality is correct; single-row treatment loses the ownership distinctions that resolve the velocity issue. Recommend four rows.

2. Accountable column applied to CTO Function across all observability activities. CTO is correctly Accountable for cross-service concerns (APM, Tracing platform layer, Quality gates definition). For per-service concerns (Logs, service-level Quality compliance), Development Lead (Park) is the more accurate Accountable, with CTO as Consulted. Recommend split.

3. C and I distinction soft. Several rows assign C (Consulted) where the actual practice is I (Informed). C means review before decision; I means notify after decision. Soft Cs become bottlenecks because reviewers expect input opportunity that the workflow does not actually provide. Recommend tightening.

A RACI that uses C as polite I produces meetings that resolve nothing.

The third flag was the one the PM had not seen coming. The instinct in regulated environments is to over-Consult; it feels safer. In practice, over-Consulting produces meetings where the Consulted parties expect to drive decisions they were never going to drive, and the velocity penalty is identical to no RACI at all. Tightening C versus I was the single edit that mattered most for sprint velocity recovery.

RACI Matrix v1.0, Extract

Published 15 August 2025. Eight rows shown across the 12-row matrix, focused on the observability stack and the three other cross-cutting activities where ownership ambiguity had cost velocity.

RACI Matrix
v1.0  ·  15 Aug 2025
Project Falcon: Microservices Platform RACI
Atlas Bank  ·  12 activities, 5 roles
Activity Platform
(Raman)
Development
(Park)
Integrator
(Volkov)
CTO Function
(Alemu)
PMO
(Hassan)
Service log shape and retentionPer-service logging policy and execution C R RPI-2024-11 cl. 4.2 A I
APM dashboards and SLI/SLO definitionsCross-service performance visibility R C I A I
Distributed tracing instrumentationTrace collector platform layer R C C A —
Trace ID propagation per serviceService-level trace continuity C R RPI-2024-11 cl. 4.2 A —
Quality gate thresholds (SonarQube)Platform-defined coverage, complexity gates R C I A —
Quality gate compliance per serviceService-level enforcement I R RPI-2024-11 cl. 5.1 A —
Production deployment release authorityPer-service deploy decisions C R R A I
Incident response (sev-1 and sev-2)On-call rotation, post-incident reviews R C C A I
R Responsible — executes the work A Accountable — owns the outcome C Consulted — reviews before decision I Informed — notified after decision
Review cadence. RACI reviewed at every quarterly risk review (Post 06 governance). Ownership disputes that cannot be resolved at working-group level escalate to steering with the disputed cells annotated. Vendor RACI cells with contract clause references require contract review before amendment.
What the human changed from the AI draft
  1. Decomposed Observability into four rows. AI flagged this as a candidate. PM made it the structural decision: Logs (service-owned), APM (platform-owned), Tracing (shared), Quality Gates (platform-defined, service-enforced). One ownership model did not fit all four; four rows resolved the ambiguity that two consecutive sprints could not.
  2. Split Accountable between Park and Alemu. AI assigned Alemu as A across the matrix. PM kept Alemu as A for cross-service concerns (APM, Tracing platform, Quality definition) but assigned Park as A for per-service concerns (Logs, Quality compliance). Accountability tracks consequence, not seniority.
  3. Tightened C versus I throughout. AI used C generously where I was operationally accurate. PM converted soft Cs to Is where the workflow did not actually require pre-decision review. Reduced expected meetings per cross-cutting decision from 4 to 2 in the most affected areas.
  4. Added Integrator Team as a distinct role with contract references. AI bundled vendor team into Development. PM separated, citing contract clauses (PI-2024-11 cl. 4.2 for service log responsibility, cl. 5.1 for quality compliance). Where vendor team carries R, the contract clause is referenced inline; where Atlas Bank applied responsibility on top, the cell shows operational rationale.
  5. Added quarterly review cadence. AI treated RACI as static. PM made it a living artifact: reviewed at every quarterly risk review (Post 06 governance), disputes escalated to steering. The microservices platform was the first beneficiary; future cross-cutting concerns (security patching, dependency upgrades) will be added as they surface.
September 2025 (Sprint 15), what happened

Sprint 13 (first sprint after RACI sign-off) closed at 38 story points. Sprint 14 closed at 42. Sprint 15 closed at 44 against the 48-point baseline. Not perfect, but the three-to-four-days-per-sprint ownership argument had gone. The September status report converted the microservices Amber to Green with rationale citing the RACI publication. The full 48-point baseline returned by sprint 17, when teams had internalised the matrix to the point where it stopped being a reference document and started being how they thought about responsibility. The RACI also surfaced in a subsequent vendor scope discussion: Volkov’s senior partner referenced the contract-clause cells when a downstream service was reassigned mid-Phase 2. Because the RACI made vendor scope explicit, the discussion was procedural rather than confrontational. The artifact is doing work the contract was never going to do alone.

The Takeaway
The cost of an unspoken RACI is paid in sprint velocity, every sprint.
A team without a RACI is not necessarily a team in conflict. Often it is a team of capable engineers spending a third of their time arbitrating ownership questions that should have been settled in Phase 1. The discipline is to write the matrix at the activity level, not the team level; to decompose composite activities into their natural ownership patterns; to distinguish R from A, and C from I, with operational seriousness; and to add the vendor as a named role with contract references where the work crosses commercial boundaries. Responsibility without authority is the oldest PM trap. Authority without explicit responsibility is a quieter, costlier version of the same trap.

A fictional case study for teaching purposes. Atlas Bank, Project Falcon and all named individuals are invented. Technologies are industry-standard and publicly available.