15 Jul 2016

That’s not what we want! Gaining Quality Requirements in PRINCE2

Posted by Paul Atkin

That’s not what we want!  Gaining Quality Requirements in PRINCE2

This is a statement that gets made far too often in a project. How often do we fail to define what the customer actually wants? Or, in some cases, don’t even really ask them! Tire_Swing without PRINCE2

So how does PRINCE2 deal with this?  Well, one of the first things we do in a PRINCE2 project is to ask the customer what their quality expectations for the project are.  In PRINCE2, it is the Senior User’s responsibility to provide this information.  These would then be documented in the Project’s Product Description document.

If your project is to build your dream house. Some quality expectations might be:

“I want a big house”, “I want a nice view” or “It must meet current building regulations for safety” etc.

While that sets the scene, if it is all the information we have about quality we will have problems when it comes to creating the products.  In this case, what I consider a “big” house may not be what the customer actually wants.   But it is a good start and, to be fair, you can’t expect a customer to tell you “I want my new property to meet Planning Regulation XYZ Version 3.5”   So the next step is to take the Customer’s Quality Expectations and make them into measurable acceptance criteria

PRINCE2’s Acceptance Criteria

Acceptance Criteria are a list of measurable criteria that needs to be met to make the project acceptable to the customer.  They are documented in the Project Product Description and should be prioritized

If the customer wants a big house. How many bedrooms do they want, how many bathrooms etc?

During the Closing a Project process the Acceptance Criteria are checked and successful completion is the PRINCE2 answer to “are we done yet?”

So when do we ask these questions?

Well the Project Manager captures the Customers Quality Expectations from the Senior Users during the pre-project Starting up a Project process. During the Initiation Stage as more is known about the project these will be refined.

Of course, once the Customer’s Quality Expectation and Quality Criteria have been agreed we shouldn’t then just forget about them.  At the end of every stage we should go back to the customer and check that their expectations are the same and that the Acceptance Criteria are still relevant. Otherwise we will get to the end of the project, hand the product over and the customer could still say “that’s not what we want”.

Requests to change the Customer Quality Expectations or Acceptance Criteria must go through change control to examine the impact of the changes requested, the impact on the Business Case, timescales, costs, scope, quality and the risk profile of the project.  We take all this into account before making a decision as what to do next.  This allows us to keep control of the project (PRojects IN Controlled Environments) but at the same time allowing us to meet the quality requirements of the customer.

Comments are closed.