The work order looked ready. A planner's name in the field. A labor estimate. A short list of parts. A scheduled date, this coming Tuesday. On the weekly review, it slid by without a second glance. Planned. Good to go.

Tuesday morning, the crew shows up to execute, and the job is dead before the first wrench turns. The equipment can't be isolated during the window they were given, because the unit next door is mid-startup and the shared system has to stay live. Nobody caught it in planning. Nobody caught it in scheduling. So four people stand around while a supervisor scrambles to find them something else to do, and a "planned" job goes back into the pile.

Here's the thing. That job wasn't badly planned. It was barely planned. It carried the label without carrying the substance. And that gap, between planned as a status and planned as a standard, quietly wrecks more schedules than any emergency ever will.

In most CMMS systems, "planned" is just a state a work order sits in. Somebody opened it, added an estimate and a couple of parts, moved it along, and the software dutifully flipped it to planned. That's it. The label says the record passed through a step. It says nothing about whether the work will actually succeed in the field.

We treat that label as a promise anyway. Planned goes onto the schedule. Planned counts toward your planned-work percentage. Planned gets committed to a crew. And all the while, "planned" might mean a genuinely prepared execution package, or it might mean a title, an hour estimate, and a hope. The word can't tell you which, and that's exactly the problem.

When a nominally planned job blows up in the field, the cause is almost always one of a familiar set of gaps:

Any one of these can stall a job. Stack two or three, which is common, and the crew spends the morning doing discovery work that should have happened weeks earlier, at a desk, for a fraction of the cost.

The fix isn't more paperwork. It's a different mental model of what a job plan is for.

A weak job plan documents an intention: here's roughly what we want done, and here's a guess at what it takes. A strong job plan designs an execution: here's exactly how this work will succeed in the field, step by step, with the scope, sequence, resources, access, safety controls, and interfaces resolved in advance. The first is a note to a scheduler. The second is a package a crew can pick up and run without reinventing it.

Good planning guidance lands in the same place. A work plan earns its keep when it spells out the specific scope, the task sequence, the labor and parts, the special tools, the safety and permit needs, the technical references, and the coordination required, all before the job gets scheduled. Not after. Not in the field. Before. That's the difference between a record that says planned and a package that is.

Here's the humbling part for anyone who plans work. You cannot judge the quality of a job plan from behind a desk. The only honest test is what happens when a crew tries to execute it.

Did they have to hunt for anything? Discover anything? Wait on anything that should have been arranged? Improvise a method because the steps weren't there? Every one of those is a defect in the plan, and every one of them is invisible until the work hits the field. That's why the best planning organizations treat field feedback as gold. The crew that just ran the job knows precisely where the plan was thin, and if you don't capture that, you'll write the same weak plan again next time. A plan isn't proven when it's approved. It's proven when someone executes it cleanly.

None of this means every work order deserves a thick execution package. That's its own kind of waste. The trick is matching planning depth to the work.

Simple, low-risk, familiar jobs need light planning: a clear scope, the right parts, and go. Standard corrective work needs a real package: scope, steps, materials, labor, and the access and safety basics resolved. Complex jobs, tight access, multiple crafts, heavy enabling work, need genuine execution design, with sequencing and interfaces worked out in advance. And event-critical work, the high-consequence or outage-path jobs, deserves the deepest rigor you've got, because a surprise there doesn't just cost a morning, it moves the whole event. Planning maturity isn't planning everything to death. It's spending your planning effort where the complexity and the risk actually are.

A job is not planned because someone entered labor hours and moved the work order to the next state. It's planned when the people doing it can see how it will succeed: what the work is, how it goes, what it needs, and what has to be true before they start.

The label on the record is cheap. The readiness behind it is what determines whether Tuesday's crew executes the job or stands around waiting for the next one. Treat "planned" as a quality standard instead of a status flag, and a whole category of field surprises stops being surprising.

Next in the series, we follow the single most common reason a well-planned job still can't start: the equipment isn't available. It's time to talk about waiting for operations, and why access is a shared responsibility, not a maintenance problem.