“Every element of scope should have acceptance criteria. And these requirements should derive from somewhere higher up the project food chain — ultimately, to the stakeholders’ objectives and mission.” — Sr. Project Manager, NASA
We’ve established why the project exists (Step 1), who cares about it (Step 2), and we’ve named what we’re creating as deliverables on the project (Step 3). Now we have to agree on how good those deliverables have to be. Welcome to Step 4 of the Project Management Blueprint planning process.
You can hand over every single item listed in an agreed-upon WBS, but still get told that you failed. The scope is not acceptable as delivered. Step 3 establishes what gets built, but doesn’t say how good it has to be when you’re done. That’s what Step 4 addresses: you can’t claim a deliverable meet its acceptance requirements until you’ve written what those requirements are.
Step 4 is about establishing specific and measurable acceptance criteria for every element of scope, from the bottom-layer of a WBS, to the high-level system deliverables. The outputs of this step are the criteria and specs themselves, and on more formal projects, we also create a quality management plan. Good requirements meet a standard we call SMARTTT: Specific, Measurable, Achievable, Relevant, Traceable, Tiered, and Total. In plain terms, every element of scope in your WBS should have at least one acceptance requirement that you can actually test and prove that you’ve met. Here’s why this is so important:
Scope only tells you “what,” not “how good,” and that applies at every level of the WBS, not just the bottom. Take the backyard shed: the deliverable “shed” in your WBS doesn’t tell the contractor whether it needs to pass county inspection, securely lock, or match the house’s paint color. The same gap exists whether you’re talking about one stud in one wall (e.g., it needs to be 2x4 construction) or the entire structure (size, shape, color, etc…). Every element of the work breakdown structure needs its own pre-approved-by-the-stakeholders, acceptance criteria.
Requirements have to trace back to the mission, not arrive willy-nilly. Criteria that don’t derive somehow from Steps 1 and 2 are arbitrary; they’re somebody’s preference dressed up as a requirement.
It’s the basis for acquisition strategy and test planning (Step 5). You can’t write a statement of work, decide on build vs. buy, or plan QC testing without knowing the bar each deliverable has to clear.
It grounds cost and schedule estimates (Steps 7 and 8). “How good” has a price. over-spec and you risk necessarily gold-plating, which drives the budget and schedule. Under-specifying means you risk unhappy stakeholders.
Ambiguous or unachievable criteria are a risk source in their own right (Step 9). A requirement nobody can actually meet doesn’t surface until someone tries to build it, and by then you’ve burned schedule and budget discovering the spec itself was the problem. A positional accuracy requirement set tighter than the hardware can deliver, for instance, isn’t a technical risk so much as a planning failure: it belongs in the risk register the moment it’s written down, not the moment it fails a test.
It’s what closeout (Step 10) actually tests against. A WBS compliance matrix is the proof you created something, a specification compliance matrix means your met the expectations of the stakeholders. In other words, no criteria = no objective basis for sign-off.
Without acceptance criteria, you can’t actually know when you’re done creating a deliverable. Nor will your stakeholders. Further, missing, vague, and/or untestable requirements are worthless. “Software shall be robust” isn’t a requirement; nobody can test it, so nobody can ever be proven wrong. It’s like playing a game of football without a definition of what constitutes a touchdown.
Step 4 is the only thing standing between “I think it’s done” and “I can prove it’s done.”