Maintenance scheduling software is bought to put dates in a calendar, and putting dates in a calendar was never the hard part. The hard part is that a schedule is a claim on people's time, and most schedules are written without anybody checking whether the time exists. A calendar that says 60 jobs are due this month is a fact; a calendar that says three technicians can do them alongside the call-outs is an assumption, and it is the assumption that fails. This page is about testing it before the dates are loaded, and about what a scheduling product has to show once they are.
Convert the schedule into hours first
Assets times tasks a year times hours a task, divided by twelve. On the worked example this site publishes that is 180 assets, four tasks, 1.1 hours: 60 jobs and 66 hours a month. That figure, not the job count, is what you compare against the people you have.
Then divide by the technicians who are actually available
Not the headcount, the availability. A technician who takes every call-out is not a full unit of PM capacity, and the schedule has to be written against what is left. 66 hours across three is 22 each; across one and a half it is a schedule that will be deferred and then abandoned.
Handle two clocks, because most sites have two
Some assets degrade with time and some with running hours, and a product that can only hold calendar intervals will have the usage-based ones tracked in a spreadsheet beside it. Two schedules of record is worse than one spreadsheet, so this is worth checking before buying rather than after.
Show deferral where somebody will see it
The useful screen is not the month ahead, it is the list of jobs that have been rescheduled more than once. That list is the early warning that a schedule is failing, and it is the one most products bury behind a report nobody runs. Ask to see it in the demo, and ask how a technician or a supervisor would stumble across it without being told to look.
Questions people ask about maintenance scheduling software
Should PM dates be fixed or floating?
Floating from last completion for most assets, because a fixed calendar drifts out of step with reality after the first deferral. Fixed dates make sense where a statutory inspection sets them.
How far ahead should the schedule run?
Far enough to order parts and book cover, which is usually a quarter. A schedule projected two years out is a planning artefact, not an operational one.
What about travel between buildings?
Include it in the task hours if it is real. Fifteen minutes between plant rooms adds a quarter to every short task and is the commonest reason a schedule that looked carryable is not.