Project Goals: From Mandate to Measurable Objective
What this domain tests
The Project Goals domain checks whether you can turn a project mandate into an unambiguous objective, a defined project result and testable acceptance criteria. Questions typically ask you to distinguish an objective from a result, to spot a weak objective, or to judge whether proposed work still serves the agreed goal.
Core rules
- The project objective states the effect the project must achieve for the organisation: what changes, for whom, and by when. It is written SMART - specific, measurable, acceptable, realistic, time-bound.
- The project result (product, service or deliverable set) is what the project builds in order to create that effect. Objectives sit above results; results sit above deliverables; deliverables decompose into activities.
- Scope boundaries must be explicit - what is in scope and, just as importantly, what is out.
- Acceptance criteria make the result testable and are agreed with the project owner before work starts.
- The business case justifies the project and is re-checked at every decision point. If the objective no longer delivers value, stopping is a legitimate decision.
- Every activity must trace upward: activity → deliverable → result → objective. Work that cannot be traced is scope creep.
Worked example
A hospital laboratory commissions a project. Objective: “Reduce average sample turnaround time from 90 to 60 minutes within nine months for the two busiest departments, without increasing headcount.” Result: a sample-tracking application with scanning points at reception, analysis and reporting. Deliverables: process design, software, interface to the lab system, trained staff, acceptance report. Acceptance criterion for the software: “95% of samples tracked end-to-end during a two-week pilot, timestamps accurate to one minute.” An activity such as “redesign the waiting room” cannot be traced to the objective, so it is out of scope unless a change is formally approved.
Traps that cost marks
- Naming the product as the objective (“deliver a tracking system”) - that is the result, not the effect.
- Objectives with no measure or no deadline, which cannot be evaluated at closure.
- Accepting extra work because it is “small”; informally accepted work is still scope creep.
- Writing acceptance criteria after delivery and bending them to fit what was built.