A downstream work package was progressed based on reported completion of a critical predecessor activity without sufficiently defined acceptance criteria or objective verification. The resulting dependency failure caused rework and demonstrated the need for stronger hold points at trade interfaces.
Or, what actually happened was:
Back in the early days of my urgent property maintenance coordination role, I made a real blunder of a work order.
I was within my first month of managing urgent work orders. I had around 40 running at the same time, a ridiculous number of little procedures still to learn, and nowhere near enough time to stop and deeply understand every technical detail coming across my desk.
Then this work order came in:
The shower is leaking through the base of the shower tiles.
Okay. Send the plumber.
The plumber attended, tested the shower, and reported that they needed to replace the breech piece behind the tiles.
Okay.
I didn’t actually know what a breech piece was, but I knew what needed to happen next: get the additional work approved.
Approval received.
Sent it to the plumber.
The next day I got an email back with photos:
Done.
Plumbing complete. Send the tiler to repair the wall.
The tiler went to the site and had been working for quite a while. He was about halfway finished and found something wasn’t quite right.
Then my phone rang.
“Shanti, it’s still leaking. You need to send the plumber back.”
Oh, no! “Can you just do what you can do?”
“No. You really need to send the plumber back.”
Right. Okay.
The tiler sent me videos showing the leak. I sent those back to the plumber and arranged another attendance.
The plumber went back to site.
Their report came back:
We need to replace the breech piece.
Wait.
WHAT?
I’d already had the breech piece approved.
And that was the moment I realised something slightly important:
I had absolutely no idea what a breech piece was.
So I Googled it.
Ohhhhh! That’s a breech piece!
A beautiful, shiny copper plumbing fitting behind the wall, connecting the hot and cold water supplies to the taps.
And now that I knew what I was actually looking for, I went back through the photos attached to the original “done” email.
Sure enough:
No new breech piece.
It hadn’t been replaced.
The plumber had reported the work as complete.
I had accepted that report as verification.
And because I didn’t understand the specific subject matter well enough to know what evidence I should have been looking for, I’d sent the next trade.
That bit was mine.
The plumber said it was done.
I didn’t understand the work well enough to know what I needed to see to prove it was done.
So I sent the tiler.
The wall was still leaking.
And now we had another plumber attendance, another tiler attendance, rework, delays, and additional cost.
It was an expensive lesson relative to the responsibility I had at the time.
But I have never made that mistake again.
I don’t need to know how to replace a breech piece#
This is the important distinction.
The lesson wasn’t:
Project coordinators should become plumbers.
Absolutely not.
I work with specialists because they know things I don’t.
What changed was my understanding of how much technical knowledge I need in order to coordinate specialist work effectively.
I don’t need to know how to replace a breech piece.
But if replacing one is a critical predecessor to the next stage of my work, I need to understand:
What is it?
What outcome are we expecting?
What evidence should exist when it’s finished?
And what needs to be true before I send the next person?
That work order permanently changed one of my habits.
If a trade gives me a term I don’t understand, I look it up.
If I still don’t understand it, I ask.
And when the work comes back as completed, I don’t just look for the word “done.”
I look for the evidence that the thing we approved is the thing that actually happened.
Because reported completion and verified completion are not the same thing.
That’s the bit I learned from a leaking shower, an increasingly exasperated tiler and one very educational Google search.
Before progressing to the next stage, make sure you understand the prerequisite well enough to verify that it has actually been completed.
Or, to translate the whole story back into project-management language:
Effective dependency management requires sufficiently defined acceptance criteria to verify predecessor completion before downstream activities are released.
Which is accurate.
But the version permanently burned into my brain is much simpler:
You can’t verify what you don’t understand.
And I will never forget what a breech piece looks like.
Originally published on LinkedIn.