Project and Program Fundamentals
This domain tests whether you can tell a project from a program and a portfolio, and whether you can apply the control model that fits each. A project produces a defined output within a finite lifecycle; a program coordinates related projects to deliver benefits no single project could; a portfolio is a prioritized investment pool governed against strategy.
Work containers and lifecycle
- A project has a charter plus scope, schedule and cost baselines; approval to proceed is a phase-gate decision, not a status meeting.
- A program adds benefit dependency management, tranche planning and a business case that survives beyond project closure.
- A portfolio adds prioritization, capacity balancing and explicit kill decisions.
Governance and benefits
The business case is a living decision document. Benefits are measured after handover, so a project can be on time and on budget yet still fail if adoption or outcome targets are missed. Governance assigns decision rights: the sponsor owns the business case, the project manager owns delivery, and the steering group resolves escalated trade-offs.
Worked example
A project has a fixed regulatory date, a fixed budget and a new scope item that adds two weeks. The project manager should not silently absorb the work. The correct sequence is to quantify schedule and cost impact, identify options such as reducing scope elsewhere, adding resources or accepting a phased release, then escalate to the sponsor because date and budget are both constrained. The reasoning is that the triple constraint has no free variable once two legs are fixed.
Traps
- Treating a large project as a program; programs are defined by benefit coordination, not size.
- Reporting percent complete without a baseline; progress is meaningless against a moving target.
- Confusing outputs with benefits.