Overview Intermediate 5 min read

Running a Project: The Complete Tech PM Checklist

The hub checklist that ties every artifact in this series together. Use it to start a project, audit a project mid-flight, or prepare for a handover.

Phùng Anh Tú · June 24, 2026

Table of contents

When does the full checklist matter?
What is the cost of skipping the audit?
What does the complete checklist look like?
How does this scale to the project shape?
What does using the checklist as an audit look like?
What failure modes does using the checklist introduce?
When is the checklist overkill?
Where should you go from here?

This chapter is the index of the series. Every artifact you have read is mapped here to its phase, with a one-line check and a link to the chapter that defines it. The list works three ways: to start a project right, to audit one in trouble, and to leave a project clean for the next owner.

When does the full checklist matter?

Three signals.

Starting a project. Walking down the list at kickoff makes sure no foundational artifact is missed.

Project showing stress. When schedules slip or trust erodes, the checklist surfaces the missing artifact - usually status reports or risk tracking.

Handover or audit. When a project changes hands or a peer reviews it, every unticked item is a question to address.

For a 1-week internal hack, the full checklist is overkill. For anything longer, it is the gravity check.

What is the cost of skipping the audit?

Two scenarios.

No checklist mid-project. The team thinks they have everything; in fact, no decision log exists, the risk register is 6 weeks stale, and the kickoff doc was never updated. Each gap costs hours later.

Handover without checklist. New owner inherits a project where artifact gaps are invisible. They learn week by week about each missing piece and the project regresses for a quarter.

What does the complete checklist look like?

# Tech PM Project Checklist

## Foundations (set up at kickoff)

- [ ] Roles doc + RACI for big decisions ([chapter 1](/tech-pm/pm-vs-em-vs-tpm))
- [ ] Estimate range with confidence ([chapter 2](/tech-pm/estimation-fundamentals))
- [ ] RAID log with weekly review cadence ([chapter 3](/tech-pm/risk-and-issue-tracking))
- [ ] Stakeholder map and comms plan ([chapter 4](/tech-pm/stakeholders-and-comms))
- [ ] Scope frozen with MoSCoW ([chapter 5](/tech-pm/scope-and-tradeoffs))

## Methodology (pick one, document the choice)

- [ ] Methodology selected with rationale ([chapter 8](/tech-pm/method-selection))
- [ ] Sprint or Kanban cadence set up ([chapter 6](/tech-pm/scrum-essentials), [chapter 7](/tech-pm/kanban-flow))

## Lifecycle (run during the project)

- [ ] Kickoff doc with sponsor sign-off ([chapter 9](/tech-pm/discovery-and-kickoff))
- [ ] Roadmap (Now/Next/Later) published ([chapter 10](/tech-pm/planning-and-roadmap))
- [ ] Daily standup with blocker list ([chapter 11](/tech-pm/sprint-execution))
- [ ] Launch checklist + rollback plan ([chapter 12](/tech-pm/launch-and-handover))
- [ ] Incident runbook owned by ops ([chapter 13](/tech-pm/incident-and-rollback))
- [ ] Retrospective after each sprint ([chapter 14](/tech-pm/retrospective-and-post-mortem))

## People (ongoing)

- [ ] Weekly 1-on-1s with all reports ([chapter 15](/tech-pm/one-on-ones))
- [ ] Hiring loop documented; onboarding plan per new hire ([chapter 16](/tech-pm/hiring-and-onboarding))
- [ ] Performance feedback within 48h of behaviour ([chapter 17](/tech-pm/performance-and-feedback))

## Artifacts (running, updated)

- [ ] Weekly status report (RAG) sent ([chapter 18](/tech-pm/status-reports-that-work))
- [ ] ADRs for major architectural choices ([chapter 19](/tech-pm/decision-logs-and-adrs))
- [ ] Decision log for non-architecture choices ([chapter 19](/tech-pm/decision-logs-and-adrs))

## Project shape (use the case study that fits)

- [ ] If rescuing: 30-day rescue plan ([chapter 20](/tech-pm/rescue-a-failing-project))
- [ ] If MVP: 12-week timeline + hypothesis ([chapter 21](/tech-pm/greenfield-mvp-launch))
- [ ] If modernising: Strangler Fig migration plan ([chapter 22](/tech-pm/legacy-modernisation))
- [ ] If vendor-managed: contract phases + acceptance criteria ([chapter 23](/tech-pm/vendor-managed-project))

