The final goal is to replace a reactive personal workload with a visible maintenance system. You do not need expensive software to begin. Ninety days of consistent basics can materially change how the role feels and how the plant sees maintenance.
Days 1-30: make the work visible
Start by capturing the asset list, critical equipment, current backlog, repeat failures, spare-part gaps, and known safety/obsolescence risks.
When one person owns the queue, the method has to be simple enough to use every time: Create one queue, one log format, and one start-of-shift routine.
At the end of month one, you should be able to answer what is open, what is critical, and what repeatedly consumes your time.
A useful test for days 1-30: make the work visible is reproducibility. If you repeated the same job next month, could you reach the same conclusion from the evidence you recorded? If not, add one more fact while the equipment and reasoning are still in front of you.
Days 31-60: remove repeat pain
Select the few failures causing the most interruption and solve them permanently where feasible.
The point is not extra administration; it is reducing the next uncertainty: Improve documentation, spares, operator instructions, and PM around these faults.
The goal is to create capacity by eliminating recurring work, not by moving faster between the same emergencies.
Do not allow days 31-60: remove repeat pain to depend on remembering a conversation. Put the important point where the next decision will be made: on the work order, machine note, tagged component, drawing, spare bin, or shared queue. Information stored at the point of use survives interruptions far better than memory.
Days 61-90: build resilience
Use the data to strengthen contractor support, backup files, critical spares, staffing case, and vacation/absence coverage.
A reliable one-person routine turns this into a standard rather than a judgment call: Present a concise maintenance status report with risks, improvements, and next priorities.
By day ninety, management should see maintenance as a controlled function with known needs rather than one person who magically appears when something stops.
When days 61-90: build resilience consumes more time than expected, do not hide the overrun. Record what created the delay – access, missing drawings, unavailable parts, unfamiliar software, contamination, damaged fasteners, or production constraints. Those delay causes are maintainability data and often justify the next improvement.
Practical application
Take one recent maintenance event that relates to your 90-day one-technician maintenance system. Reconstruct what you knew at the beginning, before resets, part changes, or production explanations influenced the diagnosis. Then review the event through three lenses from this chapter: days 1-30: make the work visible, days 31-60: remove repeat pain, and days 61-90: build resilience. Write down where your real response matched the method and where it depended on memory, urgency, or luck.
Use the examples as prompts rather than scripts. For days 1-30: make the work visible, the chapter showed: At the end of month one, you should be able to answer what is open, what is critical, and what repeatedly consumes your time. For days 31-60: remove repeat pain, it showed: The goal is to create capacity by eliminating recurring work, not by moving faster between the same emergencies. Decide on one practical change you can make before the same type of event returns – a measurement point, spare, label, note, backup, callout rule, PM task, or escalation contact.
Chapter action checklist
☐ Identify one current weakness related to your
90-day one-technician maintenance system.
☐ Choose one change that can be implemented without new
software or budget.
☐ Decide what evidence should be recorded the next time this
situation occurs.
☐ Identify the point where you would stop and escalate rather
than continue alone.
☐ Add any resulting repair, documentation, spare, training, or
management action to the visible backlog.