Project Plan Template: A One-Page Plan a Small Team Will Use

A project plan a small team will actually use fits on one page and answers six questions: what is the goal, what is in scope and what is not, what are the milestones, who owns each one, what could go wrong, and how will you track progress. Write the goal as an outcome you can check, list the exclusions as carefully as the inclusions, give every milestone one owner, and keep risks to a short list with what you will do about each. Then turn the milestones into tasks on the board you already work from, and the page stays true because the board does the tracking. The template, a filled example and the step from plan to tasks are below.

Why one page is enough

Long plans are written once and never reopened. A short one is read at the kickoff, pinned where the team works, and checked every week. The SBA makes the same point about business plans: its guide to writing a business plan↗ (opens in a new tab) describes a lean format that focuses on the most important points, “can take as little as one hour to make” and is typically only one page, suited to anyone who plans to change and refine the plan regularly. That describes most small-team projects.

This template is deliberately light. It has no charter, no work breakdown structure, no Gantt chart and no resource plan. If your project needs a formal plan for a client contract or a regulator, use theirs. If it needs a team of three to five people to agree on what they are doing for the next six weeks, use this.

The six parts of a one-page project plan

1. Goal: one or two sentences describing the outcome, with a way to check it. “Launch the new booking page” is an activity. “Customers can book and pay online without calling us, by the end of November” is a goal.
2. Scope in and out: what the project will deliver, and what it will not. The “out” list prevents more arguments than anything else on the page, because it is where people discover they assumed different things.
3. Milestones: three to six points where something usable exists, in order. Each is a result, not a phase: “bookings work on staging,” not “development.” Put a target date on each if you have one.
4. Owners: one name per milestone. Other people help; one person answers for it.
5. Risks: the three to five things most likely to derail the project, each with what you will do about it now and what you will do if it happens.
6. Tracking: where the work lives, how often you look at it, and who writes the weekly update.

On owners, the US Digital Service Playbook is direct. One of its plays is to “Assign one leader and hold that person accountable”: a single product owner in the USDS Playbook↗ (opens in a new tab) has the authority to assign tasks and make decisions, and answers for the result. A small team is not a federal agency, but the principle scales down: if two people own a milestone, nobody does.

On risks, rate each one by how likely it is and how much it would hurt. That is the classic definition: the NIST glossary entry for risk↗ (opens in a new tab) describes it as typically a function of the adverse impact if an event occurs and the likelihood of it occurring. You do not need a scoring matrix for five risks. High, medium or low on each of the two is enough to decide which ones get a response written down.

A one-page project plan template to copy

# Project plan: [Project name]
Lead: [one name]     Start: [Month day, year]     Last updated: [Month day, year]

## Goal
[The outcome, and how you will check it. One or two sentences.]

## Scope
In:
- [What this project delivers]
Out:
- [What it does not, even if someone will ask]

## Milestones
| # | Milestone (a result, not a phase) | Owner  | Target      |
|---|-----------------------------------|--------|-------------|
| 1 | [What exists when this is done]   | [name] | [Month day] |
| 2 | [ ]                               | [name] | [Month day] |
| 3 | [ ]                               | [name] | [Month day] |

## Risks
- [Risk] | Likelihood: [H/M/L] | Impact: [H/M/L]
  Now: [what we do to make it less likely] If it happens: [what we do]

## Tracking
Work lives in: [board / tool]
Reviewed: [every Monday, 15 minutes]
Weekly update by: [name], to: [who]
Changes to this plan: [who can approve them]

A filled example

# Project plan: Online booking
Lead: Priya     Start: October 6, 2026     Last updated: October 6, 2026

## Goal
Customers can book and pay for a cleaning online, without calling,
by November 30. Check: 20 real bookings made online in the first week.

## Scope
In:
- Booking page for the three standard services
- Card payment at booking
- Confirmation email to the customer and the office
Out:
- Custom quotes and commercial jobs (stay on the phone)
- Rescheduling online (next project)
- A mobile app

