Project quality as opportunity

What’s your go-to swear word?

Here’s how I’d find out:

Imagine this: as you walk into your office tomorrow morning, you flick on the light switch. Lights go on - duh. You press the button on the coffee machine, and your daily dose of magic is on its way.

And then you turn your computer on.

Nothing.

That’s the moment I’d find out what your go-to swear word is.

You’ve just learned mine 👆. This newsletter is read in 81 (!!) countries, so I’d actually be curious. The variety will be wild.

Anyway…

Why do you swear when your computer doesn’t turn on?

It doesn’t do what it’s supposed to do, when you expect it to do so.

Low (perceived) quality.

It does not meet the requirements. Or does it?

Quality in projects often leads to friction, but it’s a huge opportunity to differentiate yourself as a project manager.

Let’s break it down together:

What is quality?

Let’s wind back the clock to the world after WW II. One of the main industrial thinkers of that era was Edwards Deming, who is often described as the father of quality management.

There are hundreds of definitions of quality, but they all boil down to Deming’s ideas: meet specification.

Is it really that simple?

This is where we hit an issue within project management. If “all you had to do” was to meet requirements, life would be relatively easy.

Here’s the thing…

Meeting requirements does not mean that the stakeholders are happy. And they are the ones that ultimately decide on project success.

Back to your computer. Maybe it was designed to have a 3-year lifespan?

If you’ve exceeded that and it broke, it met specification.

But it doesn’t make you a happy customer.

There’s a distinct difference between meeting spec and perceived quality.

And that’s where it becomes an opportunity for you as a project manager.

Work with me!

My firm Raundalen Consulting has capacity for two new clients. I specialize in strategy execution & project management for D2C scaleups.

Most companies have tons of great ideas and strategies, but they don’t know how to balance executing them with day-to-day firefighting. As a result, they hit a scaling plateau and leave money on the table.

Together we’ll refine your strategy, plan execution, and set up the support + accountability you need to turn your ideas into results and grow your business.

Make execution your unfair advantage and schedule a discovery call today!

Quality in projects is mostly quality assurance

As we just established, meeting spec is only part of the job. Let’s look at that in detail first, and then look at our stakeholders later.

Meeting specification comes down to quality assurance. How do you ensure & confirm that you did what you said you’d do?

There are three main tools you have for quality assurance, and they line up with three different phases of your project.

1. Before (planning)

2. During (process)

3. After(verification)

Before (planning)

If you’re trying to meet specifications, that means defining specs right is a crucial job. We’ve gone into each of these elements in the past weeks: translating a project purpose into scope and then building a timeline and a budget. See the whole archive here!

In Deming’s world, you’re home safe as long as you meet those requirements while staying within any additional boundaries set by the steering committee.

Things like regulatory & legal requirements, integrations, vendor restrictions, et cetera.

Without repeating what I’ve said about these topics in the past few weeks, one piece is crucial to remember: project management = managing expectations.

You can’t manage those if they are unclear.

So focus on that during your planning phase. Go beyond the specs, and make all implicit expectations explicit.

You can’t meet what you don’t know!

During (process)

A project is a one-off event by definition. But that doesn’t mean that you have to constantly reinvent the wheel.

Whether activities are repeated often or critical for the projects’ success, a good process is almost always worth the time investment.

You may feel that processes are restrictive.

“You can’t capture creativity in a flow chart”.

True.

But what we can capture in a process is what goes in, and what comes out. Processes don’t have to be restrictive, and some constraints can actually increase creativity - but that’s a whole different topic.

For now, recognize that your best chance to get what you expect is designing and documenting how you’ll do it, and then actually following that process.

After (verification)

Some software PMs are already screaming at their screen right now.

Please, give me 30 seconds to explain myself.

Yes, testing is done continuously.

But testing, verification, and reviews all serve the same goal. Whether it’s code, a weld, or someone’s blood pressure.

Your goal is to confirm that it meets specifications. That you got what you expected.

This is best done as soon as possible to keep the consequences of a potential error low.

In software development, we’ve come a long way in this. Pair programming, continuous testing, live AI code reviews - fantastic stuff, and a far cry from the traditional “We’ll give it a test run the night before launch”.

Virtually any other industry can learn from this, and that’s something I’d love to do a deep dive into one day. (If you’re a software PM and expert in the field of testing, please reach out to me!)

How and when the best way is for you to do this, depends on your context.

But what you need to remember is that just having the right spec and a good process does not guarantee the outcome.

No matter how well you trust your team…

You are responsible for the project's quality and its ultimate success.

That means that you must verify the quality in some way.

Quality as your secret weapon

Back to the stakeholders.

Because “just” ensuring that the specs are met makes you incredibly vulnerable to an error in the specification.

I see it as a balancing act.

You have the project requirements on one side, and your stakeholders on the other.

If stakeholders keep pushing for more, you can always point back to the agreed-upon spec.

But if you discover that meeting spec won’t drive the benefits & business value your project is supposed to deliver?

Then don’t stick your head into the sand.

Go back to your stakeholder matrix (see this stakeholder management deep dive) and identify a few key stakeholders that you can pull into your team.

Use their feedback to better yourself, and to ensure that what you deliver is fit for purpose.

Because in the end, you’re delivering to people and not to a checklist.

Putting it all together

Back to your computer once more.

Have you ever thanked it for turning on in the morning?

Of course not.

Quality is a baseline expectation. As long as it’s met, you don’t think about it.

But the moment it’s not met, you’ll learn a few new swear words.

And quality comes in two different flavors: meeting spec, and perceived quality.

Balancing these two is your opportunity, because very few projects are run that way.

Cheers,

Jasper

PS: 231 readers replied last week to tell me what they had for breakfast. If you were one of them, thank you SO much for your support! We still have a deliverability & spam issue, and my email provider is all over it.

If you want to help, a simple reply with your favorite vegetable would go a long way to signal to Google that this newsletter is legit. Thank you! 🙏