What Is Project Management?
Project management is the practice of getting a specific, non-routine outcome delivered — on a deadline, with people who mostly do not report to you, while the ground keeps moving. Everything else is technique.
In short
- A project is temporary and produces something new. If it runs forever, or you have done it forty times, it is something else and wants different handling.
- The job is mostly decisions and blockers, not charts. Charts are how you find out where the decisions and blockers are.
- Nobody needs the job title to do the work. Most projects are run by someone whose title says something else entirely.
- The apparatus should match the risk. Full project management on small, repeatable work is how the discipline earned its reputation for bureaucracy.
The definition, and why it is worded so carefully
The standard definition — from the Project Management Institute — is that a project is “a temporary endeavour undertaken to create a unique product, service, or result.” That sounds like jargon until you notice that both adjectives are doing real work.
Temporary means it has an end, and that the team assembled for it will disband. This is why projects need explicit closure and why handover is a real activity rather than an afterthought: the people who built the thing will not be there to look after it.
Unique means you have not done exactly this before. This is why estimates are uncertain, why risk management exists, and why copying last year's plan without thinking is such a reliable way to get hurt. If the work were repeatable, you would not need a plan — you would need a checklist.
So is the thing on your desk a project?
The two adjectives give you a test, and it is more useful as a grid than as a definition, because it also tells you what to do when the answer is no.
What a project manager actually does all day
People imagine the job is producing schedules. Schedules take a fraction of the time. The bulk of it looks like this:
- Making decisions happen. Most delay is not slow work — it is work waiting on a decision nobody has scheduled. A large part of the job is noticing what is undecided and going and getting it decided.
- Removing blockers. An hour spent unsticking someone routinely buys back days. This is the highest-return activity available and it never appears on a plan.
- Keeping one version of the truth. When five people hold five different mental models of the project, they will make locally sensible decisions that do not fit together.
- Saying no, and saying it early. Every accepted addition displaces something. The job is to make that trade visible before it is accepted rather than discovering it in week nine.
- Translating between altitudes. Engineers describe work in tasks, sponsors think in outcomes and dates. Someone has to convert faithfully in both directions.
- Protecting the team's attention. Absorbing interruptions so that the people doing the work can hold a thought for more than twenty minutes.
Notice how little of this requires software. The tools in chapter 5 exist to make these six things visible — they do not do any of them for you.
What it looks like when this is missing
Projects rarely fail loudly. They fail as a slow accumulation of small ambiguities, and the symptoms are recognisable long before anyone says the word “late”:
- Nobody can say in one sentence what finished looks like. Ask three people separately; if you get three answers, the project has no agreed destination.
- Work keeps arriving without displacing anything. Scope is growing and the deadline is not moving, which means quality is quietly absorbing the difference.
- The same question is answered repeatedly in chat. There is no shared source of truth, so everyone reconstructs it privately.
- Every problem is a surprise. Not because problems were unforeseeable, but because nobody was asked to foresee them.
- Progress is reported as a percentage that stalls near the end. A reliable sign that “done” was never defined.
Do you need the job title?
No, and most people doing it do not have it. Projects are run by marketing leads, engineers, operations managers, founders and office administrators — anyone who ends up responsible for something with a deadline and moving parts.
This matters for how you read the rest of the guide. Very little of it requires authority. Writing down what “done” means, asking what could go wrong before it does, and noticing which task everything else is waiting on are all available to anyone on the team. If you are on a project rather than running one, these chapters mostly explain the machinery you are already inside — which is the fastest way to stop being surprised by it.
How much project management is enough?
Match the apparatus to the cost of being wrong. A two-week internal task needs a clear goal, an owner and a date — that is the whole plan. A twelve-month regulated programme with six teams and an immovable launch needs the full set: scope document, risk register, change control, formal handover.
Getting this wrong in either direction is expensive. Under-manage genuinely complex work and it drifts; over-manage simple work and you spend the budget on process while people quietly route around you. The grid above is the first cut at that judgement, and the chapters that follow are all right-sized rather than applied wholesale.
What this chapter covers
Defining a Project
The two adjectives in detail — temporary and unique — and the everyday work that qualifies without looking like it.
Read 1.1 →Why It Matters
Why the discipline exists, what it costs when it is absent, and why coordination has got harder rather than easier.
Read 1.2 →Projects vs. Daily Operations
Why the same management approach fails on the other kind of work, and how to tell which one you are actually holding.
Read 1.3 →How this looks in AB
In AB Project Management a project is a container with its own tasks, members, statuses and Wiki — which sounds obvious until you compare it with running work out of a shared inbox or a spreadsheet. Because every task carries an owner, a due date and a status history, the two things this chapter says are hardest — knowing what is undecided and knowing what is blocked — are visible without asking anyone. And since AI assistants can act through the MCP server, the routine chasing that fills a project manager's afternoon can happen without a human in the loop.
Terms used on this page
Every term below is defined at more length in the full project management glossary.
- Project
- A temporary endeavour producing a unique result. Both adjectives matter: temporary means it ends and the team disbands; unique means you have not done exactly this before. More →
- Operations
- Ongoing, repeatable work that keeps the organisation running. Optimised for efficiency and consistency rather than delivered to a deadline.
- Deliverable
- A tangible, verifiable output — a document, a system, a migrated database. Not an activity: “run workshops” is a task; “approved requirements” is a deliverable. More →
- Scope
- What the project will deliver — and explicitly what it will not. The one constraint you control directly at the start. More →
- Triple constraint
- Scope, time and cost interlock, with quality in the middle. Change one and at least one other has to move — which is why “yes, from time or from budget?” is the useful reply. More →
- Sponsor
- The senior person who owns the business case and can resolve what the team cannot. The strongest single predictor of whether a project succeeds. More →
- Stakeholder
- Anyone who affects the project or is affected by it — including the people whose daily work your deliverable will change. More →
- Blocker
- Anything stopping work that the person holding it cannot resolve alone. Unblocking is the highest-return hour available to a project manager. More →
- Scope creep
- Gradual expansion through small additions that each seem trivial and together consume the schedule. More →
Related reading
The shape of a project
How the work divides into four phases, and what each one is responsible for.
2.0 The Project Lifecycle →Doing it for real
Scope, schedule, resources and risk — the four decisions every plan has to settle.
3.0 Planning Basics →Every term, in one place
One hundred and two pieces of vocabulary explained in plain English, each linked to its chapter.
Project Management Glossary →