Job Plans, Kitting, and the Anatomy of a Work Order That's Ready to Execute
Here is the same failure, written two ways.
Version one: "Pump 3 making noise. Check it out." That's the whole work order. The tech reads it, walks to the pump, listens, guesses at the cause, walks back for tools, walks to the storeroom for a part that isn't there, calls the supplier, waits, and somewhere in the back half of the shift, fixes it.
Version two: a nine-element planned package. Defined scope, step-by-step procedure, the exact bearing and seal staged in a kit by the pump, a two-tech / three-hour estimate, the torque spec attached, lockout points listed. The tech reads it, walks to the staged kit, and starts turning wrenches.
Same failure. Two completely different days. The difference is the planned work order — a distinct artifact from the reactive ticket, and the thing that actually moves wrench time.
Job plan vs. work order: the distinction that lets you scale
These two terms get used interchangeably, and keeping them separate is what makes planning compound.
A job plan is the reusable recipe: how you replace the bearing on this class of pump, written once, refined over time. A work order is a single instance — replace the bearing on Pump 3, this Thursday. The work order is the meal; the job plan is the recipe you cook from.
Why it matters: you plan a job once and execute it many times. The first time you write the bearing-replacement plan, it's real effort. Every time after, you pull it off the shelf, attach it to a work order, and you're done in minutes. A team with a growing library of good job plans gets faster every month. A team that re-invents each job from scratch never does.
The anatomy of a planned work order
A work order that's truly ready to execute carries these elements. Each one removes a reason the tech would otherwise stop.
Clear scope statement and problem definition
What's being done and what "done" looks like — in specific terms, not "check it out." Scope ambiguity is where jobs balloon or get redone.
Step-by-step task instructions
The procedure, in order. Not a novel — enough that a competent tech who hasn't done this exact job can execute it without guessing or hunting for tribal knowledge.
Crafts, number of techs, and time estimate
Who's needed (mechanical, electrical), how many, and how long. This is what makes the job schedulable — you can't build a real schedule out of jobs with unknown duration.
Parts and materials list — with bin and stock locations
Not just "needs a bearing." The exact part number, quantity, and where it lives. The location detail is what makes kitting possible and what keeps the tech out of the storeroom.
Special tools, permits, and safety requirements
Anything beyond a standard toolbox: the puller, the crane, the hot-work permit. Staged or arranged in advance, not discovered mid-job.
Reference docs: prints, manuals, torque specs
The drawing, the O&M excerpt, the torque table — attached, not "go find it." A torque spec the tech has to look up is a torque spec the tech will skip.
Lockout, permitting, and isolation requirements
The specific LOTO points, isolation steps, and any permits required to make the job safe and legal. This belongs in the plan, every time, because rushed reactive work is exactly where isolation gets shortcut.
Kitting: the highest-leverage thirty minutes in maintenance
Notice that "parts on the shelf" is not the same as "parts at the job." Kitting closes that gap: the planner pulls the parts, stages them in a kit, and places them where the work happens before the tech arrives.
The wrench-time math is stark. Studies of maintenance work consistently find that technicians spend a large share of their day not on tools but on travel, waiting, and looking for parts and information. Direct wrench time on reactive work often sits around 25–35%; well-planned, kitted work can roughly double it. The thirty minutes a planner spends kitting a job saves the tech far more than thirty minutes of walking — and does it for every tech on every recurrence.
A worked example: the bearing plan, two ways
To see why the package matters, walk one job through both states.
Reactive ticket: "Pump 3 making noise, check it out." The tech arrives, diagnoses a failing bearing, and now the job stops being maintenance and starts being logistics. Find the part number on a faded nameplate. Walk to stores. Bin's empty. Check the second location. Call the supplier. Wait for a callback. Locate the bearing puller, which is checked out to another crew. Hunt for the torque spec in a manual nobody's seen in months. Of a four-hour clock, maybe ninety minutes is wrench time. The rest is travel, waiting, and looking things up.
Planned package: the same failure, attached to a job plan written the first time this pump class was serviced. Scope says "replace drive-end and non-drive-end bearings, inspect shaft, replace seals." The procedure lists the steps in order. The kit — both bearings, both seals, the right grease — is staged at the pump on a cart. The plan names the puller and notes it's reserved. The torque table and the alignment tolerance are attached. LOTO points are listed. The tech reads, walks to the cart, and works. Same four-hour clock, but now better than three hours of it is wrench time, and the job is done right because the spec was in hand rather than from memory.
Nothing about the second version is exotic. Every element existed somewhere — the part number, the torque spec, the procedure. The planner's contribution was assembling them into one package before the tech arrived, so the knowledge didn't have to be re-gathered under time pressure. That assembly, done once and stored as a job plan, is the entire mechanism.
The reasons a tech stops, and how the package removes each one
Every element of the planned work order maps to a specific reason a job would otherwise stall. It's worth making the mapping explicit, because it's the argument for why each element earns its place.
A tech stops to find out what to do — the scope statement and procedure remove that. A tech stops to get parts — the kitted, located parts list removes that. A tech stops to find a tool or wait on a crane — the special-tools line, arranged in advance, removes that. A tech stops to look up a torque value or a print — the attached reference docs remove that. A tech stops to figure out isolation or wait on a permit — the LOTO and permit section removes that. A tech stops because the job's bigger than expected and needs another craft — the crafts-and-duration estimate, done honestly up front, removes that.
Each removed stop is wrench time recovered, and the recovery repeats on every execution of that plan. This is why a planner's thirty minutes of preparation returns far more than thirty minutes: it isn't saving one walk to the storeroom once, it's removing a recurring interruption from every future run of the job, across every tech who ever executes it.
Estimating without guessing
"I don't know how long it'll take" is not a reason to skip the estimate. Estimates come from three sources: history (how long it took last time, captured in the CMMS), standard times (published or built-up task durations), and craft feedback (asking the people who do the work).
Early estimates will be wrong. That's fine. An imperfect estimate still lets you build a schedule, and the feedback loop sharpens it. A job estimated at four hours that takes six teaches you something; a job with no estimate teaches you nothing and makes the schedule fiction.
The feedback loop that makes plans get better
After the work, the planner captures actuals — real duration, real parts used, what the plan got wrong — and feeds them back into the job plan. The next version is tighter: the estimate is closer, the parts list is corrected, the missing step is added.
This is the quiet engine of a planning program. A PM library and job-plan library that's actually maintained compounds in quality. After a year, your most common jobs are planned to near-perfection, and the planner's effort per job keeps dropping. Skip the loop and your plans freeze at their rough first draft forever.
A practical first step: plan your top ten
Don't try to plan everything. Apply Pareto: a small fraction of your job types account for most of your recurring work. Pull the ten most frequent jobs from your CMMS history and plan those first.
Those ten plans, reused weekly, deliver an outsized share of the total benefit for a fraction of the total effort — and they teach you the discipline on jobs you understand well before you tackle the rare ones. Once the top ten are solid and a healthy backlog is feeding them into the schedule, you expand from there.
The takeaway
Most teams already have the parts and the people. What they lack is the package — the planned work order that arrives scoped, kitted, estimated, and safe, so the tech can do nothing but execute. That artifact is specific and repeatable, and it's what actually moves wrench time.
Start with ten plans. Build the library. Let it compound.
See how planning runs day to day. Walk through the workflow →