Every closed-won deal becomes an engagement that flows through Definition, Build, Delivery, and Closure — each with its own gating sign-off, its own spawned tasks, and its own RACI-routed accountability. When Closure signs off, the engagement graduates to BAU.
Every engagement shows you the same thing: current phase, gate readiness, what was signed, and what's next.
Currently in Build · G1 signed Jan 22
14 of 22 phase tasks complete. Data migration module is enabled — dry-run scheduled for Feb 8. Lead Engineer Sarah Chen is Accountable on the integration workstream. BID has 2 pending revisions from client feedback.
Each phase has typed inputs, spawned tasks, and a gating sign-off. No ambiguity about whether you're ready to move forward.
Scope it before you ship it.
Inputs
Closed-won deal + handoff memo
Tasks
Kickoff, requirements workshops, RAID log setup, BID/PID drafts, config form, team staffing
Gate
G1 — Signed PID + signed BID + VeroOS Configuration Form + finalized plan
Configure, integrate, develop.
Inputs
Signed G1 artifacts
Tasks
OS config, GL mapping, data migration, integrations, user-story dev, UAT prep
Gate
G2 — Build-complete sign-off, UAT-ready system
Test it, train them, take it live.
Inputs
Build-complete system
Tasks
UAT execution, defect triage, training, cutover prep, go-live readiness
Gate
G3 — UAT sign-off + go-live approval
Stabilize. Hand over. Close out.
Inputs
Live system
Tasks
Hyper-care, post-go-live stabilization, lessons learned, BAU handoff
Gate
Project Closed — Closure sign-off → graduation to BAU
Every gate captures an immutable snapshot of what was signed — the BID, the PID, the VeroOS Configuration Form, the UAT report, the closure pack. The source document keeps evolving; the snapshot freezes what was agreed at that gate.
Documents update continuously as the project unfolds — the gate snapshot freezes what was actually signed.
Rewinding a gate never retracts a snapshot. Every audit, every dispute, every renewal references the same source of truth.
When a change request approves in BAU, a fresh BID snapshot tags `phase: bau` so the post-go-live trail stays complete.
The completed VeroOS Configuration Form is linked from Google Drive and frozen at the G1 gate alongside the signed BID and PID, so the agreed system config is on the record.
Client legal not engaged for DPA
Okta SSO is production-ready by G2
Sandbox creds intermittently expire
Pin EDI rollout to phase 2 (post go-live)
Phase tasks land on the Accountable role automatically when the phase opens. No manual triage.
The delivery team has typed role slots — Delivery Manager, Business Analyst, Account Manager, Lead Engineer, Data Lead, QA Lead — that map to the RACI matrix on every phase task. When a phase opens, tasks auto-route to the Accountable person. No triage meeting. No spreadsheet.
Toggle a module on at the start of the engagement — Anchor spawns the right tasks in the right phase. Toggle one off, and the related tasks never appear.
Spawns mapping, validation, and dry-run tasks in Build
Finance-side configuration in Build phase
Third-party connector workstream in Build
EDI partner setup and message-flow validation
The signed agreement and BID set the scope and budget at G1. Any post-G1 scope shift runs through the 11-stage change request workflow — with cost estimates, billable classification, client signature, and payment confirmation before any work begins. The BID re-snapshots when the CR approves.
Hours, rates, spend per engagement with burn-rate forecasting against the G1 budget
11-stage CR pipeline with cost estimates, signatures, invoice tracking, and BID re-snapshot on approval
Log time per task with consumption visualization against the active phase
Weekly capacity hours and utilization % per team member, per phase
G1 Budget
$0
Locked at G1
Spent
$0
58% utilized
CRs approved
$0
2 billable CRs
Burn Rate
$0/wk
~9 weeks runway
When the Closure gate signs off, the engagement graduates to BAU in one atomic transaction — the engagement leaves the delivery board, the account flips to live_customer, and Customer Success picks up the relationship. No more "is this still in delivery or are we live?"
BAU spawns zero tasks. Ongoing servicing flows through change requests, client submissions, and ad-hoc CS work — modeled, tracked, and never confused with delivery work.
Atomic transition
currentPhase → bau
accountType → live_customer
RevenueEvent → bau_graduated
Anchor is invite-only. Log in if you already have access, or join the waitlist below.
or join the waitlist