Fixed-Price Project Runbook · D3 Career Framework

1. Project at a glance

A fixed-price (FP) project locks scope, timeline, and price at contract signing. Once signed, change happens only through a formal Change Request. The job is to deliver the agreed scope on time, at the agreed price, with the agreed quality. This page describes how D3 runs that delivery.

Scope is the contract

Every line in the SoW is a deliverable. Everything outside is a Change Request — no silent additions, no "just one more thing".

Design before build

Design phase ends with a signed-off architecture. Build does not start until that signature is on the document. This is non-negotiable.

Reserve is a feature, not a luxury

Every FP estimate carries a 10-20% reserve. It funds unknowns we know exist. Burning through it without flagging it is a project-management failure.

2. Roles in the project

Six roles run an FP project. The min level shown is the floor — anyone above qualifies. The biggest difference from agile: Project Manager (formal, not Scrum Master), and the Solution Architect carries a much heavier upfront role.

Project Manager Min: PM2

Owns the contract end-to-end. Runs Change Request workflow, milestone reporting, client reporting cadence, escalation. The single point of accountability for delivering scope on time at price. PM3+ for projects > 6 months.

Solution Architect Min: SE L4

Owns the design phase. Translates SoW into architecture, ADRs, NFR plan. Sign-off on architecture gates the start of build. Co-owner of Change Request impact analysis with PM. Often plays Tech Lead during build for smaller projects.

Tech Lead Min: SE L4

Owns build execution. Reviews PRs, mentors team, enforces code standards. Maintains build-phase quality gate. Owns technical risk register. SE L5 expected on projects with NFR-heavy or distributed-system scope.

Business Analyst Min: BA2

Owns requirements + acceptance criteria documentation. Much heavier upfront role than agile: every requirement becomes a testable AC. Co-owns UAT plan with QA Lead. Triages Change Requests for clarification before formal CR.

QA / UAT Lead Min: QA2

Owns the UAT phase as a formal milestone. Writes test plan against acceptance criteria, runs UAT with client, captures accept/reject decisions story by story. Holds the pen on the acceptance log that triggers payment milestone. QA3 for safety-critical or regulated domains.

Developer Min: SE L1

Builds features per spec. Stricter spec adherence than agile — if the spec says X, build X. If something feels off, raise it as a Change Request candidate, do not silently change scope. Mix of L1-L5 typical; L1-L2 on simpler modules, L3+ on harder.

Change Control Board (CCB): not a formal new role — it's PM (chair) + Solution Architect + the client's project sponsor. CCB meets only when a Change Request is on the agenda. See section 4.

3. Project lifecycle phases

Six phases run sequentially with hard gates. A phase ends when its outputs are signed off — not when "we feel ready". Build is the longest; everything else is short and disciplined.

1

Discovery & estimation

Typical: 1-2 weeks · Owner: PM + SA + BA

Activities

Client interviews · stakeholder mapping
Scope decomposition into deliverables
High-level architecture sketch + tech stack proposal
Effort estimation with reserve (10-20%)
Top-3 risks identified

Exit criteria

scope.md drafted · all deliverables enumerated
Estimate signed off internally (PM + SA + Head of D3)
Risk register seeded with top-3 risks
Client agrees to proceed to SoW

2

SoW & contract

Typical: 1-2 weeks · Owner: PM + Legal + Sales

Activities

Formal Statement of Work drafted from scope.md
Acceptance criteria attached to every deliverable
Milestone payment schedule defined
Change Request process documented in contract
Legal review + redlines + sign-off

Exit criteria

Contract signed by both sides
Kickoff date scheduled
Project added to Techvify DES with milestone calendar
Team allocations confirmed

3

Design & architecture

Typical: 2-4 weeks · Owner: SA + Tech Lead + BA

Activities

System architecture diagrams (C4 or equivalent)
ADRs for non-trivial choices (DB, queue, auth, etc.)
NFR plan: performance, security, scalability targets
Detailed AC per deliverable (BA owns)
UAT plan drafted (QA Lead owns)
Build phase plan with weekly checkpoints

Exit criteria — Design sign-off gate

Architecture document signed off by SA + Tech Lead + Client tech contact
All ADRs reviewed
AC and UAT plan attached to project tool
Build phase plan agreed
⚠ Build does NOT start before this gate passes

4

Build

Typical: longest phase, varies by scope · Owner: Tech Lead + Devs + QA

Activities

