It was a Monday morning. Priya had just been handed her first project – Small Project or Big Project.
It wasn’t a big deal, as projects go – a small internal process change that needed to be rolled out across three teams by the end of the quarter. Four people involved, no external budget, a clear deadline. Simple enough, right?
Then her manager CC’d her on an email with a link to the company’s project management framework. PRINCE2. She clicked through and found herself staring at seven themes, seven processes, 40 activities, 12 baseline documents, nine roles, and a glossary that ran longer than most short stories.
She closed the tab. Opened a blank spreadsheet. And winged it.
Sound familiar?
Here’s the thing – Priya wasn’t wrong to feel overwhelmed. PRINCE2 in its full form is an extraordinary tool, built to govern complex, high-stakes projects with multiple teams, large budgets, and long timelines. Applied wholesale to a small project, it creates more paperwork than progress.
But here’s what most newcomers don’t realize: the principles behind PRINCE2 are exactly what every small project needs. You just don’t need all 200 pages to apply them.
You need five things.
A word about the trap most newcomers fall into
When people are handed PRINCE2 for a small project and find it overwhelming, they tend to do one of two things.
Some do everything – every document, every checkpoint, every report, and spend more time managing the method than the project. The project staggers under its own governance.
Others do the opposite. They pick out the bits that seem easy and skip the rest. They’ll write a timeline (because that feels familiar) but skip the business case (because that feels corporate). They’ll note down tasks but never formally identify risks (because “my project has no risks”). This second approach has a nickname in project management circles: PINO – PRINCE in Name Only. And it’s surprisingly dangerous, because the parts people tend to skip are often the parts that matter most.
The goal isn’t to do everything. It’s to do the right things. Here’s what those are.
1. A one-paragraph reason why this project exists
Before you do anything else – before you make a plan, before you assign a single task – write down, in plain language, why this project is happening.
What problem does it solve? What benefit will it deliver? What happens if it doesn’t get done?
This is your Business Case, and it doesn’t need to be a formal document. It can literally be three sentences. But it needs to exist and be written down, because you’ll refer back to it more than you think. When someone asks you to add scope (“can we also do X while we’re at it?”), your business case tells you whether that makes sense. When the project hits a rough patch, and someone questions whether it’s worth continuing, your business case answers that too.
The question your one-paragraph business case must answer: “Why are we doing this, and is it still worth doing?”
If you can’t answer that, stop and answer it before anything else.
2. One person who can make decisions
Every small project needs a sponsor – one person with the authority to say yes or no when things need to change.
This sounds obvious, but it’s one of the most commonly skipped steps in small projects. Without a named sponsor, decisions get made by whoever is loudest, or whoever happens to be in the room, or, most dangerously, they don’t get made at all, and the project drifts.
Your sponsor doesn’t need to be involved day-to-day. In fact, they probably shouldn’t be. But they need to be:
- Reachable when you need a decision
- Empowered to approve changes, extra budget, or scope adjustments
- Accountable for whether the project delivers its benefit
If you’re a newcomer and you’re not sure who your sponsor is, ask your manager directly: “Who is the person who owns the outcome of this project?” That’s your sponsor.
One important note: the project manager and the sponsor should not be the same person. If you find yourself saying “I am both the manager and the sponsor of this project,” that’s a warning sign that accountability has broken down before you’ve even started.
3. A simple plan that shows what, by when, and who
You don’t need a Gantt chart with 47 dependencies. You need to know three things:
- What are the things this project needs to produce? (the deliverables)
- When does each one need to be ready?
- Who is responsible for producing it?
That’s your plan. It can live in a spreadsheet, a shared doc, a whiteboard photo, or a project tool – the format matters far less than the content. What matters is that everyone involved can look at it and know exactly what they’re doing, and by when.
A few things that make a small project plan genuinely useful:
List deliverables, not just tasks. “Draft communications plan” is a deliverable. “Send some emails” is not. Deliverables have a clear definition of done; tasks don’t.
Include a brief description of what “done” looks like for each deliverable. This prevents that painful end-of-project moment when the team thinks they’re finished and the sponsor disagrees.
Keep it updated. A plan that reflects what was true three weeks ago is worse than no plan at all, because it gives you false confidence.
4. A short list of what could go wrong
“My project has no risks.” This is one of the most common things newcomers say, and it’s almost never true.
It usually means one of two things: either the risks haven’t been thought about, or they seem too obvious to write down.
Both are problems.
A risk register for a small project doesn’t need to be complicated. A simple table with four columns is enough:
| Risk | Likelihood | Impact | What we’ll do about it |
|---|---|---|---|
| Key team member unavailable during critical week | Medium | High | Identify a backup now |
| Stakeholder approval takes longer than expected | High | Medium | Build two extra days into the timeline |
| Scope expands beyond original brief | Medium | High | Refer all changes to sponsor |
The act of writing risks down does two things.
First, it forces you to think about them before they happen, when you still have time to do something.
Second, it creates a paper trail that protects you – if a risk materializes, you can show that it was identified and a response was planned.
You don’t need to identify every possible risk. You need to identify the ones that would significantly affect your timeline, budget, or outcome if they happened.
5. An agreed definition of “done”
Projects without a clear finish line don’t finish – they just stop.
Before you start delivering, get explicit agreement on what the end looks like.
- What will have been produced?
- Who needs to sign off on it?
- What does success look like, in terms that everyone can agree on?
This is your quality check, and it serves two purposes.
The first is practical: it prevents scope creep. If you’ve agreed upfront that the project produces X and Y, you have a defensible basis for saying “Z is out of scope” when someone asks for it three weeks in.
The second is relational: it aligns expectations. Sponsors and stakeholders often have a picture in their heads of what the finished product looks like. If that picture is never articulated, you risk delivering something technically correct that still disappoints.
Get this agreed in writing – even if “in writing” just means an email thread where everyone confirms they’re on the same page.
A quick test: is this actually a project?
Before you apply even this light-touch framework, it’s worth asking a more fundamental question: is this a project at all?
Not everything that gets called a project needs to be managed as one. If the work involves just you, takes less than a few weeks, has a single deliverable, and affects no one else significantly – it’s probably a task, not a project. Manage it accordingly.
A useful rule of thumb: if the work involves more than one person contributing, crosses more than one team or budget boundary, and produces something that others depend on – treat it as a project and apply the five things above.
This matters because treating every task as a project creates “project overload” – a very real phenomenon where teams become so burdened by project governance that they lose the ability to move quickly on the things that genuinely need it.
When to level up – Small Project
These five things will carry you through most small projects. But there will come a point – as projects grow larger, longer, or higher-stakes – where you’ll need more structure.
That’s when it’s worth investing time in the full PRINCE2 framework, or exploring how it combines with Agile delivery methods for projects where the scope and requirements evolve as you go.
The good news is that if you’ve been applying these five principles, you’re already thinking the right way. You understand business justification, governance, planning, risk, and quality. The rest of PRINCE2 builds on exactly those foundations.
Start a Small Project. Do it properly. Grow from there.
Managing a small project right now? Save this post and use the five points above as a checklist before your next kickoff conversation.
And if you’ve learned something from running small projects – the hard way or otherwise – share it on LinkedIn.
