What a project actually is

The four folded sheets are on Zara’s bedroom wall now, a drawing pin in each corner, and she has started a list of everything the treehouse needs.

It goes wrong by line four. The first three are saw the planks, get the rope, ask Dad about the branch. The fourth is feed Biscuit, which she wrote without thinking, because feeding Biscuit is genuinely something she has to do today.

Her mum reads over her shoulder and draws a line through it.

Zara objects. It is a real job and she does it and nobody else does.

“You did it yesterday,” her mum says. “You’ll do it tomorrow. When is it finished?”

Explain it like I’m 10

Biscuit is never finished.

The treehouse has a last day. There will be an afternoon when the ladder is bolted on and the roof is on and the job is over, and after that there is no treehouse to build, only a treehouse to play in. Feeding Biscuit has no last day. It has a tomorrow, forever, and the only way it ends badly is if someone forgets.

Both are work. Only one of them is a build.

The treehouse does not disappear when the build finishes. It becomes a thing that needs sweeping out, and checking after storms, and arguing about whose turn it is. The build ends and the looking-after starts, and they are different jobs with different people on the hook.

There is a list on the fridge downstairs that makes the same point at a bigger size. It is Dad’s, and it says fence panels, shed roof, bramble patch. Three separate jobs, each with its own last day. But he has been doing them in a particular order, and when Zara asked why the bramble came first he said you cannot carry planks through a bramble patch. The bramble, the treehouse, and the rope swing are all really one thing: the end of the garden becomes somewhere the children actually go. Done separately they are three chores. Done in order they are a garden.

And then there is the thing Dad does in January with a pencil and the bank app, where the garden competes with the car and the bathroom for the same weekends and the same money. Nobody at that table is deciding how to build a treehouse. They are deciding whether the treehouse happens at all this year.

Four different sizes of answer, and the exam expects you to know which one you are standing in.

The grown-up version

Temporary, and unique

PMI’s definition has been stable for a long time and is worth memorising close to word for word. A project is a temporary endeavour undertaken to create a unique product, service, or result.

Two words carry the whole thing.

Temporary means a definite beginning and a definite end. It does not mean short. A programme of work that runs for nine years is temporary in exactly the sense PMI means, and a two-week piece of maintenance that will recur every quarter forever is not. The end arrives in one of three ways: the objectives are met, or it becomes clear they will not be met, or the funding or the need goes away. All three are legitimate endings, which is a point the exam returns to.

Unique means the result did not exist in that form before. This is the word people argue about, usually with housebuilders. The hundredth identical house on an estate still has its own ground, its own permissions, its own weather and its own neighbours, and the output is a house that was not there in September. Uniqueness is a property of the result, not of the method.

One consequence follows from unique, and a lot of exam questions sit on it. If nobody has made this exact thing before, nobody can fully plan it on day one. That is why PMI treats planning as something you do repeatedly at increasing levels of detail rather than once at the start, and why a scenario where a plan is revised is not, by itself, a scenario where something went wrong.

Operations, and the line between

Operations are the opposite case on both counts. Ongoing, repetitive, no defined end, and they keep the organisation running: payroll every month, the support desk, monitoring, the monthly close.

The line between the two is tested more often than it is taught, for three reasons.

The first is handover. Almost everything a project produces goes on to live in operations once the project closes, and getting it accepted into operational ownership is part of closing rather than a favour you do afterwards. A project that has finished building but has nobody signed up to run the result has not finished.

The second is that benefits usually arrive after you leave. The project delivers an output. The outcome and the benefit show up months later, in operational use, counted by someone else. This is why business value is its own topic later in the series instead of a footnote to delivery.

The third is the practical one. A great deal of scope creep arrives dressed as operations work, and it is persuasive because it is genuinely useful work that genuinely needs doing. Running the thing you built, staffing it, monitoring it, handling its first month of tickets: all real, none of it yours unless the charter says so. Recognising operational work as operational work is the first defence, and on the exam it is frequently the correct answer.