Feature build sprint-by-sprint (often 2-week iterations internally)
Continuous internal QA on each feature
Weekly client demo (informal) — keep visibility high
Burn-rate tracked vs plan weekly
Risk register refreshed weekly with weekly report
Change Requests triaged immediately (no batching)

Exit criteria — Build complete gate

100% of SoW deliverables coded
Internal QA pass rate ≥ 95%
NFR targets met (perf, security scan, etc.)
Build environment matches UAT spec
UAT readiness checklist signed by Tech Lead + QA Lead

5

User Acceptance Testing (UAT)

Typical: 1-3 weeks · Owner: QA Lead + BA + Client

Activities

Client runs test cases against UAT plan
Defects logged with severity (P0-P3)
P0/P1 fixes within 1-2 days · P2/P3 batched
Daily UAT status: open defects, sign-offs, blockers
Acceptance log updated per story

Exit criteria — UAT pass gate

0 open P0/P1 defects
100% acceptance criteria signed (or formally waived)
Acceptance log signed by client sponsor
P2/P3 defects either fixed, deferred to warranty, or formally accepted
⚠ Payment milestone triggers on this signature

6

Go-live & warranty

Go-live: 1-3 days · Warranty: 1-3 months · Owner: PM + Tech Lead

Activities

Production deployment per cutover plan
Smoke tests + production health check
Handover docs delivered (runbook, ops guide, contact list)
Warranty: defect SLA only for SoW-scope bugs, NOT new features
Final lessons-learned + project retro

Exit criteria — Warranty close gate

Warranty period elapsed without open critical defects
All warranty tickets resolved or transferred to support contract
Final payment received
Project archived in DES (post-mortem written, lessons captured)

4. Change Request process

The CR process is the only legal way to change scope, price, or timeline after the contract is signed. It must be followed without exception. Bypassing the CR process is the #1 cause of FP project failure.

1

Raise CR

Anyone (client or D3) submits a CR form: what changes, why, urgency. PM logs it within 1 business day.

2

Impact analysis

PM + SA analyze impact on scope, effort, timeline, risk. 3 business days SLA. Output: cost delta, schedule delta, risk delta.

3

CCB review

CCB = PM (chair) + SA + Client Sponsor. Discusses trade-offs, alternatives. Decides: Approve / Reject / Park.

4

Re-baseline

If approved: update SoW, contract addendum signed, schedule + budget re-baselined in DES. Team informed. Backlog updated.

Approve — addendum signed, work proceeds against new baseline.

Reject — change is out of scope for this contract. Client may raise as separate project later.

Park — defer decision until UAT or post-launch. Tracked in parking lot, re-reviewed monthly.

No verbal scope changes. Ever. If a stakeholder says "just add X" in a meeting, the PM records it and converts it into a CR. No work happens on it until the CR is approved. This protects both sides — the team from silent overcommitment, the client from getting work they didn't agree to pay for.

5. Quality gates

Five milestone gates govern progression. Each gate has a named owner with veto power. If a gate fails, the project does not advance — the next phase doesn't start. Escalation goes to Head of D3, then to client sponsor.

Design sign-off Owner: SA (SE L4+)

Passes when

Architecture doc signed by SA + Tech Lead + client tech contact
All ADRs for non-trivial choices recorded
NFR plan agreed (perf, security, scalability targets)
AC documented per deliverable

Build complete + internal QA Owner: Tech Lead (SE L4+)

Passes when

100% of SoW deliverables coded and merged
Internal QA pass rate ≥ 95% across all features
NFR targets met (load test, security scan, etc.)
UAT environment provisioned and matches spec

UAT pass Owner: QA Lead (QA2+)

Passes when

0 open P0/P1 defects
100% acceptance criteria signed (or formally waived) by client
Acceptance log signed by client sponsor
P2/P3 either fixed, deferred to warranty, or formally accepted

Go-live readiness Owner: PM (PM2+) + Tech Lead

Passes when

Cutover plan reviewed (rollback, backout, comms)
Production environment provisioned + smoke-tested
Handover docs ready (runbook, ops guide, contacts)
Warranty SLA documented + on-call schedule agreed

Warranty close Owner: PM (PM2+) + Head of D3

Passes when

Warranty period elapsed with no open critical defects
All warranty tickets resolved or transferred to support contract
Final payment received
Post-mortem written, lessons archived in DES

6. Risk & reserve management