## Closing (do not skip)

- [ ] Post-mortem written if any P1/P2 incidents
- [ ] Handover doc complete and signed
- [ ] Lessons learned added to team's [reference class](/tech-pm/estimation-fundamentals)
- [ ] Project channel archived; ownership clear in production

How does this scale to the project shape?

flowchart TB
    Start[Project starting?] --> Choice{Which case?}
    Choice -->|Brand new| MVP[Use MVP case 21<br/>12-week timeline]
    Choice -->|Inherited mess| Rescue[Use rescue case 20<br/>30-day plan]
    Choice -->|Old to new| Legacy[Use legacy case 22<br/>strangler fig]
    Choice -->|External team| Vendor[Use vendor case 23<br/>contract phases]
    Choice -->|Standard project| Standard[Use Foundations + Lifecycle<br/>chapters 1-14]
    MVP --> Common[All shapes share<br/>the artifact base]
    Rescue --> Common
    Legacy --> Common
    Vendor --> Common
    Standard --> Common

The case study tells you which shape; the artifact base is universal. Pick the case study that matches; layer it on the foundation.

What does using the checklist as an audit look like?

A 30-minute walkthrough with the project lead:

# Project Audit — {{ Project }} — 2026-06-24

## Foundations (5 items)
- [x] Roles doc - up to date
- [x] Estimate - present, last updated 6 weeks ago (stale)
- [ ] RAID log - missing! Project running for 3 months without one
- [x] Stakeholder map - present
- [x] Scope MoSCoW - present, but 'Won't' has been violated twice

## Recommendations (top 3)
1. Set up RAID log this week; review with team
2. Refresh estimates; reconcile with original budget
3. Re-confirm scope with sponsor; restate Won't list

## Risk level: Amber
Project is functional but missing artifacts that catch problems
early. Without RAID + status report, surprises are likely.

The audit is the artifact format; the conversation is what matters. Most projects have most things; the audit surfaces the 2-3 gaps that need attention.

What failure modes does using the checklist introduce?

Checkbox theatre. All items ticked but the artifacts are shelfware. Mitigation: each tick requires evidence (link, recent date, owner).
Cargo cult adoption. Adopting all 30+ artifacts at once; team rebels. Mitigation: introduce one at a time after a pain point.
Paper over leadership gaps. The checklist exists, items ticked, but the team is dysfunctional. Mitigation: artifacts surface dysfunction; they don't fix it. Use 1-on-1s and retros to address human issues.
Outdated checklist. As the team and project mature, some artifacts become unnecessary. Mitigation: review the checklist quarterly; adjust the team's standard.

When is the checklist overkill?

Two cases.

One-week project, two engineers. The checklist applies in spirit (estimate it, ship it, retro it) but the formal artifacts are oversized.

Continuous-flow team with no projects. Platform / SRE / support teams use the team's standing artifacts (runbook, on-call, ticket process), not project-level checklist.

The full checklist earns its weight at project size + team size + duration. Below that, lighter.

Where should you go from here?

Last chapter: conclusion - the five lessons that survive every project shape and the recommended reading list to keep growing.

Frequently asked questions

How do I use this checklist?

Three ways. Starting a project: walk down the list, set up each artifact in order. Mid-project audit: tick what exists, identify gaps, prioritise. Handover: every unticked item is a handover risk; address before the new owner arrives. The checklist is the table of contents for the series, organised by when you need each piece.

Do I need every item on every project?

No. The 'when overkill' section in each chapter lists the cases where the artifact is unnecessary. Use the checklist as the maximum; cut down based on team size, project length, and risk profile. Tiny project = 5-10 items; multi-team multi-quarter = all 30+.

What if my company has different terminology?

The artifacts are universal; the names vary. 'RACI' might be 'roles doc'; 'RAID' might be 'risk register'; 'retro' might be 'lookback'. Map the names to the function. The series teaches the function; the local team teaches the names.

How do I introduce these artifacts without seeming bureaucratic?

Introduce one at a time, after a pain point makes the case. After a missed deadline, introduce estimation. After a stakeholder surprise, introduce status reports. After a confused decision, introduce ADRs. Each artifact has to earn its keep.