Quality Risk: When the Diamond Isn't a Diamond

The wedding survived the schedule.

The bridal march played. The church doors opened. Dad cried. People were actually sitting inside. The groom was standing exactly where the groom was supposed to be.

Success!

Well…not so fast.

As our bride reaches the altar, she happens to glance down at her beautiful engagement ring. The light catches it just right.

Except it doesn't sparkle quite right.

Later, someone who knows a little about jewelry takes a closer look.

The diamond is fake.

Oh, and while we are delivering good news, someone notices tiny threads hanging from the wedding dress. Then another. A few sequins are missing. The stitching around the waist is beginning to loosen, and the hem looks as though someone finished it at 2:00 a.m. while watching Netflix.

But technically?

The ring was delivered.

The dress was delivered.

The wedding started on time.

Welcome to quality risk.

Done Does Not Mean Done Well

Projects love the word complete.

Development complete. Testing complete. Installation complete. Training complete. Construction complete.

Fantastic.

But there is an enormous difference between “We completed it” and “We completed it correctly.”

Our bride ordered a diamond ring. She received a ring.

Check.

She ordered a wedding dress. She received a wedding dress.

Check.

If our project dashboard measures only whether something was delivered, everything looks wonderful. The boxes are checked. The milestone is green. Someone updates the slide for the executive steering committee.

Meanwhile, the bride is standing there wearing a dress that may not survive the first dance and staring at a cubic zirconia she paid diamond prices for.

Quality risk appears when the project delivers something that technically satisfies a milestone but does not satisfy the standard, specification, performance, or expectation behind that milestone.

What Did We Actually Ask For?

Quality problems often begin much earlier than the inspection.

They begin with requirements.

What exactly did we specify?

If the contract simply says “diamond engagement ring,” that leaves quite a bit of room for interpretation. What size? What grade? What clarity? Natural or lab-grown? What certification is required?

The same applies to the dress. What fabric? What stitching? What embellishments? What workmanship standards? What alterations are included? What constitutes an acceptable defect?

Projects suffer from the same problem.

We tell a vendor we want a “user-friendly system,” “high-quality materials,” “adequate testing,” “professional training,” or a “fully functioning solution.”

Those phrases sound lovely.

They are also incredibly difficult to inspect, test, measure, or enforce.

If quality matters, define what quality means before the work begins.

Otherwise, when something goes wrong, one side says, “This isn't what we expected,” while the other says, “But this is what you ordered.”

And both may be right.

Inspection Is Not an Insult

Imagine spending thousands on a wedding dress and never trying it on until the morning of the wedding.

Ridiculous, right?

Yet projects sometimes do exactly that.

Work progresses for months before anyone meaningfully reviews the deliverable. Testing is pushed toward the end. Inspections become ceremonial. Quality reviews are shortened because the project is behind schedule.

And there it is again.

Schedule pressure meets quality risk.

The project starts running late, so something has to give. Testing gets compressed. Reviews are shortened. Defects are accepted “temporarily.” Documentation will be completed later.

Suddenly the project is back on schedule.

Wonderful.

Except we have not recovered time.

We borrowed it from quality.

Who Is Checking the Work?

The person performing the work should absolutely have responsibility for quality.

But should they be the only person deciding whether the work is acceptable?

Probably not.

If the jeweler who sold the ring is also the only person certifying that the diamond is genuine, we have created a rather convenient quality-control process.

Projects need appropriate review, inspection, testing, verification, and acceptance procedures. Depending on the project, that may involve project management, technical specialists, quality assurance personnel, independent inspectors, users, internal audit, or third-party experts.

The goal is not to create layers of bureaucracy.

The goal is to make sure somebody other than the person saying “Trust me, it's fine” has actually looked.

The Dangerous Phrase: “We'll Fix It Later”

Small defects have an interesting habit.

They rarely remain small.

A loose thread becomes a seam coming apart. A missing sequin becomes twenty missing sequins. A minor software defect becomes a system outage. Poorly installed equipment becomes a maintenance problem. Incomplete documentation becomes an operational nightmare six months after the project team has moved on.

Yet projects routinely accept deficiencies because they seem minor.

“We'll put it on the punch list.”

“We can correct it after go-live.”

“It doesn't affect functionality.”

“We don't want to delay the project over something this small.”

Sometimes that is a perfectly reasonable business decision.

But it should be a decision, not a habit.

Management should understand what defects are being accepted, why they are being accepted, who owns the correction, when the correction will occur, and what happens if it doesn't.

Because “we'll fix it later” has an uncomfortable cousin.

“Whatever happened with that?”

Quality Has a Price, But So Does Poor Quality

Quality controls cost money.

Testing costs money. Inspections cost money. Independent reviews cost money. Better materials cost money.

That can make quality activities tempting targets when budgets tighten.

But poor quality carries its own price tag.

Rework costs money. Repairs cost money. Delayed operations cost money. Warranty claims cost money. Customer complaints cost money. System failures cost money. Reputational damage costs money.

And sometimes the organization pays twice: once for the work that was done incorrectly and again to have it done properly.

Our bride did not save money by buying a fake diamond at diamond prices.

She simply paid too much for poor quality.

Questions Worth Asking

When evaluating project quality, ask:

• Have quality requirements been clearly defined and documented?

• Are specifications measurable, or are we relying on vague words such as “adequate,” “appropriate,” and “high quality”?

• Who is responsible for inspecting, testing, and approving the work?

• Is the person verifying quality sufficiently independent from the person performing the work?

• Are inspections and testing occurring throughout the project or primarily at the end?

• Have testing or inspection activities been reduced because of schedule or budget pressure?

• What defects have been identified, and how are they being tracked?

• Who has authority to accept a defect or deviation?

• Are vendors correcting defective work at their expense when contractually required?

• Are recurring defects telling us something bigger about the vendor, process, materials, or oversight?

And perhaps the most important question:

Are we measuring whether the work is finished, or whether the work is good?

Those are not the same thing.

The Point

Project success is not simply delivering something on time and on budget.

It is delivering something that actually works, meets requirements, performs as intended, and provides the value the organization expected when it approved the project in the first place.  As an author if my editor finds one or two typos in a 200 page manuscript, she is OK with that.  If my editor finds 20,000 instead, well we are back to the drawing board (or word processor as the came may be).

Quality should not be something we inspect into a project at the very end. It should be designed, defined, monitored, tested, and verified throughout the project lifecycle.

Because our bride made it to the church on time.

The flowers arrived.

The photographer showed up.

The groom remembered where he was supposed to stand.

By traditional project measures, we might even call the wedding a success.

Except her diamond is fake, her sequins are falling onto the dance floor, and one particularly important seam is beginning to make decisions of its own.

Sometimes a project can meet every deadline and still deliver something nobody should be proud of.