Software Project Management Checklist

Product manager drafts the PRD in Notion or Confluence with user stories, acceptance criteria, and out-of-scope items called out explicitly. Link the originating Jira / Linear epic. Common gotcha: leaving non-functional requirements (latency targets, accessibility, data residency) implicit — surface them now or pay later.

Tech lead and PM agree on what ships in v1 vs. fast-follow. Definition of done covers tests written, code reviewed, docs updated, feature flag wired, observability in place. Write down what is explicitly NOT in scope to head off scope creep mid-sprint.

Does this project touch customer PII, payment data, PHI, or production auth? If yes, the security review and threat-modeling steps later in this checklist are required and not optional. Flag this early so the security engineer can be looped in before code is written, not at PR review.

Tech lead drafts the design doc: data model, API contracts, sequence diagrams for non-trivial flows, migration plan if schema changes, rollout plan, rollback plan. Circulate for async review with at least two senior engineers before kickoff.

Break the epic into stories, point them in planning poker, and map them to sprints. Apply a 30% buffer for unknowns — if you've never integrated with the third-party API in question, double it. Capture milestones in Jira / Linear so burndown actually reflects reality.

Engineering manager confirms named engineers, designer, QA, and SRE coverage. Check PTO calendars across the project window — vacations during release week are the most common slip. Identify the back-up engineer for the service this project touches so on-call isn't a single point of failure.

AppSec engineer facilitates a STRIDE walkthrough with the tech lead and two engineers. Cover OWASP Top 10 risks against the new endpoints, IAM roles touched, and data flows in/out of the service. Output is a list of mitigations tracked as Jira tickets in the project epic.

If the project changes access controls, audit logging, change management, or vendor sub-processors, log it in Vanta / Drata / Secureframe so the next SOC 2 Type II audit picks up the change. New sub-processors require a DPA before integration begins.

Walk the team through the design doc, confirm story owners in Jira / Linear, and call out cross-team dependencies (platform, design, data). Each story has a single DRI even if multiple engineers contribute.

Create the LaunchDarkly / Unleash flag with a named owner and a stale-by date — flags without expirations are how 60% of your flag pool ends up dead. Wire RED-method metrics (rate, errors, duration) and a Datadog or Grafana dashboard before the first endpoint ships.

Required status checks on main: CI green, CodeQL / Semgrep clean, at least one CODEOWNERS approval. Block force-pushes. Without this, the "just rerun the flaky test and merge" habit will mask real regressions.

15 minutes, async-friendly via Slack standup bot if the team prefers. Engineers flag blockers — design feedback waiting, staging environment broken, third-party API rate-limiting. Scrum master / EM clears blockers same-day.

Tech lead reviews the project risk register weekly: blocked dependencies, vendor SLAs, environment availability, scope-creep requests. Risks with no mitigation owner get one assigned the same day they're identified.

Unit and integration coverage hits the team's threshold (typically 80% on touched lines, enforced in CI via SonarQube or Code Climate). New critical paths get e2e coverage in Playwright or Cypress. Coverage on a green file count is meaningless — gate on diff coverage.

Snyk or Dependabot must show no critical or high CVEs on direct or transitive dependencies. License scan blocks GPL/AGPL contamination if the codebase ships commercially. Generate the SBOM (CycloneDX or SPDX) for the release.

Two senior engineers outside the project review the merged work against the design doc — what diverged, why, and whether the divergence was documented. CODEOWNERS approvals are necessary but not sufficient for a project of this scope.

Mid-project change requests go in a "change" Jira / Linear issue type, not a Slack DM. Capture the requester, business justification, and engineering estimate before any decision is made. "Just one more thing" is how timelines slip silently.

Tech lead estimates added scope, identifies which design-doc sections need updating, and flags downstream dependencies (data migration, API contract, customer-facing docs). PM confirms whether the trade-off is worth it against the original priorities.

Approved changes get reflected in the design doc with a dated revision note, and an entry in the project changelog. Stakeholders who reviewed the original doc get a Slack ping with the diff — silent design changes are the most common source of post-release "that's not what we agreed."

Release captain walks the team through the runbook: DB migration first with replication-lag monitoring, backend canary at 5%, gradual rollout 25/50/100, frontend deploy after backend is fully out. Confirm the previous container image is still in the registry for rollback and the migration is reversible.

Watch error rate and p99 latency dashboards for 30 minutes post-deploy. Customer-support inbound and Sentry / Bugsnag spike alerts both count as signals. Tag the deployed sha (e.g., v2024.45.0) once green.

Blameless PIR within five business days of the rollback. Capture the timeline, contributing factors (alert tuning, missing dashboard, deployment automation gap), and action items with named owners and due dates. Action items track to closure in the next sprint, not "someday."

What went well, what didn't, what to try next time. Capture concrete action items with owners — "improve testing" is not an action item, "add Playwright e2e for the checkout flow by sprint 47" is. File the action items in the team backlog before the meeting ends.

Remove the launch flag once the rollout is at 100% and stable for two weeks. Close completed Jira / Linear tickets, archive the project Slack channel, and update the service catalog (Backstage) with new ownership or runbook links.

Customer-facing release notes published, internal architecture docs in Confluence / Notion updated to match what actually shipped, runbook for on-call updated with new alert routing. Engineering manager sends the project summary to #engineering with metrics: scope shipped, slip vs. estimate, incidents during rollout.