## Milestones
| # | Milestone                               | Owner | Target  |
|---|-----------------------------------------|-------|---------|
| 1 | Services, prices and slots agreed       | Priya | Oct 10  |
| 2 | Booking works end to end on staging     | Tom   | Oct 31  |
| 3 | Payments tested with real cards         | Tom   | Nov 14  |
| 4 | Live, announced to existing customers   | Priya | Nov 21  |

## Risks
- Payment provider review is slow | L: M | I: H
  Now: apply in week one. If it happens: launch with pay-on-the-day.
- Slots double-booked with phone bookings | L: H | I: M
  Now: office enters phone bookings in the same calendar from Oct 20.
  If it happens: office calls the second customer the same day.
- Tom is out for a week in November | L: M | I: M
  Now: Sam pairs with Tom on payments from Nov 3.

## Tracking
Work lives in: the team board, project "Online booking"
Reviewed: every Monday, 15 minutes
Weekly update by: Priya, to: the owner
Changes to this plan: Priya, after asking the owner

How to write it in an hour

1. Write the goal alone first, then read it to the person who asked for the project. If they would describe success differently, stop and settle that before anything else.
2. List everything anyone has asked for, then sort each line into In or Out. Out is not “never”; it is “not in this project.”
3. Group the In list into milestones, each ending in something a person could look at or use. If a milestone has no visible result, merge it into the next one.
4. Put one name against each milestone and ask that person, in the room, whether they accept it.
5. Ask the team what would make this late or wrong, write down the top few, and agree one action for each.

Then date the page and treat it as current until someone changes it. When scope or a milestone changes, edit the page, update the “Last updated” line, and tell the team what moved and why. A plan that is quietly out of date is worse than none, because people keep following it.

Turning the plan into tasks with Add many

The plan says what and why. The tasks say what someone is doing today. On a fenbs board, Add many turns a pasted list into tasks in one step, so the plan does not have to be typed in again. A few things to know before you paste:

• Paste the work, not the whole page. When a paste contains bullets, headings are treated as section labels and are not turned into tasks, and lines under a bullet become that task’s note, so a pasted Goal or Risks paragraph would end up in the note of the task above it.
• Paste one milestone at a time. Project, category, lane and priority are set once for the whole batch, so set the project to the plan’s name and the category to the milestone, and every task in that batch carries both.
• Mark the kind where it matters. Every task is a feature, an enhancement or a bug; start a line with feature:, enhancement: or bug: to set it for that line, or let the line take the batch’s kind.
• Write the owner in the note. fenbs has no assignee field, so an indented line such as “Owner: Tom” under each task is how the board says whose it is.

- [ ] feature: Booking page for the three standard services
      Owner: Tom. Slots come from the office calendar.
- [ ] feature: Confirmation email to the customer and the office
      Owner: Tom.
- [ ] enhancement: Office calendar shows online bookings in a different color
      Owner: Sam.

Everything is previewed before anything is created, so a misread line is corrected rather than cleaned up. Each task then has a note for the problem, a plan for how it will be done, a test status for how it was checked, and an optional size from XS to XL; an XL is a signal to split the task before anyone starts.

Tracking progress, and what fenbs does not do

Once the tasks exist, the board is the progress report. Tasks move through To Do, Next Up, In Progress and Completed, filter the board by the project and a category to see one milestone, and Copy as Markdown puts the board on your clipboard for the weekly update. Every change is recorded with who made it, so “who moved the payments task back?” has an answer.

Be clear about the gaps. fenbs has no Gantt chart, no due dates, no dependencies between tasks beyond linking related ones, and no epics, so milestone dates stay on the one-page plan, not on the board. If your project’s main risk is a hard date with a long chain of dependencies, a scheduling tool will serve you better. If it is getting a small team to agree and follow through, the page plus the board is usually enough.