The price is locked, so every unknown is risk. The job is to keep risks visible and reserves disciplined — never silently burn through the buffer.

Risk register

Seeded with top-3 risks at Discovery. Refreshed weekly alongside weekly report. Each risk: probability (L/M/H) × impact (L/M/H), mitigation owner, due date, status (open/mitigated/closed/realized).

Reserve (contingency)

10-20% of effort estimate, embedded in price. Tracked separately from main budget. Burning it requires PM approval + reason logged in DES. >50% reserve burn = mandatory escalation to Head of D3.

Burn rate tracking

Weekly: planned effort vs actual effort. Cumulative variance plotted. >10% over = warning, >20% over = escalation. Burn-down chart shared in weekly client report.

Escalation matrix

<5% variance: PM monitors silently. 5-10%: PM + Sponsor discuss. 10-15%: Head of D3 informed. >15%: department review + recovery plan within 1 week.

Top 5 FP-specific risks (always check at kickoff)

Scope creep without CR — silently absorbed "small" changes accumulate. Mitigation: CR culture enforced from day 1.
Late-discovery complexity — design uncovers issues not flagged at estimation. Mitigation: 10-20% reserve, design phase taken seriously.
Client UAT delays — client doesn't show up to test, project sits idle. Mitigation: UAT plan agreed at design, schedule confirmed at Build start.
Vague AC — "works well" is not a testable AC. Mitigation: BA owns AC quality, every AC is a measurable test.
Team turnover mid-build — key Dev or Tech Lead leaves, knowledge transfer suffers. Mitigation: documentation discipline, bus-factor >1 for critical components.

7. Reporting channels

FP reporting is milestone-driven, not sprint-driven. The chart below shows when each report fires across the 6 project phases.

Discovery

SoW

Design

Build

UAT

Go-live + warranty

Daily team check (light) PM → team · ~5 min

Weekly client status MANDATORY · PM → Client

Milestone report (per gate) MANDATORY · PM → DES + Client

★

Monthly leadership review MANDATORY · PM → Head of D3

— Recommended below —

Risk register refresh PM → DES · 5 min/week

Quality snapshot (auto) Auto-extract · DES dashboard

CR log update PM → DES · on every CR

Acceptance log update QA Lead → Client + DES

Mandatory

Continuous (light)

Recommended weekly

Periodic

★Per-milestone (one-off)

8. Common pitfalls

Most FP project failures share a small set of root causes. Each of these has bitten D3 projects before — and each has an early-warning signal you can watch for.

1 Silent scope creep

Symptom: "just a small thing" added verbally, not logged. After 5 of these, the team is 20% over budget but nothing is flagged.

How to avoid: Train the team to convert every "just add X" into a CR draft, even if small. Reject scope changes in standups — they go to PM.

2 No reserve / contingency

Symptom: Estimate at zero buffer to win the bid. First unexpected complexity blows the budget; team works unpaid weekends.

How to avoid: Always estimate with 10-20% reserve. If sales pressure forces zero-reserve, escalate to Head of D3 before signing. Some bids are not worth winning.

3 Skipped or shallow design phase

Symptom: Team jumps to build because "design is overhead". Architectural problems surface in week 6 and require a rewrite.

How to avoid: Treat the design sign-off gate as non-negotiable. ADRs for every non-trivial choice. Even small projects get a 1-day architecture spike.

4 Vague acceptance criteria

Symptom: AC reads "system should be fast and easy to use". UAT phase becomes an open argument about what "fast" means.

How to avoid: BA owns AC quality. Every AC must be testable with a yes/no answer. "p95 latency < 200ms under 1000 RPS" beats "should be fast".

5 Client UAT not planned

Symptom: Build is done, client says "we need 4 weeks to schedule UAT testers". Project sits idle, payment milestone slips.

How to avoid: UAT plan agreed at Design phase. Testers identified, schedule blocked on client calendar before build starts.

6 No risk register

Symptom: "We'll handle risks as they come up." Risks compound silently; recovery is expensive.

How to avoid: Seed risk register at kickoff with top 3 risks. Refresh weekly. Visible to client + leadership.

7 PM as single point of contact bottleneck

Symptom: Every decision routes through PM. PM gets sick or overloaded; project stalls for days.

How to avoid: Document decision-rights matrix. Tech Lead can decide technical trade-offs without PM. QA Lead can sign off UAT items. PM only blocks scope/cost/timeline changes.

Fixed-price projects at D3 — milestone-driven, contract-anchored