Skip to content

Create CARES and External Dependencies

ContributorsPaul Atkins

Purpose

Generate a structured CARES section (Caveats, Assumptions, Risks, Exclusions) and an external dependency register from a remediation plan. The output is designed for direct inclusion in a Statement of Work.

Why CARES matters

Section Protects against Example
Caveats Over-reliance on estimates "Effort is T-shirt sized from a doc review, not a spike"
Assumptions Silent misunderstandings "Assumes 5 concurrent users — infrastructure sized accordingly"
Risks Unmanaged surprises "SQLite migration may reveal undocumented schema constraints"
Exclusions Scope creep "Load testing is excluded — can be added via change control"

Without CARES, the SoW either over-commits (missing exclusions) or under-protects (missing assumptions and risks).

Prerequisites

  1. Remediation plan — phased work items with effort estimates and dependencies
  2. Gap analysis — provides context for what's known vs. assumed
  3. Input register (optional) — unknowns and inconsistencies feed directly into assumptions

Instructions

Step 1 — Extract caveats

Caveats describe limits on the accuracy of the plan. Scan for:

  • Assessment methodology (doc-based vs. codebase-inspected vs. live-tested)
  • Estimate basis (T-shirt from doc review vs. spike-based)
  • Scope of assessment (did we see all the code? all environments?)
  • Time constraints (assessment done in N days, not exhaustive)
### 4.1 Caveats

1. **Assessment basis** — Gap analysis was performed against [source].
   Findings may change when verified against the live codebase.
2. **Effort estimates** — T-shirt sizes are indicative, based on
   [methodology]. Actual effort may vary ±30%.
3. [additional caveats]

Step 2 — Extract assumptions

For every assumption in the plan (stated or implied):

  1. State the assumption clearly.
  2. Add "Impact if Wrong" — what changes if this assumption is false.
  3. Check the input register for assumptions that have been confirmed as facts — remove those.
### 4.2 Assumptions

| # | Assumption | Impact if Wrong |
|---|-----------|----------------|
| A1 | Source code access will be granted before Phase 1 begins | Phase 0 extended; all phases shift |
| A2 | Concurrent users ≤ 5 | Infrastructure sizing in Phase 2 may need revision |
| A3 | Azure DevOps project exists with pipelines enabled | Phase 1 blocked until Central IT provisions |

Source priority for assumptions: - Input register unknowns with action "Assume" → become assumptions here - Gap analysis findings marked "assumed" or "unknown" - Plan items with effort estimates noted as "dependent on X"

Step 3 — Extract risks

Build a risk register from: - Gap analysis priority items (especially P0) - Plan items with external dependencies - Assumptions with high "Impact if Wrong" - Known technical debt or complexity

### 4.3 Risks

| # | Risk | Likelihood | Impact | Mitigation |
|---|------|-----------|--------|-----------|
| R1 | SQLite → PostgreSQL migration reveals undocumented constraints | Medium | High | Run diagnostic migration in Phase 0 before committing to approach |
| R2 | External dependency D3 delayed beyond Phase 1 start | Medium | High | Day-for-day slip clause in SoW |

Step 4 — Extract exclusions

Scan the gap analysis for items marked P3 or "out of scope". For each:

  1. State what is excluded.
  2. Explain why (not needed for this tier, deferred to future phase, etc.).
  3. Note how it can be added (change control process).
### 4.4 Exclusions

| # | Exclusion | Rationale |
|---|----------|-----------|
| E1 | Load / performance testing | T2 service; ≤5 users; can be added via change control |
| E2 | Mobile responsive design | Current users are desktop-only traders |
| E3 | Data migration from external systems | Out of scope; data connectivity is a separate workstream |

Step 5 — Build external dependency register

Scan every work item for references to teams, approvals, or decisions outside the delivery team. For each:

### External Dependencies

| ID | Dependency | Owner | Blocks | Required by | Detail |
|----|-----------|-------|--------|-------------|--------|
| D1 | Source code access | Business owner | Phase 0 | Week 0 | Git clone access or repo transfer |
| D2 | Azure DevOps project | Central IT | Phase 1A | Week 2 | Project with pipelines, ACR, service connections |
| D3 | Service tier classification | TDA | Phase 2A | Week 6 | Determines SLA, monitoring, infrastructure |

Categorise dependencies:

Category Examples
Business decisions IP, ownership, access, budget
TDA Technology choices, architecture patterns
Central IT / Platform Azure provisioning, DevOps, identity
Data / Architecture Data connectivity, ETL, database technology
Security Access policies, secret management

Step 6 — Cross-reference with plan

Verify every dependency and assumption traces back to at least one plan item. Flag any that are orphaned (no plan item references them) or any plan items that reference dependencies not in the register.

Output

CARES and external dependencies should be: 1. Added as a section in the remediation plan (Sections 4 and 5) 2. Extracted into the SoW (by the create-sow skill)

Tips

  • Assumptions are not facts. If it's confirmed, state it as a fact and remove it from assumptions. Keeping confirmed facts as assumptions undermines credibility.
  • Every exclusion needs a rationale. "Out of scope" alone invites challenge. "Out of scope because T2 service with ≤5 users" is defensible.
  • Dependencies need owners. "Central IT" is better than "someone". A named team with a known provisioning process is best.
  • Risks without mitigations are complaints, not risk management. Every risk needs at least one mitigation, even if it's "accept and monitor".

Troubleshooting

Error: CARES section feels disconnected from the plan. Cause: Assumptions and risks were written independently rather than extracted from plan items. Solution: Walk each plan item and ask "what are we assuming here?" and "what could go wrong?" — every CARES entry should trace to at least one plan item.

Error: Exclusions are challenged by stakeholders as "missing scope". Cause: Exclusions lack rationale or don't explain how they can be added later. Solution: Every exclusion needs a reason ("T2 service with ≤5 users") and a path to inclusion ("can be added via change control").

Error: External dependency register is incomplete. Cause: Dependencies embedded in work item descriptions weren't surfaced. Solution: Search every work item for references to teams, approvals, or decisions outside the delivery team. Use keywords: "requires", "depends on", "blocked by", "pending".