Project Management

3 Levels of Project Quality [Infographic]

From the The Money Files Blog
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

About this Blog


Recent Posts

5 More Cost Types to Include in Your Business Case

7 Types of cost for your business case

New Year Goals: 2023 Edition

4 Different Types of Estimating

How to show your project meets strategic objectives

Categories: quality

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.

Which one do you hit most often?

Read more about this topic in the article here.

Posted on: January 22, 2019 09:00 AM | Permalink

Comments (20)

Please login or join to subscribe to this item

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.

Good Points Elizabeth but I have two comments:

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.

Excellent post.
Thanks a lot!!

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.


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.

Good post. Thanks for sharing

Good Post . Thanks Harrin for sharing it.

Like the naming, especially the "Aspirational". Think excellent project should deliver that quality.

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.

I beg to differ with you Vincent but certainly agree with Thomas.

Thanks, Good Post

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.

Ruben, if I may extend my earlier response to include your excellent reminder:

a. Quality is Conformance to Requirements.

b. Requirements allow you to define what to do, and how to do it.

c. Clients however, frequently have more expectations than requirements.

d. A PM can not begin assigning project tasks until after they have helped their client translate their
expectations into requirements.

e. Once this has been verified, and only then can the project work be initiated with confidence that it will be done right the first time, every time.

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.

Thomas, allow me then to summarize your feedback:

a. PMs start working before all requirements are fixed.

b. Customers start not knowing what their expectations for the project are.

c. The PM is supposed to sense what that is, and respond to all of that.

d. Once known, not all requirements will be granted.

Thomas, if the above generally is faithful to your thoughts, then the work never was, nor is NOT yet a "Project."

It is a subject for perhaps a "Study" out of which a project or projects might arise.
Quality is conformance to requirements.

The requirements for a project are scope, schedule and budget.

Once a client's expectations are unbundled and translated into scope, schedule and budget,
then and only then does one have a definable project.

Hi William, appreciate your view and response.

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.

Once that study is complete, one may then reliably form a project, or as may be warranted, a program.

I agree with Thomas and have found this discussion amongst all members very handy. Thanks!

Good Information

Please Login/Register to leave a comment.


"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."

- ChuangTzu