What Are the Key Project Management Processes? A Plain Explanation

The short version: project management processes are the five groups of activity that any project moves through, starting, planning, doing, checking, and finishing, and the official PMBOK guide breaks these into 49 smaller processes across ten knowledge areas. Most small businesses and freelancers only need a handful of these to run a good project, and pretending you need all 49 is where a lot of people waste time they don't have.

The five process groups, in order

Every recognised project management framework, whether you're following PMI's PMBOK guide or a stripped down version for a two person team, comes back to the same five buckets:

• Initiating: defining what the project is and whether it's worth doing
• Planning: working out how you'll get there, who does what, and by when
• Executing: doing the work
• Monitoring and controlling: checking progress against the plan and adjusting
• Closing: formally finishing, handing over, and capturing what you learned

The Project Management Institute's PMBOK Guide (sixth edition) lists 49 individual processes sitting under these five groups, spread across ten knowledge areas like scope, cost, schedule, quality, risk and communications. That number sounds overwhelming, and it is, for most small business projects you'll use a fraction of it. I'll get to that.

Initiating: the process everyone rushes and regrets

Initiating is where you write the project charter, name the sponsor, and confirm the business case. It sounds like paperwork. It is not. It is the one process, in my experience, that gets skipped most often and causes the most expensive problems later.

I worked with a mid sized B2B client a few years back who wanted a full website rebuild done in six weeks to hit a trade show launch. Nobody wrote down what "done" meant. Marketing thought done meant the new site was live. The founder thought done meant the site was live, converting at a target rate, and integrated with a new CRM. We were three weeks into build before anyone said the CRM part out loud. That single missed conversation in the initiating phase cost us an extra four weeks and a very awkward call with the founder. The lesson stuck with me: a one page charter that states scope, budget, timeline, and what "finished" looks like takes an hour to write and can save weeks.

Planning: where most of the 49 processes live

Planning is the biggest of the five groups by far, this is where you build the work breakdown structure, set the schedule, estimate costs, identify risks, and decide how you'll communicate. On a big infrastructure project this might mean 20 separate planning documents. On a client marketing campaign it might mean a spreadsheet, a shared calendar, and a short risk list with three items on it.

Here's the uncomfortable bit nobody likes to say out loud: most small teams do not need formal planning processes for cost estimating, procurement management, or stakeholder engagement plans. If you're running a content marketing rollout for a client with a budget of five thousand pounds and one point of contact, formally documenting a "stakeholder engagement plan" is theatre. Use the processes that match the size of the risk. A project with six figures of budget and twelve stakeholders needs the full planning suite. A four week social campaign does not, and pretending otherwise just burns billable hours on documents nobody reads.

This is also where choosing a working method matters, because the processes get applied differently depending on whether you're running things in a straight line or in short cycles. If you haven't settled on how your team works, it's worth reading through the main project management methodologies explained in plain English before you build a single Gantt chart, because the planning process looks very different in waterfall versus agile.

A short, real planning checklist

• Write the scope statement, one paragraph, what's in and what's explicitly out
• Break the work into no more than 15 to 20 tasks for anything under three months
• Assign an owner to every single task, not a team, a named person
• List your top three risks and what you'll do if each one happens
• Agree how often you'll update the client or sponsor, and stick to it

Executing: the process people confuse with the whole project

Executing is the actual doing, the writing, the building, the designing, the meetings that produce deliverables rather than discuss them. It's the process most people think of when they hear "project management" and it's also the one that takes care of itself if initiating and planning were done well. Bad execution is almost always a symptom of a skipped earlier process, not a failure of the people doing the work.

This matters more than ever with distributed teams, where you can't walk over to someone's desk to check they understood the brief. If your team is spread across time zones or working remotely, the execution process needs tighter written communication than an office based team would. I've written more on this in what remote work means in practice, and the short version is that remote execution lives or dies on documentation, not on trust.

Monitoring and controlling: the process that runs alongside everything else

This one doesn't happen after execution, it happens during it, constantly. It's the weekly check against the schedule, the budget tracking, the change requests, the quality checks. On paper this is where you catch scope creep before it becomes a full blown different project.

Here's a number that surprises people: on most of the client projects I've run, roughly 30 percent of the original scope shifts by the midpoint. That's not a failure, that's normal, clients learn things, markets move, competitors launch something first. The process that saves you is having a change control step, however informal, where a scope shift gets written down and the timeline or budget gets adjusted to match, rather than just quietly absorbed by the team working longer hours for free.

Closing: the process almost everyone skips

Closing is formally ending the project, confirming deliverables were accepted, releasing the team, and running a proper retrospective. This is the process I see skipped more than any other, including initiating. Teams love starting things. They are far less enthusiastic about sitting down to write up what went wrong and what should change next time, because the project is "done" in everyone's head the moment the deliverable ships.

Skipping closing has a real cost. Without it, the same mistakes repeat project after project because nobody captured them anywhere. A 30 minute retrospective, three questions, what worked, what didn't, what we'd change, gets you most of the value with almost none of the effort people assume a "lessons learned" process requires.

Why this matters even if you never run a formal project

You don't have to be a certified project manager for these five processes to be useful. If you're running your own business, understanding where you get stuck tells you a lot about where you personally are a bottleneck. I've talked to founders who couldn't tell me what "done" looks like for their own product launch, which is an initiating failure, and founders who can't take two weeks off because nothing has ever been documented, which is a closing failure that never happened in the first place. If that sounds familiar, it's worth running through the founder dependency audit to see how much of your business only exists in your head.

It's also worth knowing this stuff if you're job hunting. Understanding the five process groups and being able to talk about a real project you initiated, planned, and closed is far more convincing to a hiring manager than the word "organised" sitting alone on a CV. If you've run any kind of project, paid or unpaid, freelance or as a side hustle, it belongs on your CV described in these terms. There's a good guide on putting side hustles on your resume the right way, and another on writing the skills section of your resume without filling it with rubbish, both worth reading if you're trying to translate "I ran a thing" into language a hiring manager takes seriously.

The number that matters

If you take one thing from the full 49 process list, take this: you do not need all of them, on any given project, ever, in practice. Even PMI's own later guidance moved away from prescribing rigid processes toward principles, because too many teams were treating the process list as a compliance exercise rather than a way to get work done. Pick the five to ten processes that match your project's size and risk. A small campaign needs a charter, a task list, a risk note, weekly check ins, and a short retrospective. That's five processes doing the job of forty nine.

Related: the product management page.

Frequently asked questions

What are the five project management process groups?

They are initiating, planning, executing, monitoring and controlling, and closing. Every project moves through some version of these five stages, whether it's formally documented or just happening in someone's head.

How many project management processes are there in total?

PMI's PMBOK Guide sixth edition lists 49 individual processes spread across the five groups and ten knowledge areas, though most small teams only ever use a small subset of these in practice.

Do small businesses need to follow all the formal project management processes?

No. Formal processes like detailed procurement management or stakeholder engagement plans are built for large, high risk projects, a small campaign or short client project usually only needs a charter, a task list, a risk note, and a short closing review.

Which project management process gets skipped most often?

Closing. Teams are quick to start work and slow to formally finish it, which means retrospectives and lessons learned rarely happen, and the same mistakes get repeated on the next project.