Prince2 is a registered trademark of the Office of Government Commerce.
Prince2 has many excellent ideas for project management, but I think its approach to quality is at best weak and at worst entirely inappropriate. My first gripe is that Prince2 redefines what the word quality usually means. My dictionary defines it as a “degree or standard of excellence, especially a high standard.” If I’ve bought myself a quality car, I’ve probably purchased something like a Mercedes or Rolls Royce. Prince2’s definition is something that is “fit for purpose” of satisfying stated needs. So for example, according to Prince my Landrover is a quality product. It’s not luxurious but, as a keen skier, I can use it to haul equipment to the Alps each year. This re-definition of the word quality often confuses people, before they even look at the detail.
At the beginning of a Prince2 project you agree with the customer a set of measurable attributes about the products you will build. These are called Acceptance Criteria. Later, when you deliver the products, the client will only sign them off if they conform to these criteria. This assumes that the client knows what they want. They often don’t. When Henry Ford was designing the Model T car he was asked why he didn’t consult with potential users. He replied,” If I had asked people what they wanted they would have said faster horses!”
Users’ not knowing what they want is often a problem in groundbreaking projects. People in the early 1900’s knew they wanted to get places faster, but their idea on how to achieve this was limited by their own experience. Another example is the project to create the iPhone. Steve Jobs did not consult with potential users. Instead he went through many iterations of building prototypes, playing with them, deciding what worked and what didn’t, until he ended up with the final design.
So this idea in Prince2’s Quality Theme, that you can simply ask a group of potential users at the outset, to specify what products they want, doesn’t always work. Prince2 defines a project as a piece of work that is unique. The more unique and groundbreaking it is, the more difficult it becomes to define exactly what is required at the end. Project work is a creative process. Sometimes it takes trial and error and a certain amount of vision to create something the end users will eventually be satisfied with.
As I said at the outset, Prince2 has many useful ideas. But the Quality Theme should be used with caution. In groundbreaking projects, they can hinder the creation of products the client is going to be satisfied with.
What do you think – always interested in hearing comments on constructive criticism of Prince2?
Trackback URL for this post: http://www.orgtopia.com/2009/12/04/why-prince2s-quality-process-is-flawed/trackback/
{ 3 comments… read them below or add one }
David,
The comment by Henry Ford about why he didn’t consult with users completely missed the point. Instead of asking what users wanted he should have been asking “What problems do you have?” to which they would probably have replied “It takes too long to get from A to B”. By letting users choose too much of the solution by-passes the analysts specialist knowledge, and also negates any intuitive ideas the analyst may have.
Therefore I believe that the acceptance criteria should be related to resolving the problem, not necessarily fitting in with a set of criteria that may limit the solution.
David,
the point you make about quality and it’s definition in relation to projects needs a little bit more elaboration.
If we are talking about a new product like iPhone or Ford model T then yes you are right. But if the project is about changing an existing business or product then customer is the one who describes and puts the quality gates or acceptance criteria. He, by deciding to move on with the project knows what are the requirements and the expectations of the change.
Hi Chris & Adamantious,
Thanks for taking the time to leave some comments. I think you both make good points.
With Chris’s point – I agree. Getting away from defining a solution is the key to getting requirements. I think this gets more difficult in ground-breaking projects as we use old ideas and ways of doing things as a reference to asking for what we want. E.g. if I’d never heard of an internal combustion engine I would be more focused on what horses can do for me!
With Adamantious’s point – I sort of agree! I think the problem can be assuming that the project is not of a ground breaking nature and setting specific requirements in terms of quality gates or acceptance criteria. But then this constrains the direction to some extent – what happens if a very innovative solution comes along that doesn’t fit the quality gate?
I think both your comments have inspired me to look at this subject in a deeper way – I’ll write another blog post soon about requirements capture and will look forward to more feedback from you guys on it
Kind regards
David