A fair objection: long-lived product teams blur this on purpose. A team that has shipped the same product for six years, with a backlog and no end date, is doing work that does not look temporary at all. Both framings exist in practice, and PMI’s own structure accommodates it, because the ECO describes what project managers do and does not require every organisation to arrange its work into projects. For exam purposes, read the scenario for an endeavour with a defined end and a named result. It is almost always there.

When projects travel together: programmes

A programme is related projects, subsidiary programmes, and programme activities managed in a coordinated manner to obtain benefits not available from managing them individually.

The test is that final clause, and it is one you can apply to a real situation. If coordinating the work gains you nothing except a combined status report, you do not have a programme. You have a list. A programme exists when the coordination itself produces something: a dependency that has to be sequenced, a shared benefit case that only adds up when all the parts land, a scarce resource that cannot be in two places.

The bramble is the honest version of this. Clearing it has no value to anybody as a standalone job. It has value because it unblocks the treehouse, and the treehouse plus the swing plus the clearing is what makes the garden usable. Managed separately, they can each succeed while the garden stays unusable.

What this changes for you as a project manager is where a problem goes. An interdependency between your project and another project in the same programme is not a thing you absorb into your own schedule without saying so, and it is not something to renegotiate privately with the other project manager. It belongs to the programme, and your job is to surface it there with the dates and the impact attached.

Portfolios, and the decision you do not get to make

A portfolio is projects, programmes, subsidiary portfolios, and operations managed as a group to achieve strategic objectives.

Operations is in that list, which is the part to notice. The portfolio is the only level that holds both the temporary work and the ongoing work, which makes sense once you see what it is for: it is where an organisation decides what to spend itself on. Not how to do the work. Whether to do it, now, instead of something else.

Portfolio answers which. Project answers how. A portfolio decision looks like fund, defer, reprioritise, or stop.

The uncomfortable implication is one the exam likes. A competently run project can be cancelled, correctly, with nothing wrong in its delivery at all, because the strategy it served changed. If you have internalised that cancellation is a verdict on the project manager, a whole class of questions will read as unfair to you. It is not a verdict. It is the portfolio doing its job, and the professional response is an orderly close-out with the lessons and the assets preserved, not a defence of the business case.

The value delivery system

The Guide’s framing for all of this is the value delivery system, which is the arrangement by which an organisation turns strategy into something it values. Portfolios select, programmes coordinate, projects produce outputs, operations run them, and the outputs become outcomes and then benefits and then value. Direction flows down that chain and information flows back up it.

It sounds abstract until you notice what it does to exam questions. Under the July 2026 outline, Business Environment is 26% of the exam and holds governance, compliance, organisational change, and evaluating changes in the external business environment. Questions in that territory routinely turn on whose objective your project is serving and who needs to know when that objective stops being served. You cannot answer those from inside the project.

Where the boundary shows up on the exam

There is no task on the outline called “define a project”, and you will not get a question asking for the definition of a portfolio. The 26 tasks describe things project managers do, and the boundary sits underneath them as an assumption.

So it gets tested sideways, which is harder. A scenario hands you ongoing operational work and waits to see whether you take it. A scenario puts a cross-project dependency in front of you and waits to see whether you escalate it to the right level. A scenario cancels your project and watches what you do next. In each case the knowledge being tested is the structural one from this post, and the question will be filed under People or Process or Business Environment depending on who is in the room, not on which concept it is really about.

Worth remembering alongside the 40/60 approach split from the first post: none of this changes with delivery approach. An adaptive team has the same boundary with operations and the same obligation to its programme as a predictive one.

Exam trap

Tempting: the data centre migration has been running for four years and has two more to go, so it is operations rather than a project.

Why PMI rejects it: temporary describes a defined end, not a short duration. Six years with a target state, a scope, and a last day is a project, and a fifteen-minute backup check that recurs every night forever is operations. Duration is not the test, and reaching for it is how candidates talk themselves out of the right answer on scenarios involving long programmes of work.

Key points

