Are You S.M.A.R.T.T.T?
Are You S.M.A.R.T.T.T?
The Seven Requirements of High-Quality Quality Requirements
“How good is good enough?” —Andy Stanley
A WBS lists what a project is supposed to deliver. I.e., the “scope” of the project. Scope comes in three basic flavors: Products, Results, and Services. We’ve discussed all of this before (e.g., here, here, and here.)
We’ve also talked about the concept of Quality (e.g., here), but what we’ve not covered is how we create (pun intended) high-quality Quality Requirements. This is a key factor in meeting the expectations of your stakeholders. It’s not enough to build a house (i.e., Scope = House); we also have to build it to our stakeholders’ requirements and specifications. Creating and delivering a 500 square-foot wooden shack is not the same as handing over the keys to a 5,000 square-foot marble palace. Technically, they both would be listed as simply “house” in a WBS, but you won’t have a happy stakeholder if they were expecting a mansion and you deliver a cottage.
Every single element in your WBS must have some kind of acceptance criteria tied to it. Each must have measures of acceptance that are both objective and verifiable for both you and the customer to agree upon—before planning or building anything. Without quality acceptance criteria, the likelihood of mismatched expectations grows exponentially on a project. Creating sound quality requirements is a fundamental aspect of planning a project.
For instance, imagine a WBS scope element of “bicycle frame.” This is fine, but it’s open to interpretation. You need to specify—and your customer must agree on—the size of the frame, how much load it must carry, and perhaps even what material and color it should be painted. If these requirements are not specified up front, and we deliver a green bike when the customer wanted red—well, we’re going to have an unhappy stakeholder. (And, yes, we’ve discussed this concept before here, too.)
The takeaway is that we must ensure our Quality Acceptance Requirements are rock solid and agreed upon before we build anything and get to a potentially unhappy handover with a key stakeholder.
But what makes up a “high-quality” quality requirement? I’m glad you asked.
The SMARTTT Framework for Quality Acceptance Criteria:
When creating a requirement for a product or result-type deliverable, we should strive to meet “SMARTTT” criteria. Every quality acceptance criterion for deliverables should have seven key characteristics baked into it:
S = Specific. Any requirement that you apply to an element of scope should be unambiguous. Stating that “software shall be robust” is not sufficient. The word “robust” is subject to interpretation. Your idea of robustness may differ significantly from mine. We need to be much more clear and specific when creating acceptance requirements.
M = Measurable. Every requirement should also be testable or verifiable. To state the obvious, if a requirement is not measurable, then there is no way of ensuring it was actually met. And this is more fodder for disgruntled stakeholders.
A = Achievable. A common problem with acceptance criteria is that it’s not possible to achieve within the project constraints. Or at all. You can specify that a car drives at a million miles an hour, but it’s not a reasonable requirement. Always ensure your requirements are achievable.
R = Relevant. You also must ensure your requirements are relevant and necessary. Engineers and scientists are often guilty of “gilding the lily” or gold-plating requirements. Just because you specify a device has a lifespan of ten years doesn’t mean it’s necessary. These types of requirements often add unnecessary expense and effort to achieve. Make sure your requirements are all truly needed, and not just “wish list” or “nice to have” elements.
T = Traceable. Another key characteristic of a proper quality acceptance criteria is that it stems from a higher requirement. Usually, there is some very high-level aim or set of goals (often contained in a Mission Statement) from which you can derive the high-level project, business, or science requirements. And from these, you can derive a suite of systems-level requirements. And from these, Sub-systems requirements will flow, and so on. Every requirement should ultimately arise from a high-level goal or purpose of the project.
T = Total. Every requirement should also be both complete and standalone, not requiring another requirement or specification to be complete. If you’re describing the required rotational speed of a device, all the information about that speed should be in a single specification.
T = Tiered. Finally, every requirement should be individually numbered for identification, tracking, and compliance purposes. Usually, this means a hierarchical numbering schema that is tied to the WBS numbering.
Service-Type Scope Acceptance Criteria:
For service-type Scope (e.g., Project Management, Systems Engineering, etc), you need to predetermine suitability or acceptability requirements tied to them. You can’t just say you’ll provide professional Project Management on the project. Instead, specify what level of rigor, formality, and standards you’ll adhere to when managing the project. You may think just a weekly check-in with the team is sufficient, but your customer may expect NASA-grade oversight and project controls. You must define exactly what the customer is going to get for their funding.
The Bottom Line:
Scope costs money, time, and effort. You can’t accurately plan or execute a project until you define the deliverables. And by extension, that means you must pre-define—and agree upon with your stakeholders—the quality criteria of that scope. What is acceptable for each element of scope? I.e., what level of quality must the scope be created and/or provided to? Exactly how good is good enough?