How to Create a Project Plan on a Page: A Practical Guide for Project Managers
- Essan Wray
- 2 days ago
- 5 min read
A project does not need a 50-page document to create clarity. One of the most useful things a Project Manager can do is bring the key information about a project together in a single, practical view — a Project Plan on a Page.
Done well, it gives your project team, stakeholders and sponsors a shared understanding of what the project is trying to achieve, what needs to happen, what could affect delivery, and where decisions are needed.
What Is a Project Plan on a Page?
A Project Plan on a Page is a concise overview of a project that brings together the information people need to understand and manage delivery. It is not a replacement for your detailed project plan, schedule, RAID log or governance documentation — it is a single point of reference that sits alongside them.
A good one-page plan should let anyone quickly answer:
Why are we doing this project?
What are we trying to achieve?
What is in scope, and what is out of scope?
What are the key deliverables?
When do the major milestones need to happen?
What are the key risks and dependencies?
How is the project governed?
How will we measure success?
What decisions are required?
If you can't answer these clearly, that's usually a sign the project needs more definition before delivery progresses further.
Why Use a Project Plan on a Page?
Projects rarely stay simple. Multiple workstreams, stakeholders, suppliers, dependencies and competing priorities build up quickly — and the more complicated a project becomes, the more valuable a simple view of the bigger picture becomes.
A well-built one-page plan helps you:
Create clarity: Everyone can see the purpose, objectives and expected outcomes in one place.
Align stakeholders: It gives sponsors, project teams and stakeholders a common reference point.
Focus conversations: Instead of working through pages of documentation, you can use the plan to focus discussion on outcomes, risks, dependencies and decisions.
Identify gaps: Building the plan often exposes what hasn't been properly defined — clear deliverables but no agreed success measures, for example, or an ambitious timeline resting on unconfirmed dependencies.
Support governance: A concise overview is especially useful when preparing for project boards, steering committees and stakeholder meetings.
What Should a Project Plan on a Page Include?
There's no single format every project must follow, but I'd recommend building yours around these twelve areas.
1. Project Purpose
Start with the reason the project exists. Ask: what problem are we solving?
Avoid describing the project purely as a list of activities — "implement a new CRM system" tells you what the project is doing, but not why it matters. A stronger purpose statement might read: "Replace the existing CRM system to improve customer data quality, reporting and user experience."
The purpose sets the context for everything that follows.
2. Business Outcome
What will be different when the project succeeds? This shifts the conversation from delivery to value — for example, "a single, reliable source of customer information with improved reporting and operational efficiency."
3. Objectives
Define the specific things the project needs to achieve, and keep them measurable wherever possible: implement the new CRM, migrate agreed customer data, complete required integrations, train users before go-live, and transition successfully into business operations.
4. Scope
Clearly define what's included, to protect the project from uncontrolled expansion — for example, CRM configuration, data migration, system integrations, testing, user training and implementation.
5. Out of Scope
Equally important. Naming what the project will not deliver — wider business process transformation, replacement of unrelated systems, or future functionality outside the agreed implementation — prevents misunderstandings later.
6. Key Deliverables
List the tangible outputs the project must produce: a configured CRM, migrated data, completed integrations, a tested solution, trained users, and a completed go-live.
7. Key Milestones
Show the major points in the project rather than reproducing the full schedule — for example, Discovery → Design → Build → Test → Training → Go-Live. Milestones help stakeholders see where the project is heading and judge whether delivery is on track.
8. Key Risks
Capture the risks that could materially affect delivery, structured as Risk → Impact → Owner → Mitigation. For example: poor data quality → delayed migration → Data Lead → early data cleansing and validation.
The goal isn't to capture every possible risk — it's to surface the ones that matter most.
9. Key Dependencies
Projects rarely operate in isolation. Consider what the project relies on: supplier availability, business subject-matter experts, technology teams, data owners, other projects, or external approvals. A dependency that isn't visible can quickly become a delivery problem.
10. Governance and Roles
Make it clear who is accountable and where decisions are made — for example, Sponsor → Steering Committee → Project Manager → Workstream Leads. Good governance should make decision-making clearer, not add unnecessary layers of reporting.
11. Success Measures
Define how you'll know the project has actually succeeded — for example, 95%+ successful data migration, 90%+ training completion, no critical defects at go-live, adoption targets met, and benefits tracking established. This is where the project moves from "did we deliver it?" to "did it achieve what the organisation needed?"
12. Decisions Required
Finally, make outstanding decisions visible — approve the final design, confirm the migration approach, approve go-live readiness. A project can look busy and still make little progress if important decisions keep being deferred.
A Project Plan on a Page Is Not Your Entire Project Plan
Worth repeating: the one-page plan should never replace the detailed documentation a project still needs — your detailed schedule, RAID log, risk register, resource plan, communications plan, business case, benefits plan and full governance documentation all still matter.
Think of the Project Plan on a Page as the executive view: it lets people understand the bigger picture without reading every project document.
Keep It Current
A Project Plan on a Page is only as useful as its accuracy. Projects change — priorities shift, risks evolve, dependencies move. A plan that made sense when it was written can be out of date within months.
Good Project Management isn't about blindly following the original plan. It's about recognising when the context has changed and making sure the project responds. Review your one-page plan regularly, and update it whenever there's a significant change to scope, schedule, risks, dependencies, outcomes or governance.
Get Your Free Project Plan on a Page Template
Rather than build this from scratch, use the template. I've put together a free Project Plan on a Page template that structures all twelve areas above, ready for you to complete for your own project.
To get your copy: email essan@tldprojectcoaching.com with "PLAN" in the subject line, or get in touch through the TLD Project Coaching website.
Looking for More Project Management Support?
If you want to strengthen your Project Management skills, build your confidence, or improve the way you approach delivery, TLD Project Coaching has more to help:
Project Management Templates & Tools — practical, ready-to-use resources built to help you manage projects more effectively, including full template systems for kick-off, close-out, stakeholder management, risk and more.
TLD Project Coaching Community — connect, learn and develop alongside other project professionals.
Project Management & Leadership Coaching — one-to-one support to build your confidence, leadership and delivery capability.
Transform • Lead • Deliver
Good Project Management isn't about creating more documentation. It's about creating clarity, making better decisions, and keeping people focused on what matters.
Comments