22.02.2021Project Management: PRINCE2 Quality Theme
Quality is something that many of us spend a lot of time talking about, and everyone agrees “Quality” is important, but it’s something that few truly understand. Many organisations buy in to Quality Management Systems, but articulating Quality as a definition is often a difficult task.
The Purpose of the Quality Theme of PRINCE2 is to define and implement the means by which the project will verify that products are fit for purpose - what we will be happy to accept at the end of the project - the What.
We’ve established the definition of Quality is a difficult thing to pin down. PRINCE2 defines quality as “the degree to which a set of inherent characteristics of a product, service, process, person, organisation, system or resource fulfils its requirements”. PRINCE2 mandates that we define our customers quality expectations and the acceptance criteria that govern success or failure. It’s a simple notion but can be hard to get right!
Often when a customer is asked outright, 'what do you expect from this project', the first things include:
- Costs - keep these down.
- Time - get it done ASAP.
- Outcomes - we want a really effective [a], [b], [c].
- Benefits - we want a better [this].
- Risk - we can’t tolerate [that].
ANYTHING but Quality! So, given that Quality (according to PRINCE2), ensures that you get what you ask for, how do we define what it means for our Project? Systems Engineering can help us with this.
Focus on Products
By capturing and formalising our Customer's needs, then eliciting, refining, and validating Quality expectations, we start to see how PRINCE2 themes (and Systems Engineering practices) work together to deliver a successful project. By taking one of the key Principles, “Focus on Products”, and applying it to Quality, we work with Customers to gain an explicit understanding of the products (which can include any input or output, however tangible or intangible) to be produced. This is coupled with the criteria against which they will be individually approved.
Products can refer to a huge variety of things, with varying levels of Quality. A “Focus on Products” approach allows us to look at each “product” within the project and ask, “what does it mean for this [product] to be of a good or bad Quality”. In some instances, this might be a relatively simple answer, for instance if your “product” is a progress report that you intend to deliver, what would your Customer require for them to be satisfied with the Quality of that document? Do they want it in a particular format? Do they need for the report to be heavily detailed or a simple summary? These are all viable questions to ask because Quality can be a very personal notion.
Elicit, Refine, Validate, Verify (and Repeat)!
Systems engineering practices make very specific distinctions between needs and (formal) requirements. There’s a lesson to be learned from formal requirements which apply directly to the PRINCE2 Quality Theme, but first we need to understand what the major differences are. For our example, let’s assume we’ve been asked to deliver a Grand Prix winning Formula 1 car; and starting with what we define as a need or a requirement:
Needs – these are generalised statements, often informal necessities, or desirables within a specific project context. This could be taken from people, documents, emails, literally any context-defining thing. Let’s go with a statement taken from a meeting with the formula team bosses e.g. “we just need a car that is lighter and faster than the competition.”
If we focussed on delivering a project that satisfied this need where would we spend our focuses, probably on:
- Making the car lighter
- Making the car faster
Where does the aspect of quality fit into this? If we deliver a project that we believe satisfies the pit boss’s needs, how do we know she’ll be satisfied? The short answer is we don’t, and in reality, we’ve no idea what “Quality” might mean to her in the project-context; so let’s look at what a requirement might do to help us:
Requirements – these are purposefully formulated statements so that whoever is delivering the project can assure themselves that they are delivering products to a measurable specification. Requirements are usually linked to both a need and either a stakeholder or some other context-defining entity (e.g. an email or a documented regulatory standard). An example would be “Under dry-track race conditions, the Car shall reach a steady velocity of 44.75 meters per second from a stationary state in less than 4 seconds”.
What should be obvious is the amount of detail in this requirement is much greater than what was in the need. To get this level of detail we must elicit the requirement, that means to extract a greater level of detail from the source of the need or the context-defining entity to better define what “fast” might mean. In this example, the competition team may have recorded their fastest 0-100 mph, maybe this is a good way for us to start to define what ‘faster than the competition’ might mean, although we should check (or validate) our understanding with the pit boss before getting too far down the line!
Quality also arises when we start to unravel the specific context for the project; a Formula 1 car does not just race in the dry, it is also expected to perform in wet weather conditions. Did our pit boss just want to car to be faster than the competition in the wet, or in the dry? Or both? Well, it’s a good job we did our homework understanding the project context, because our requirement specifies very specific and testable conditions which we can use to prove that our project has resulted in the car being faster than the competition.
So how did the aspect of quality fit into this compared to the need? Well, we:
- Took the time to elicit details relating to the need, asking questions of the context, rationale, environment, and logic behind the statement in order to better define our understanding
- Refined the need statement making a point to specify that “being fast” is applicable to a Formula 1 in a race-day configuration, after all it is no use being the fastest car in the starting position, but only when it doesn’t have a driver sat in the seat! This refinement process is about being specific with our language and taking out as much ambiguity as is possible!
- Validated our requirement by asking the pit boss responsible for the need to check that we have correctly interpreted those needs and that she is satisfied with our requirement specification. This allows us early on to ensure we are using the right quality testing methods to satisfy the project brief.
- Formulated a requirement which can be verified, therefore defining quality expectations. This is perhaps one of the most important aspects of defining a requirement – What better way is there to assess “the degree to which a set of inherent project characteristics fulfil the project requirements” than by making the project requirements easy to test.
Let that soak in for a moment. Even before we’ve got stuck into nuts and bolts of the project, we’re taking needs and turning them into requirements which clearly define the functional characteristics and specific conditions in which the project’s products (in this case a Formula 1 car) shall be tested. If the product performs as per the necessary functional characteristics and within the conditions we’ve set out in each requirement, then we can be 100% assured that we’ve delivered a high-quality product (on the proviso that requirements were validated throughout the process).
Top Tip: This can sound either ridiculously obvious, or incredibly complicated. If you’re lucky enough to have dedicated Requirements Managers or Systems Engineers in your project team, ask if they can help you with these practices.
Don’t Get Complacent: Validation is Iterative!
You might do everything right and by the book, but both needs and requirements have a habit of changing. As we all know (and have to deal with), sometimes a changing environment forces us to re-think certain aspects of the project, and consequently getting things revised ASAP may take priority over doing it RIGHT. Should the project context (or other external forces) change the landscape, its worth re-validating requirements with your stakeholders, asking questions like “are you sure this is still what is warranted” and “am I right in thinking this is what you need”; you’d be surprised how many times these sorts of questions turn into major quality wins, capturing small changes well in advance of them turning into major issues.
Validation and refinement are constant iterative processes which save money, time and effort; these activities are just some of the daily duties of systems engineers and requirement managers. Keep these people happy, they will make your life as a project manager a lot easier.
Get in touch
To learn more about how combining PRINCE2 Project Management and Systems Engineering can help your Project, get in touch with our expert team of Project Managers and Engineering Experts.
