Project Management Fundamentals
Domain 1: Project Management Fundamentals
This domain tests precise use of core project language: what a project is, how it differs from programs and operations, which constraints shape decisions, and how organizational structure changes the project manager's authority. Expect scenario questions that ask you to classify work, identify the governing constraint, or select the right lifecycle and governance model.
Core rules and concepts
- A project is a temporary endeavor undertaken to create a unique product, service, or result. Temporary means it has a defined start and end; unique means the outcome is not routine repetition.
- A program is a group of related projects managed together for benefits that would not be realized separately. A portfolio is a collection of projects, programs, and operations selected to meet strategic objectives.
- Projects are progressively elaborated: high-level scope becomes more detailed as information improves. Planning is iterative even on predictive projects.
- The competing constraints are scope, schedule, cost, quality, resources, and risk. 'Triple constraint' is shorthand for scope, time, and cost, but quality, resources, and risk also trade off.
- Project lifecycle phases typically include initiation, planning, execution, monitoring and control, and closure. Monitoring and control overlaps execution rather than following it.
- Organizational structure affects authority. Functional organizations keep authority with functional managers; projectized organizations give the project manager high authority; matrix organizations share authority and require clear role negotiation.
- The sponsor authorizes the project, provides funding, and escalates beyond the project manager's authority. The project manager plans, executes, and controls work within the charter.
- A PMO can be supportive (templates and coaching), controlling (compliance with methods), or directive (directly manages projects).
Worked example
A payroll team must replace a statutory reporting module before a regulatory deadline. The work is temporary, produces a unique system change, and has a fixed compliance date. The correct classification is a project, not operations, because the work ends after the new module is accepted. The binding constraint is schedule; scope is largely fixed by regulation; cost and quality trade off around testing depth and contractor use. A predictive lifecycle with staged acceptance fits because the deadline and regulatory requirements are stable; agile delivery could still be used inside phases, but the governance gate is date-driven.
Traps that cost marks
- Calling recurring payroll processing a project. Routine operations are not projects.
- Treating the triple constraint as only three variables and ignoring quality, risk, or resources.
- Assuming a matrix organization gives the project manager full authority over staff.
- Confusing the sponsor's funding and escalation role with the project manager's delivery role.
- Assuming agile is always the right lifecycle; regulated fixed-date work may need predictive governance.