1.1. What a Project Actually Is
Imagine your company needs a new customer-facing mobile app. That work has a start date, an end date, a fixed budget nobody wants to blow past, and it produces one specific thing — a working app — that didn't exist before. Now compare that to your company's customer support team, which answers tickets every single day, forever, with no defined "done." Both are real work. Both need people to organize them. But they need to be organized differently, and the exam tests whether you can tell which kind of work you're looking at.
💡 First Principle: A project is temporary and produces something unique; operations are ongoing and produce something repeatable. The distinction isn't about how important or how long the work is — a project can run for years, and daily operations can be simple — it's about whether the work has a defined end and a one-of-a-kind result.
Project vs. operations. A project is a temporary endeavor undertaken to create a unique product, service, or result. It has a defined beginning and end, and once the unique result is delivered, the project closes. Operations are ongoing and repetitive — running payroll, staffing a help desk, manufacturing the same part on a production line. Operations sustain the business; projects change it or add to it.
⚠️ Exam Trap: Duration and importance are not the difference between a project and operations. A project can run for years (a multi-year construction build); daily operations can be simple (running a weekly report). The test is whether the work has a defined end and produces something unique — not how long it takes or how critical it is.
Project vs. program vs. portfolio. Once you're comfortable separating projects from operations, the next confusion is scale. A program is a group of related projects, subsidiary programs, and program-level activities managed together in a coordinated way — the coordination itself is what produces benefits you couldn't get by managing each project separately (shared risk management, shared stakeholders, sequencing dependencies). A portfolio sits a level above that: a collection of projects, programs, and other work grouped together to achieve a strategic business objective, regardless of whether that work is related in any operational sense. Think of it as three different questions an organization asks:
| Question being asked | Answered by | Primary concern |
|---|---|---|
| "How do I deliver this one unique thing?" | A project | Scope, schedule, budget for a single deliverable |
| "How do I coordinate several related projects to get benefits none of them would produce alone?" | A program | Cross-project dependencies, shared risk, sequencing |
| "Are we investing in the right mix of work to support company strategy?" | A portfolio | Strategic alignment, prioritization, resource allocation across everything |
| "How do we keep the lights on, day after day?" | Operations | Sustained, repeatable output — no defined end |
⚠️ Exam Trap: A program is not just "a bigger project," and a portfolio is not just "a bigger program." Size is a coincidence, not the definition. A portfolio can contain a single small project and a massive program side by side — what makes it a portfolio is that both were grouped together to serve the same strategic objective, not that one is larger than the other.
Why this matters beyond the exam: if you can't correctly classify what you're looking at, you'll apply the wrong tools. Trying to "close out" an ongoing operations function like you would a project, or trying to manage a whole program using only project-level scope documents, is a common on-the-job mistake the CAPM is specifically designed to screen for — PMI's own research into what associate-level project team members actually need to know (the Job Task Analysis behind this exam) flagged this exact confusion as a recurring gap.
⚠️ Exam Trap: This exam is not simply a PMBOK Guide quiz, even though that's the most common assumption new candidates carry in. It's built from the CAPM Examination Content Outline (ECO), which draws on the PMBOK Guide – Seventh Edition alongside the Process Groups: A Practice Guide, the Agile Practice Guide, and PMI's business analysis guides. Treat the ECO — not any single book — as your syllabus of record.
