A blog that looks at all aspects of project and program finances from budgets, estimating and accounting to getting a pay rise and managing contracts.
Written by Elizabeth Harrin from GirlsGuideToPM.com.
How do you define the right level of quality on your project? Your project sponsor probably has expectations you need to meet. Your team has a level to which they can deliver. You have to find a way to balance the competing needs and hit a quality level that suits as many people as you can.
At least, that’s a good approach if you want to avoid too many grumpy faces round the table at your project lessons learned meeting.
This infographic, inspired by a fantastic short little book on project management called Project-Driven Creation by Jo Bos, Ernst Harting and Marlet Hesslelink, sets out the three levels of project quality that you can reach for your deliverables.
Thank you! Elegant simplicity. This will be very helpful to me in the future as we design business cases. Helping people understand these three levels and their associated costs BEFORE the project begins will help shape benefits management and expectations.
1- I would be cautious about using Aspirational Quality because as you said it comes with a cost and this, if not required or approved, can be considered Gold Plating.
2- I’ve seen instances where the standards of Acceptable Quality are higher than Appropriate Quality. Some clients ask for certain quality that goes above and beyond the Norm and that is their right as long as it is pre-defined I the contract and paid for.
With no disrespect intended to any person, this attempt to fractionalize quality with modifying language such as “Acceptable, Appropriate,” and “Aspirational” is taking the subject and field of quality back to pre-1983 levels of mis-understanding.
We came to understand that:
Quality is Conformance to Requirments.
Period.
In the non-expert, non-professional world, one may define and describe quality any way they choose.
However, I will wait to see what others think before opinionating further.
From a project manager's perspective, I agree with Rami and William, there is only one quality, it is conformance to requirements.
Aspirational quality might be required though from marketing and sales to the project, e.g. to delight customers and differentiate from competition. If so, it should be stated as an explicit requirement. See Apple, Porsche as examples. If initiated by the project delivery itself, it is indeed gold plating, waste of resources and damaging.
If there is a difference between acceptable and appropriate quality, it is due to the lack of managing expectations, which might be OK in the beginning of a project but must be closed towards the end or you risk non-acceptance or at least dissatisfaction.
And requirements are subject to change, especially in adaptive environments. Even in Scrum projects, the Definition of Done would often contain quality requirements and they would not change as much as feature requirements.
A product can be technically perfect, be made with the most suitable materials and have an optimized production process. However, not being accepted by the clients to whom it is addressed; not succeed in the market.
Fractioning extends many criteria to failure in delivery, quality there is only one and must be successful, not partial or speculative.
Said this with all respect.
William, in reality things are more in flux, a PM will start working before all requirements are fixed, expectations will develop over time as customers understand better what they asked for and the PM has to sense and respond to all of this. If it goes quick, agility is appropriate.
And - not all requirements will be granted. Requirements are what the customer wants. The scope is what a PM promises to give. Might be quite different. Expectations management is a key skill.
You are correcttly summarizing my view. Life is not perfect nor are projects. A project has a beginning and an end and produces a unique output. Most projects are not 100% predictable, some even have to use trials before a customers discovers what he needs. General von Moltke said no plan survives 1st contact with the enemy. Even PMBoK states that PM process groups are iterative.
But I agree the PM needs to know how to manage expectations, elicit requirements including those about quality, tell the customer what he will deliver, under the constraints of schedule and budget, get the right resources, execute and monitor just this and start again, in cycles. If the cycles turn fast, agile is more appropriate, if slower change management is suitable.
Resilience and adaptability are capabilities of humans, that AI does not show yet.
Most projects are not 100% predictable, some even have to use trials before a customer discovers what he needs.
If I may, for those clients who you intend to serve that do not yet have a clear view of what she/he wants or needs, I suggest using the Deming Plan Do Study Act model for the trials to finally arrive at the clients desired want or need.
https://www.process.st/deming-cycle/
Once that study is complete, one may then reliably form a project, or as may be warranted, a program.
"We cling to our own point of view, as though everything depended on it. Yet our opinions have no permanence; like autumn and winter, they gradually pass away."
