One-Page Project Plan Template
Updated: 2 days ago
The thickest project plan I ever inherited was 34 pages, and it was wrong about the one thing that mattered. It had a resourcing table, a RACI matrix, a risk register with severity scores — and buried in the scope section, one sentence assumed a third-party team would deliver an API by a date nobody on that team had agreed to. All 34 pages rested on that sentence. When the API slipped, the plan didn't bend; it shattered, because the volume had hidden the single load-bearing assumption instead of exposing it. A one-pager would have put that dependency on the same line as the goal, where someone would have poked it in week one.
That's the argument for compressing a plan to a page: length is where uncertainty goes to hide. When you have room for everything, you never have to admit what you don't know. This guide is a template that works for most engineering projects, with notes on what to do when one page genuinely isn't enough.
The Template
# [Project Name] - One-Page Plan
## Goal
[One sentence: what we're trying to achieve]
## Why
[One sentence: why this matters]
## Success Metrics
[How we'll measure success: 2-3 specific metrics]
## Scope
In: [3-5 bullets]
Out: [2-4 bullets]
## Approach
[3-5 bullets: how we'll execute]
## Timeline
[Key milestones with dates]
## Team
[Roles and who's filling them]
## Risks
[Top 2-3 risks and mitigations]
## Decisions Pending
[What needs to be decided]
The whole thing fits on a page. Each section answers one question.
When the One-Pager Is Enough
A one-page plan is sufficient for:
Most engineering projects under 3 months
Internal initiatives with clear scope
Iterations within a larger program
Cross-team coordination at the working level
It's insufficient for:
Multi-quarter strategic initiatives
Projects with significant compliance or regulatory components
Vendor-driven projects requiring detailed SOWs
Anything with complex financial structure
For those, the one-pager becomes the executive summary of a longer plan.
The Goal
A single sentence. Active voice. Specific.
Bad: "Improve the user experience of the platform."
Good: "Launch self-service workspace switching for customers with multiple workspaces."
If you can't fit the goal in a sentence, it's probably not one project.
The Why
A single sentence. The motivation.
Bad: "This is strategically important."
Good: "Power users have been requesting workspace switching for 18 months; it's the #2 churn-cited friction point."
The why guides decisions when scope questions come up later. "Does this serve the why?" is the test.
Success Metrics
Two to three specific, measurable metrics. Including the failure threshold.
Example:
"Within 60 days of launch, 30% of multi-workspace users use the switcher weekly"
"Workspace-switching-related support tickets drop by 70%"
"If usage is below 10% at 90 days, we'll re-evaluate the feature"
The failure threshold is critical. Without it, every project is retroactively successful regardless of evidence.
Scope
In and Out, with bullets.
The Out list is the dispute-preventer. Whatever you don't write in "Out" can be argued in two months. Whatever you do write closes off the debate.
Common out-of-scope items:
Migration of existing entities
Mobile vs. web (start with one)
Advanced configuration options
Integration with specific external tools
Be specific. "Mobile support is out of scope for this release; tracked as separate effort for Q3."
Approach
How you'll execute. Not detailed schedule — high-level approach.
Examples:
"Phase 1: backend API. Phase 2: web UI. Phase 3: rollout with feature flag."
"Beta with 5 friendly customers before broader release."
"Reuse existing auth flow; no changes to permissions model."
Approach answers "what's our strategy?" without descending into task-level detail.
Timeline
Major milestones, not detailed Gantt.
Week 4: Design complete
Week 8: MVP in staging
Week 12: Beta launch
Week 14: GA
Five to seven milestones is a working number for most projects. More than that and the milestones are too granular.
Team
Roles and who's filling them.
Lead: Sam
Engineering: Pat, Alex (50% allocation)
Design: Riley (4 weeks)
PM: Jordan
Sponsor: VP Product
Names matter. "An engineer" is not a commitment; "Pat full-time" is.
Risks
The top two to three. Not everything that could go wrong — the things most likely to derail the project.
For each: brief description, severity, mitigation.
- SSO integration complexity (High): may extend timeline by 2 weeks if Okta API behaves differently than documented. Mitigation: spike in Week 2 to validate.
- Resource contention (Medium): Pat is also on-call rotation in Week 6. Mitigation: confirm coverage with team.
Be honest. A plan with no risks is a plan that hasn't been examined.
Decisions Pending
What needs to be decided before the plan is fully baked.
Pricing tier eligibility (Sales VP, by Week 1)
Beta cohort selection (PM + Success, by Week 6)
Mobile timeline (deferred decision)
If decisions aren't named, they happen by drift. Naming them forces them to happen on purpose.
A Worked Example
# Workspace Switching - One-Page Plan
## Goal
Launch self-service workspace switching for customers with multiple workspaces.
## Why
Power users have requested this for 18 months; it's the #2 churn-cited friction point.
## Success Metrics
- 30% of multi-workspace users use switcher weekly within 60 days
- Workspace-related support tickets drop 70%
- If usage <10% at 90 days, reassess
## Scope
In:
- Switcher accessible from any page
- Switching preserves URL context
- Recent workspaces list
- Keyboard accessible
Out:
- Bulk workspace operations (separate project)
- Workspace creation/deletion in UI (existing flow)
- Mobile (Q3)
- Workspace search (consider for v2)
## Approach
- Reuse existing auth flow; no permissions changes
- Phase 1: API + minimal UI
- Phase 2: polished UI + analytics
- Phase 3: feature flag rollout, 10% → 50% → 100%
## Timeline
- Week 2: Design review complete
- Week 4: API + minimal UI in staging
- Week 6: Polished UI complete
- Week 8: Internal beta
- Week 10: 10% production rollout
- Week 12: GA
## Team
- Lead: Sam (Eng Manager)
- Engineering: Pat (full-time), Alex (50%)
- Design: Riley (3 weeks)
- PM: Jordan
## Risks
- Deep-link preservation may have edge cases (Medium): spike in Week 1
- Analytics instrumentation may slip into Phase 3 (Low): plan to address pre-launch
- Browser back-button behavior with switching may surprise users (Medium): user testing in Week 7
## Decisions Pending
- Permissions edge case: what happens if user loses access mid-session? (Lead + PM, Week 3)
- Analytics events naming (PM, Week 4)
The whole plan fits on a page. Anyone can scan it and understand what we're doing and why.
What Falls Off the One-Pager
Things that legitimately don't fit:
Detailed implementation plans (live with the team)
Day-by-day schedules (live in the team's tracking tool)
Detailed budgets (live in finance docs)
Detailed risk register (separate doc for big projects)
Stakeholder map (separate doc)
The one-pager points to these; it doesn't contain them. Link them when they exist.
Updating Over Time
A one-page plan should update as the project evolves. Stale plans are worse than missing ones.
Cadence:
At each major milestone, review and update
When scope changes, update before the change is implemented
When risks materialize or close, update the risks section
When decisions are made, move them from "pending" to context or scope
Version the document. A change log at the bottom is enough.
Anti-Patterns
The wall-of-text page. Technically one page but unreadable because it's all paragraphs. Use bullets.
The aspirational metrics. "Improve everything." Specific or skip.
The hidden scope. Out of Scope says "various items." Useless. Name them.
The committee team. "Various engineers across the team." Names matter.
The fictional timeline. Milestones not based on real estimates. Becomes credibility-destroying when they slip.
Key Takeaway
A one-page plan answers the essential questions: goal, why, success metrics with failure threshold, scope (in and out), approach, timeline, team, risks, pending decisions. Fits on a page. Updates as the project evolves. Sufficient for most engineering projects; serves as executive summary for larger ones. The discipline of compressing to one page surfaces what's unclear. If you can't fit the plan on a page, you probably don't understand the project well enough yet — or it's actually multiple projects.
Part of the Engineering Templates & Playbooks guide — ShiftQuality's collection of ready-to-adapt templates.