• A project is a temporary endeavour producing a unique product, service, or result. Temporary means a defined end, not a short one.
• A project ends three ways: objectives met, objectives clearly unreachable, or the need or funding goes. All three are legitimate.
• Operations are ongoing and repetitive with no defined end. What a project builds moves into operations at closing, and transferring that ownership is part of closing.
• Benefits usually land after the project closes, counted by someone else, in operational use.
• A programme is related work coordinated for benefits unavailable from managing the parts separately. If coordination buys you nothing but a combined report, it is not a programme.
• Cross-project dependencies belong to the programme. Surface them with dates and impact instead of absorbing them.
• A portfolio holds projects, programmes, and operations, and decides which work happens against strategy. A well-run project can be correctly cancelled.
• The value delivery system is the chain from strategy through outputs to outcomes, benefits, and value. Business Environment is 26% of the exam and much of it lives on that chain.

Student notes

A printable study sheet for this episode, with the four levels on one side and the project-versus-operations tests on the other, is being put together. Email [email protected] and I will send it across when it is ready, along with the sheets for the other episodes as they are written.

Practice questions

1. Your project delivered a new customer portal, which went live six weeks ago. The operations manager has not assigned anyone to monitor it, and the sponsor asks you to keep your team on it for another quarter to handle incidents and apply patches. What is the best response?

• A. Accept the work. The team built it and knows it best, so this is the lowest-risk option for the customer.
• B. Refuse, since incident handling and patching are operational work and fall outside the project.
• C. Treat the missing operational ownership as an open closing item, and work with the sponsor and operations manager to assign it, with interim cover agreed and time-boxed if it is needed.
• D. Close the project immediately and let operations resolve its own staffing.

Answer

**C.** Transferring the product into operational ownership is part of closing, so the gap is yours to surface and resolve rather than to absorb silently or walk away from. A converts the project team into an operations team and extends the project to cover ongoing work. B is correct about the category and wrong about the behaviour, since naming something as out of scope does not discharge the handover obligation. D abandons a known, unresolved closing item.

2. You manage one of five projects in a programme modernising a bank’s payments estate. Your next milestone depends on an interface another project in the programme is late delivering, and its project manager offers to swap scope with you informally to keep both schedules looking green. What should you do?

• A. Accept, since both projects stay on schedule and the programme is unaffected.
• B. Raise the dependency and the schedule impact at programme level for a decision.
• C. Rebaseline your own schedule to absorb the delay, and report the new dates.
• D. Escalate to the portfolio, since two projects are affected.

Answer

**B.** Dependencies between projects in the same programme are managed at programme level, which exists precisely to obtain benefits that the projects cannot deliver separately. A hides a real programme risk behind two green reports, and "looking green" is the clue that the option is wrong. C absorbs someone else's slippage into your baseline and removes the programme's visibility of the cause. D is the wrong level, since the portfolio decides which work is funded, not how a dependency inside one programme is sequenced.

3. Midway through delivery, and with your project on schedule and inside budget, the organisation changes strategic direction and your project no longer supports any current objective. The steering committee cancels it. Which statement best describes what has happened?

• A. The project has failed, since it will not deliver its scope.
• B. The sponsor has mismanaged the business case, and the cancellation should be challenged with the performance data.
• C. A portfolio-level decision has been taken, and the project should now be closed in an orderly way with deliverables, lessons, and reusable assets preserved.
• D. The project should continue to its next milestone so the investment made so far is not wasted.

Answer

**C.** Deciding which work an organisation funds against its strategic objectives is a portfolio decision, and a project ending because the need went away is one of the legitimate ways projects end. A treats scope completion as the only definition of success. B defends the business case instead of acting on the decision. D is sunk-cost reasoning, which the exam consistently rejects.

Next episode

Knowing where a project sits does not tell you how to behave inside one. PMBOK 8 answers that with six principles, down from twelve in the 7th edition, and they are the closest thing the Guide has to a statement of what good looks like. Next in the series: the first three, holistic view, focus on value, and embedding quality, and why the exam cares what you believe rather than what you can recite.

---

PMP, PMBOK, and PMI are registered marks of the Project Management Institute, Inc. This blog is independent and is not affiliated with, endorsed by, or sponsored by PMI. Content is for study support only and does not count toward the 35 contact hours required for PMP eligibility. Always refer to PMI’s official Examination Content Outline and PMP Handbook.