Brainforge Knowledge

week-by-week-implementation-plan

4 min read

Head of Delivery — week-by-week implementation plan

Purpose: Roll out the delivery operating model in a deliberate sequence rather than trying to rewrite, socialize, and enforce everything at once.

This document is the practical implementation layer beneath the delivery-folder restructure plan.

1. Why the rollout is phased

This operating model is substantial. It affects:

  • standards
  • checkpoints
  • lifecycle
  • roles
  • supporting doctrine
  • leadership review habits

Trying to change all of those at once would create noise and reduce clarity. The rollout should prioritize doctrinal clarity first, then downstream alignment, then adoption and measurement.

2. Rollout logic

The sequence should be:

  1. Define the floor
  2. Define the checkpoints
  3. Define the lifecycle and systems of record
  4. Define how roles fit into that system
  5. Align supporting standards and examples
  6. Begin active adoption, review, and KPI thinking

This ordering protects the team from role confusion and document sprawl.

3. Week-by-week sequence

Week 1 — Establish the standard

Focus: Lock the shared standards doctrine.

Primary work:

  • rewrite the consolidated standards chapter
  • finalize the floor vs excellence model
  • align on the poster-grade non-negotiables

Leadership review questions:

  • is the floor explicit enough?
  • is excellence clearly separated from the floor?
  • are the standards memorable enough to teach repeatedly?

Output:

  • stable standards spine doc

Week 2 — Establish checkpoints

Focus: Define how the standards are enforced.

Primary work:

  • rewrite the checkpoint / meeting chapter
  • make PRM the clear main gate
  • define account-level and portfolio-level forcing functions

Leadership review questions:

  • do these checkpoints actually enforce the standards?
  • are there too many checkpoints?
  • what should be retired or downgraded to async?

Output:

  • stable checkpoint chapter

Week 3 — Establish lifecycle and systems of record

Focus: Clarify how work moves from signed scope to execution and when it returns for review.

Primary work:

  • rewrite lifecycle overview
  • clarify project plan / Linear / client narrative relationship
  • tighten re-gating doctrine

Leadership review questions:

  • is plan before promise clear?
  • is re-gating on material change clear?
  • does Linear have the right conceptual place in the system?

Output:

  • stable lifecycle chapter

Week 4 — Establish role model

Focus: Rewrite the role-system overview and begin aligning role-specific chapters.

Primary work:

  • rewrite role overview
  • add the HoD / CSO / SL / IC relationship model
  • clarify the CSO-SL partnership seam

Leadership review questions:

  • does the role model reinforce the system rather than fragment it?
  • are role accountabilities clearer without over-prescribing the work?

Output:

  • stable role-system chapter

Week 5 — Align supporting standards

Focus: Bring supporting doctrine into line with the spine docs.

Primary work:

  • communication standards
  • PM standards
  • Linear hygiene
  • escalation standards
  • analogical reference

Leadership review questions:

  • do all detail docs point back to the same floor?
  • are analogies helping rather than cluttering?
  • is anything still competing with the spine docs philosophically?

Output:

  • aligned support docs

Week 6 — Navigation and adoption

Focus: Make the system easy to teach, easy to navigate, and ready for active use.

Primary work:

  • refresh knowledge/delivery/INDEX.md
  • refresh folder README.md files where needed
  • finalize reading order
  • announce the system and what is active now vs still maturing

Leadership review questions:

  • can a new reader understand where to start?
  • what is active doctrine now?
  • what still needs pilot or further iteration?

Output:

  • usable operating system, not just a set of rewritten docs

4. Adoption rhythm

The rollout should include:

  • weekly leadership review of progress
  • explicit decisions on what is draft vs active standard
  • explicit decisions on what the team is expected to follow immediately
  • visible backlog for what remains under refinement

This avoids a common failure mode: a strong document set that nobody knows how to adopt in practice.

5. What should be enforceable first

Early enforcement should focus on:

  • no surprises
  • plan before promise
  • checkpoint clarity
  • story matches build

Later enforcement can expand into:

  • stronger hygiene expectations
  • more explicit KPI review
  • broader coaching and excellence expectations

6. Relationship to KPI layer

The KPI layer should not lead the rollout. It should follow once the doctrine is stable enough to measure meaningfully.

Use kpis.md to define:

  • adoption indicators
  • checkpoint compliance indicators
  • delivery quality indicators
  • escalation quality indicators

Metrics should reinforce the operating model, not substitute for it.

Last updated: 2026-03-24

Graph View

Backlinks