How do you know how much process and documentation are enough to keep a project on track (without burying your team and clients in overhead)?
This is, genuinely, one of the harder problems in project management for small agencies. It took me years to get it roughly right, and I’m still calibrating.
I’ve been managing projects at a software agency since 2018. I’m PMP and PRINCE2 certified, and — full disclosure — I am a type A individual who enjoys a spreadsheet. I’ve had to actively resist my instinct to document everything in favour of asking what actually moves the project forward.
The core problem is this: project management frameworks are designed for enterprise and large teams. PRINCE2, PMI’s PMBOK, SAFe — these are thorough, rigorous, and largely overkill for smaller teams delivering a client app in ten weeks. And yet, I’ve never met a project that didn’t benefit from some structure. The question is never “should we have project management” but rather “how much project management does this project actually need?”
In this post I’ll walk through three tiers of PM structure, the triggers I use to decide which applies, and the tools that sit behind each one.
A Quick Glossary
(skip if you know your sprints from your standups)
Some of the language below comes from agile project management. If you’re not steeped in it, here’s the short version:
This porridge is too hot!
When I Over-PMed: The PRINCE2 Phase
When I first started project managing, I wanted a framework I could point to for the decisions I was making. I chose PRINCE2 — a popular project management framework in the UK, originally created by the government to manage software projects and now used across sectors with extra governance requirements. On paper, it’s thorough. In practice, for a small agency, it was a mistake.
PRINCE2 is built around its artefacts — the documentation. Even when tailored, it pulls you towards quality registers, daily logs, issue logs, risk logs, and a Project Initiation Document (PID) that can run to many pages. I added all of these. I built a dedicated Google Site for each project. I ran meetings to review quality requirements and surface issues.
I realised I had it wrong when three things happened in quick succession:
• There was audible frustration from the team about PM meetings
• I discovered nobody was actually accessing the documentation
• Project success seemed to depend almost entirely on the lead developer — and was completely unrelated to the PM framework I had wrapped around them
The lesson: process that nobody uses is not project management. It’s just overhead. Documentation that doesn’t inform decisions doesn’t protect the project — it just takes time away from the people delivering it.
This porridge is too cold.
When I Under-PMed
I’ve yo-yoed to the opposite extreme too. (Should I confess this?) I’ve run projects with little to no PM intervention: scoping with a client, writing a statement of work with defined deliverables, and handing it over to a lead developer with an expected delivery date.
Here’s the thing… sometimes it worked. The developer was strong, the scope was tight and clear and didn’t change. But I had essentially delegated all project management to the developer, and the success was entirely personality-dependent. It could not scale nor handle bumps in the road, AND it was genuinely unfair on team members and clients.
When it didn’t work, we found out later than we could comfortably recover from. That’s the tell. No-process projects don’t fail loudly — they drift quietly until someone asks an uncomfortable question and the answer is bad.
Just right.
The Framework I Use Now: Three Tiers of Project Management
The honest answer to ‘how much project management do I need’ is: it depends, and you need to assess it at the outset of every project. I categorise every project into one of three tiers before we start. The tier informs the documentation, the touchpoints, and the tools. The assessment can and should be adjusted as the project evolves.
The Sprint Board Test If looking at the active sprint board gives you a complete picture of the project — where it is, whether it’s on track, what’s left — you’re in lightweight territory. If it doesn’t, you need more structure.
Here are the three tiers, with the triggers I use to assign them:
🟢 Tier 1: Lightweight
One person. Simple deliverable. Everything fits on the sprint board.
A project is lightweight if all three of the following are true:
• It can be delivered by one person
• The high-level deliverable can be described and understood simply
• The active sprint board gives you a complete picture of progress
It can run for more than one sprint — but I should be confident from the outset that if the stories are progressing, the project is on track. The sprint board is the project.
Real example: We built a small mini-game for a client to incorporate into their app. The deliverable was well-defined, we had design assets, the stack was familiar, and a single developer owned it end-to-end. It was scoped for one sprint with two sprints of buffer. At no point did we need anything beyond the sprint board and a shared requirements doc to know exactly where we stood.
At the start of a lightweight project, I break requirements into a simple spreadsheet — one row per requirement — and set up a project page in Slack with links to files, contacts, and any external references. The developer works from Jira stories and is encouraged to contact the client directly with questions. The requirements doc doubles as the final checklist before we deliver.
Lightweight: Documentation
• Statement of work
• Project page in Slack (links, contacts, references)
• Requirements spreadsheet
• Shared project folder
• User stories on Jira
Lightweight: Touchpoints
• Daily standups
• Client contact as needed (no fixed meetings)
🟡 Tier 2: Medium
Multiple people or deliverables. The sprint board no longer tells the whole story.
A project moves into the medium tier when any one of the following is true:
• More than one person is working on it simultaneously
• It has more than one major deliverable
• It is expected to last longer than two sprints (roughly a month)
The sprint board is still a core tool, but it no longer gives you the complete picture. There are parts of the project that aren’t visible there — dependencies, resource gaps, client feedback loops, upcoming holidays. This is where the absence of additional structure starts to cost you.
Real example: Delivering a client app that included multiple mini-games, custom content, and external suppliers for assets. Multiple developers were working simultaneously, and at any given point the sprint board showed what was active — but not the full shape of the delivery or the external dependencies we were managing.
For medium projects I add a project kick-off — usually separate ones for the team and the client. If the project involves unfamiliar territory or a new stack, the internal kick-off is where we surface that and decide whether to front-load research. Better to find the bottlenecks at the start than halfway through.
I also introduce sprint reports — a fortnightly summary I send to the client that covers progress, any issues or open questions, and a RAG status. Clients don’t always read them religiously, but they serve two purposes: the client always has a current picture if they want it, and I have a consistent record of how the project was tracking over time.
Resource planning also becomes important here. Holidays, illness, external dependencies — these need to be anticipated and monitored proactively, not noticed after they’ve already caused a slip.
Medium: Additional Documentation
• Sprint reports with RAG status
• Extended Slack project page (stages, milestones, quality expectations)
• Resource/availability tracking
Medium: Additional Touchpoints
• Project kick-off (internal + client)
• Fortnightly sprint reports / review meetings
• Post-mortem
🔵 Tier 3: Full Structure
Multi-month. External stakeholders. Governance requirements. The sprint board is one of many views.
Full structure projects are the large ones. They are typically multi-month, often involve external project managers or funders, and carry governance requirements that go beyond our normal process. The sprint board remains part of the picture, but it’s one lens among several.
Real example: We built Japeto Chat, funded by an Innovate UK Smart Grant. An 18-month project with quarterly reporting to an Innovate UK advisor, multiple deliverables spanning feature development and community engagement, and a team that had to be continually managed around other incoming projects.
These projects look more like the PRINCE2 projects I used to run — except I’ve learned to be selective about which artefacts actually earn their place. What I’ve found is that the overhead isn’t optional here; the governance is real and the consequences of poor documentation are real. The difference from my early PRINCE2 days is intentionality: every document has a clear owner, a clear update cadence, and a clear audience.
I maintain checklists of the documents in play and scheduled reminders to update them. On the development side, Jira stories are still the execution layer — but we work in epics, and it’s common for projects to pause and restart as external dependencies resolve. This means the delivery team needs to be actively managed back onto the project, and communication about the big picture has to happen regularly.
We use quarterly team days to realign on large projects and set expectations for the coming months. For a full-structure project, these are as important as any sprint ceremony.
Full Structure: Additional Documentation
• Quality register
• Issue log
• External reports (e.g. funder reporting)
• Epic-level planning in Jira
• Document register with update schedule
Full Structure: Additional Touchpoints
• Quarterly team alignment days
• External funder / stakeholder meetings
• Re-onboarding sessions when the project restarts after pauses
Tools: Right-Sized Too
The tools should match the tier. One of the quickest ways to make a small project feel more bureaucratic than it needs to be is to put it into a project management tool that’s designed for something three times its size.
Closing: The Real Skill Is the Judgment Call
The more experience I get, the easier it becomes to match the right level of oversight to a project. It’s still a judgment call every time — but the criteria get clearer with practice.
I have clients who like to be heavily involved and want more documentation. I have clients who want to be pinged when something is ready to review. The framework adjusts. The point is that it starts from somewhere considered, not from habit or from whatever template I used last time.
Project management in a small agency isn’t about following a methodology. It’s about answering one question: can everyone on this project — the team, the client, and me — see what’s happening without having to ask? If the answer is yes, you probably have enough PM. If the answer is no, something needs to change.
Nobody wants extra meetings or documentation for its own sake. And nobody wants to be working without any idea of whether they’re doing a good job. The goal is the useful middle — enough structure to create clarity, light enough to stay out of the way of the work.
Lessons Learned
• Strong delivery partners will rescue you if your PM is poor — but this is a lottery, and it’s unfair on clients and team members in the long run
• The best projects have PM involvement that is demonstrably useful to both the delivery team and the client. If nobody can see the value, there may not be any
• People do not always voice frustration. As I’ve gotten better at leading projects, I’ve learned to read the room. If your team or client is frustrated, a PM should have stepped in and reassessed before it got to that point
• Right-sizing project management is itself a project management skill — and one that most frameworks don’t teach you
