Defining a Project: What Counts, What Doesn’t
Almost every job contains work that ends and work that never does. Telling the two apart is the first real skill in project management — because the two need completely different handling, and most wasted effort comes from applying the wrong one.
In short
- A project is temporary (it has an agreed end) and produces something unique (it hasn’t been made in this form before).
- Size is irrelevant. A two-week internal tool build is a project; a five-year support contract is not.
- “Temporary” means the end is a condition someone agreed to, not a date that drifts.
- If work fails both tests, managing it like a project adds overhead and removes nothing.
The definition, and why each word is load-bearing
The Project Management Institute (PMI) defines a project in eleven words:
“A temporary endeavor undertaken to create a unique product, service, or result.”
It reads like a formality. It isn’t. Two of those words do all the work, and if you strike either one the sentence stops describing anything useful.
“Temporary” is about the ending, not the length
Temporary does not mean short. A ten-year infrastructure programme is temporary; the helpdesk that supports it afterwards is not. What matters is whether an ending exists and whether anyone has said out loud what it looks like.
That is a higher bar than it sounds. Three endings that look like endings but aren’t:
- “We finish when the budget runs out.” That is a constraint, not a definition of done. It tells you when to stop paying, not when you have succeeded.
- “We finish when it’s good.” Whose “good”? Without a named person who can say accepted, the work drifts until someone loses patience.
- “We finish at the end of the quarter.” A date with no attached deliverable just moves. If missing it changes nothing, it was never an ending.
A usable ending has three parts: what is delivered, who accepts it, and on what basis they accept it. That last one has a name — acceptance criteria — and writing it down at the start is the cheapest insurance in project management. 3.1 Defining Project Scope covers how to write one that holds.
“Unique” doesn’t mean unprecedented
The word trips people up because it sounds like it demands novelty. It doesn’t. Unique means this particular output has not been produced before in this form — which is true of the fortieth office move if the office, the building and the lease are different, and false of the fortieth identical client onboarding if the steps are the same every time.
The practical test is whether the work needs decisions or just execution:
Needs decisions → project
Nobody can hand you a checklist because nobody has done this exact thing. You will discover requirements as you go, and someone has to choose between options. Plan for that with risk management and a schedule that has slack in it.
Needs execution → process
A checklist exists, or should. The improvement lever is not planning but repeatability: fewer steps, less handoff, more automation. Managing it as a project buys you status meetings about work that was never uncertain.
Borderline cases, settled
Most arguments about “is this a project?” are really arguments about how much ceremony to apply. Here is how the two tests resolve the usual suspects.
| The work | Temporary? | Unique? | Verdict |
|---|---|---|---|
| Launching a new product | Yes | Yes | Project. The full apparatus earns its keep. |
| Migrating to a new payroll system | Yes | Yes | Project. Ends at cutover; then becomes operations. |
| Running payroll every month | No | No | Operations. Optimise it; don’t plan it. |
| Onboarding client number 40 | Yes | No | Process. Use a template, not a plan. |
| An open-ended “improve quality” initiative | No | Yes | Not yet a project. Carve out a piece with an end. |
| Building an internal tool over two weeks | Yes | Yes | Project. Small, but genuinely one. |
| Maintaining that tool afterwards | No | No | Operations. This is what closing hands over. |
Note the fifth row. Open-ended improvement work is the most common thing that gets a project name, a kickoff and a channel — and then never ends, because nobody defined what finishing would look like. The fix is not to abandon it; it is to slice off something with a boundary: “cut average response time to under four hours by the end of Q3” is a project. “Improve quality” is an ambition.
Why the label changes what you do
Calling something a project is not an administrative act. It commits you to four things that ongoing work doesn’t need:
- A named owner with authority. Somebody decides trade-offs when scope, time and cost pull against each other — see the triple constraint.
- A plan that can be wrong. Operations run to a standard; projects run to an estimate, which means tracking variance and adjusting. That’s what chapter 6 is for.
- An explicit end. Including the unglamorous part: handover, documentation, and someone accepting responsibility for what happens next.
- Temporary staffing. People are lent to it and returned. That’s why resource allocation on projects is harder than on teams.
Apply those four to routine work and you get overhead with no upside. Skip them on genuinely uncertain work and you get the failure modes in 1.2 Why Project Management Matters.
How this looks in AB
Every workspace in AB Projects is shaped around exactly these two traits. Creating a project asks for a start date, a target end date, the members involved, and a description of what is being delivered — those four fields are “temporary” and “unique deliverable” made concrete.
Use that as a diagnostic. If a piece of work resists the fields — you can’t name an end date without inventing one, you can’t describe a deliverable without describing an activity — that is a signal, not a form-filling problem. Two options that usually work better:
- Recurring work: keep it as a standing board with recurring tasks rather than a project with a fake end date. The Kanban board view suits this better than a timeline.
- Vague ambitions: park them in the backlog until one of them is concrete enough to have an ending, then promote that slice to a project.
Terms used on this page
- Project
- A temporary effort that produces a unique product, service or result. Both halves matter: temporary rules out ongoing operations, unique rules out repeated procedures. More →
- Deliverable
- A specific, verifiable thing the project produces and hands over — a system, a report, a trained team, a migrated database. Deliverables are nouns; activities are verbs. More →
- Acceptance criteria
- The conditions a deliverable must meet before the person receiving it agrees it is finished. Written before the work starts, they turn “done” from an opinion into a check. More →
- Operations
- Repeating work that keeps the organisation running and has no planned end — support, payroll, monitoring. Projects create things; operations run them. More →
- Scope
- The agreed boundary of what the project will and will not produce. It is the thing acceptance criteria are written against. More →
- Handover
- The transfer of a finished deliverable to whoever will operate it, including documentation and responsibility. Unfinished handovers are the main reason projects stay open long after the work stopped. More →
- PMI
- The Project Management Institute, the professional body behind the PMBOK Guide and the PMP certification. Its definitions are the closest thing the field has to a shared vocabulary. More →
Related reading
1.3 Projects vs Daily Operations
The same distinction taken further: how the two kinds of work are staffed, measured and improved differently.
2.0 The Project Lifecycle
What happens between the two boundaries: initiation, planning, execution and closing.
3.1 Defining Project Scope
How to write the boundary down so “done” is a check rather than a debate.