Study CAPM What Makes a Project Temporary and Unique: key concepts, common traps, and exam decision cues.
A project is temporary work that creates a unique product, service, or result. That sentence is basic, but CAPM uses it to drive many later decisions about authorization, planning, governance, and closure.
Candidates often weaken this idea in three ways:
All three mistakes lead to weaker decisions. A project can last a long time and still be temporary because it has a defined end. A result can be unique because of context, users, constraints, or objectives even if the organization has done similar work before. Progressive elaboration means detail grows as knowledge grows, not that scope control disappears.
flowchart LR
A["Temporary effort"] --> B["Unique result"]
B --> C["Planning detail grows"]
C --> D["Formal close and handover"]
That pattern matters because it separates change work from steady-state business work.
When a scenario describes a rollout, relocation, system replacement, policy implementation, or one-time compliance change, CAPM usually expects you to treat it as project work. The ongoing use or support of that delivered capability after handover is something else.
That is why project classification is rarely just an abstract definition. It shapes whether authorization and closure matter, how planning detail evolves, and when ownership transitions to operations.
Another common mistake is assuming that if the benefit lasts for years, the work cannot be a project. CAPM treats the change effort and the enduring benefit as different things. The project ends. The resulting product, service, capability, or benefit may continue long after the project has been accepted and closed.
This matters because some questions mix delivery work with business value intentionally. The correct answer usually depends on separating the temporary effort from the ongoing result it creates.
Candidates sometimes wait for a completely unprecedented effort before they are willing to call work unique. CAPM is broader than that. Work can still be unique because the stakeholders, timing, regulation, technology mix, location, or outcome constraints are different from earlier efforts. That means recurring work types can still be project work when the current change has its own defined objective and boundary.
This is especially useful when the organization has repeated implementations, upgrades, or site rollouts. Similar does not automatically mean non-project.
Progressive elaboration is strongest when you read it as controlled learning. The team is allowed to refine detail as more information becomes available, but that refinement still happens inside approved scope boundaries, governance, and change control. CAPM does not reward candidates who use progressive elaboration as an excuse for vague planning or informal expansion.
That is often the real exam trap: confusing evolving detail with uncontrolled scope.
Scenario: A department is moving from a manual onboarding process to a new digital onboarding workflow. A team member says the work is not a project because the onboarding process will continue permanently after the rollout.
Question: How should the team classify that onboarding effort?
Best answer: B
Explanation: CAPM separates the temporary change initiative from the ongoing use of the resulting capability. The implementation is project work; routine use afterward is not.
Why the other options are weaker: