2.1.1. Projects, Programs, Portfolios and Operations

Recall from Phase 1: a project is temporary and unique, operations are ongoing and repeatable, a program coordinates related projects for shared benefit, and a portfolio groups work to serve strategy. The exam rarely asks you to define these terms outright — it describes a situation and expects you to classify it correctly, including the tricky boundary cases where the classification genuinely could go either way depending on one detail.

💡 First Principle: When a scenario looks ambiguous, look for the word "ongoing" or a defined end date. A one-time initiative to build a new capability is a project, even if what it produces then runs forever as an operation afterward. The project ends where the operational handoff begins.

Reviewing and critiquing project scope. An associate-level team member is often asked to look at a stated scope and flag problems — not write the scope from scratch. Three checks show up repeatedly in scenarios:

• Is the scope actually achievable within the stated constraints? A scope that promises deliverables no timeline or budget in the scenario could support is a red flag.
• Does the scope describe outputs (deliverables) or just activities? Scope should be deliverable-oriented — "a functioning payment gateway," not "have meetings about payments."
• Is anything in the "operations" bucket accidentally scoped into the project (or vice versa)? A project scope that includes "ongoing maintenance after launch" has blurred its own boundary.

⚠️ Exam Trap: "Migrating our email system to the cloud" reads like a project (it has an end date), but if the scenario frames it as one recurring step in a standing IT modernization program that repeats every budget cycle, the correct classification shifts. Always classify based on what the scenario says surrounds the work, not just the work's own description.

Classification isn't fixed at kickoff. A single project that grows over its first year to formally coordinate several newly-related sub-efforts toward one shared benefit has outgrown its original label — it's a program now, not a project that simply got bigger. The reclassification isn't a technicality; it changes what governance, roles, and reporting structure actually fit the work going forward. A scenario describing this kind of growth is testing whether you'll re-evaluate the classification rather than assuming the original label still applies just because no one has formally relabeled it yet.

When "routine department work" hides a real project. A recurring trap: an effort gets waved through as operations simply because the department handling it does similar work all the time, even though the specific effort has a defined end date and produces a genuinely unique, one-time deliverable. Skipping project treatment for something that's actually a project — skipping scope documentation, for instance — creates real risk precisely because the classification, not the department's usual habits, is what should have driven the decision. Both traps share the same root cause: letting surface-level familiarity substitute for actually checking the work against the defining characteristics of each category.