Next: Define "How Good?"
Establishing Quality Acceptance Criteria for the Scope
After capturing the "What’s" of our project in a Work Breakdown Structure, the next crucial step is defining the "How Good?" On every project, it is vitally important to define what is “good enough” for the delivered condition of each of the products, results, and/or services listed in the WBS. It’s one thing to say we’re going to create and deliver a bridge across a river; it’s another thing entirely to state (formally) how many lanes of traffic the bridge must have, what load capacity it must provide, the lifespan it must achieve, the building codes it must abide by, and even what color the structure must be painted when finished.
Every element of scope in the WBS must have pre-defined quality acceptance criteria that is agreed upon by both the Key Stakeholders and the Project. We cannot plan our acquisitions approaches, determine a schedule of activities, or even establish how large our teams need to be until we take this step. We certainly can’t estimate the costs of construction without these requirements established, either. And of course, we can’t even discuss how we plan to conclude the project successfully if we don’t first agree on what success is actually supposed to look like for both parties.
While defining requirements, test plans, and compliance criteria is technically the responsibility of a systems engineer, the ultimate buck always stops with us, the project managers. As such, we need to ensure all requirements are fully developed in the correct order and level of detail. Here are some thoughts on how to do this effectively:
First, don’t do it all at once (or alone). Progressively elaborating requirements iteratively with your stakeholders is preferred. Take a first pass through defining high-level requirements and key performance parameters for the most important elements of Scope. Begin and stay at the higher-levels of the WBS, fleshing out what matters and what doesn’t. Get buy-in from your customers and end users before adding more detail. Slow and steady wins the race.
Next, make sure you think about all categories of requirements. Each of us has our institutional biases built in, so it’s easy to focus too much on some categories at the expense of others. Engineers think in terms of functional requirements, for example, and scientists & customers focus on end-product performance. But there are many other categories to consider. Safety is obvious, but don’t overlook things like environmental, reliability, maintenance, etc. And then there’s all the political, societal, aesthetic, and other requirements to consider. Create a list of all the types of requirements to consider, and then ensure you’ve looked at each.
Finally, learn how to state a requirement. Stating that “software must be robust” is not sufficient; this is not an objectively measurable specification. Your institution/industry/situation may require specific formats, but the one I like is to ensure every requirement is S.M.A.R.T.T.T, meaning:
Specific. Every requirement you create is clear and unambiguous.
Measurable. Every requirement must be testable, with objective results.
Achievable. A requirement must always be possible within the project constraints of time and budget.
Relevant. A requirement needs to be actually needed, meaning suitable and germane for the project’s goals.
Traceable. Every requirement should flow from some high-level need or goal, all ultimately stemming back to the project mission.
Tiered. Every requirement should be numbered and live at the correct level in the overall hierarchy of requirements.
Total. Finally, every requirement should be complete, standalone, and completely capture the intended purpose.
Defining quality requirements is a critical—but often under-looked—step in project management. Taking the time to craft S.M.A.R.T.T.T. requirements through iterative elaboration and consideration of all categories, project managers (with the help of their systems engineers) can set clear, achievable standards for success. This process not only aligns stakeholder expectations but also provides a solid foundation for planning, resource allocation, and ultimately, the successful delivery of the project.