The short version: project management is mostly about people, not tools, and the plan you write on day one is wrong by day three; the actual job is noticing that fast, adjusting without drama, and making sure the person doing the work has what they need before they even ask. Anyone selling you a certificate that promises a perfect Gantt chart every time is selling you a fantasy.
What people think it is versus what it is
When I ask small business owners what a project manager does, most say something like “keeps everyone on schedule” or “makes the spreadsheet.” That’s the surface. I’ve run projects with budgets from £3,000 (a rebrand for a two-person consultancy) up to £180,000 (a six-month digital transformation for a mid-size retailer), and the schedule was never the hard part. The hard part was always a person: a supplier who went quiet for nine days, a stakeholder who signed off on a brief and then hated the result, a team member who was drowning and too proud to say so.
Project management, stripped of the jargon, is the discipline of turning a vague goal into a series of decisions, deadlines, and handoffs, then holding those decisions together while reality tries to knock them apart. That’s it. Everything else, the software, the templates, the certifications, exists to support that one job.
The five phases, and why nobody runs them in the tidy order the textbooks show
Every PM course teaches the same five phases: initiation, planning, execution, monitoring, closing. They’re real, and they’re useful as a checklist. But in practice they overlap constantly. You’re still “planning” the last quarter of a project while “executing” the first quarter. Here’s what each one looks like on a real job:
- Initiation: defining what success looks like, in numbers where possible. Not “improve the website” but “get organic traffic up 20 percent in four months.” If you can’t measure it, you can’t manage it.
- Planning: breaking the goal into tasks, assigning owners, setting a budget, and building in slack (I add 15 percent to any timeline a supplier gives me, because they’re always optimistic about their own delivery).
- Execution: the actual doing, which is 80 percent chasing, clarifying, and unblocking, not building.
- Monitoring: weekly check-ins against the plan, and being willing to say out loud “we’re two weeks behind” the moment you know it, not the week before the deadline.
- Closing: the bit almost everyone skips. Documenting what worked, paying final invoices, and having the awkward conversation about what went wrong so it doesn’t happen again.
A real example: the launch that slipped by three weeks
Two years ago I managed the relaunch of a client’s lead generation funnel, new landing pages, a rebuilt email sequence, and a paid ad campaign timed to a product launch date that had already been announced to their list of 40,000 subscribers. Fourteen people touched that project across four organisations: the client’s in-house marketer, a developer, a copywriter, a designer, an ad specialist, and me holding it together.
The plan had us live in six weeks. We slipped to nine. The reason wasn’t the copy or the design, it was a single third-party integration that the developer assumed would take two days and took eleven, because the vendor’s API documentation was wrong and support took four days to reply to a single ticket. Nobody flagged it as a risk in week one because nobody thought to ask “what happens if the vendor is slow.” That’s the uncomfortable truth about most project delays: they’re rarely caused by the work you planned for. They’re caused by the dependency nobody wrote down because it felt too small to matter.
What saved that launch wasn’t a tool, it was one honest conversation in week three where I told the client straight: “We can launch on time with a broken integration, or we launch three weeks late and it works.” She chose late. Nobody was thrilled. But the alternative, launching to 40,000 people with something broken, would have cost far more in refunds and reputation than three weeks ever did.
The skills that matter more than the software
Asana, Monday, Trello, ClickUp, they’re all fine and none of them will save a badly run project. What keeps a project alive is a shorter list than people expect:
- Budget tracking down to the invoice, not the estimate. I track actual spend weekly against the original budget line, because scope creep hides in small approvals that nobody adds up until month three.
- Risk logging from day one, even the risks that feel unlikely. A risk log with ten entries and two that happen is more useful than no risk log at all.
- Stakeholder mapping. Who needs to approve what, and how fast do they usually reply? I’ve worked with a client whose sign-off process took an average of six working days because three people had to see everything, so I built that delay into the schedule instead of fighting it.
- Clear, boring communication. A weekly status email that says what’s done, what’s at risk, and what’s needed from whom, sent on the same day every week, does more for a project than any dashboard.
Marketing projects specifically need one more thing: a way to track whether the work is moving the number you set out to move. If your project is a campaign, you need a firm grip on what a conversion rate measures and how to improve it, because a beautifully delivered project that doesn’t shift the metric was still, in plain terms, a failed project.
What a typical week really looks like
I get asked this a lot by people considering a move into project management, so here’s a step-by-step from a real week running a mid-size marketing project:
- Monday morning: review the plan against actuals, update the risk log, send the weekly status update by 10am.
- Monday afternoon: a 30-minute call with each blocked task owner, not a group meeting, because group meetings let people hide.
- Tuesday to Thursday: unblocking. This is chasing an approval, rewriting a brief that was too vague, or sitting between a client and a supplier who have started to blame each other.
- Friday: budget check, a look at whether the timeline still holds, and updating stakeholders who weren’t in the daily chaos.
Notice what’s missing: there’s very little “managing” of the actual creative or technical work in there. That’s the part most new project managers get wrong. You are not there to do the work or even to judge the quality of it directly, you’re there to make sure the right work happens at the right time with the right information, and that people who need to talk to each other do.
The part most guides skip
Here’s the bit that doesn’t make it into most project management guides: a large part of the job is managing people’s anxiety, not their tasks. Studies commonly cited in project management training put the amount of time a project manager spends communicating at around 90 percent of their working hours. That figure gets quoted constantly and then ignored in practice, because most PM training focuses on charts and methodology instead of the harder skill: telling a client bad news early, telling a team member their work isn’t good enough without wrecking their confidence, and telling your own boss that the deadline they promised externally was never realistic.
Bringing a new person onto a project midstream is its own small crisis, and I’ve seen good projects derail because a replacement contractor was dropped into a live team with no context and no relationship. If you’re onboarding anyone mid-project, even briefly, it’s worth borrowing from onboarding best practice rather than assuming a Slack invite is enough; there are simple ways to break the ice with a new team member that pay for themselves within the first week by getting someone contributing instead of guessing.
And here’s the part people really don’t want to hear: a good project manager sometimes has to be the person who says “no” to a client, a boss, or their own team, even when it makes them unpopular for a week. If your instinct is to keep everyone happy at all costs, project management will wear you down fast, because the job regularly requires disappointing someone on purpose to protect the outcome.
Where automation helps (and where it doesn’t)
Marketing projects in particular benefit from automating the repetitive parts, reminder emails, status pulls, lead scoring, so the human time goes into the judgement calls. There are a number of marketing automation tools worth building into a project workflow, and I use several of them to cut down the admin that used to eat a full day of my week. But automation can only handle what’s predictable. It won’t spot that a client has gone quiet because they’re nervous about the direction, or that a developer is burning out and about to miss a deadline they haven’t flagged yet. That’s still a human job, and I don’t think it’s going anywhere soon.
How to get started if you’ve never managed a project
- Pick a project you already own, even a small one, and write down the goal as a number, not a feeling.
- Build a simple task list with owners and dates. A spreadsheet is fine to start.
- Start a risk log with at least five things that could go wrong, however unlikely they feel.
- Send one weekly status update, even if it’s three lines, and do it on the same day every week without fail.
- When something slips, say so within 24 hours. The projects that fail badly are the ones where the delay was known for two weeks before anyone admitted it.
None of this requires a certification to start. It requires the willingness to have the uncomfortable conversation on day three instead of day thirty.
Frequently asked questions
What does a project manager do all day?
Most of the day is spent communicating: unblocking stuck tasks, chasing approvals, updating stakeholders, and adjusting the plan against reality, rather than building the deliverable itself.
Do you need a certification like PRINCE2 or PMP to manage projects?
No. Certifications help with structure and can matter for larger organisations or government contracts, but small business project management runs perfectly well on clear task lists, honest weekly updates, and a risk log kept from day one.
What’s the biggest cause of project delays?
Small dependencies nobody wrote down as risks, a slow vendor, an unclear approval chain, a task that felt too minor to flag, not the big obvious tasks everyone plans carefully around.
Is project management the same as team management?
No. Team management is about developing people over time; project management is about coordinating a defined piece of work with a start and end date, often across people who don’t report to you at all.
