Fleet software implementations fail on data and on ownership, almost never on the software. This plan front-loads both.
It assumes a single-country fleet of 50–500 vehicles, one or two depots in phase one, and a standard telematics integration. Scale the durations, not the sequence.
Before week 1: decisions that must already exist
- Named business owner with authority over maintenance and operations, not a project manager alone.
- Defined phase-one scope with an explicit "not in phase one" list, agreed in writing.
- Success criteria with numbers: what will be true in month six that is not true now.
- Baseline measurements captured over at least four weeks — see ROI business case.
Without these, the plan below will run and the project will still drift.
Weeks 1–3: Discovery and data audit
Objectives. Know exactly what data you have and how bad it is.
| Task | Output |
|---|---|
| Inventory every existing data source | List of systems, owners, formats, record counts |
| Asset register reconciliation | Vehicles that exist in fleet but not in finance, and vice versa |
| Maintenance history assessment | How many years are usable, and in what form |
| Document audit | Which certificates exist, which are expired, which are missing |
| Odometer source review | Current sources, conflicts, precedence decision |
| Process mapping | Current defect-to-repair flow, current PM triggering |
Expect the asset register reconciliation to find discrepancies. Fleets routinely discover vehicles that were sold, vehicles that were never added, and duplicates from a depot merge. Finding these in week 2 is a success; finding them in month 9 is an incident.
Weeks 3–5: Configuration design
Run these as workshops, one decision per topic, documented:
- Asset hierarchy and grouping — by depot, contract, vehicle class, cost centre. Grouping decisions are hard to change later and drive every report.
- PM schedule design — which schedules apply to which vehicle classes, intervals, tolerance windows, and who approves changes.
- Work order workflow — states, approvals, cost thresholds, internal versus vendor routing.
- Defect intake — how a driver-reported fault becomes a work order, and the severity rules that take a vehicle off road.
- Permissions model — roles, what each sees, what each can change.
- Document types and expiry rules — notification chains and escalation.
- Report set — the ten reports that will actually be used, with owners.
Resist configuring everything the product can do. Every configured feature is a maintenance obligation.
Weeks 5–9: Data preparation and migration
The critical path. Run it in three passes.
Pass 1 — Cleanse in the source. Fix in the system of record where possible. Migrating clean data is far cheaper than cleaning after migration.
Pass 2 — Transform and load into a test environment. Load the full data set, not a sample. Sample loads hide the records that break.
Pass 3 — Validate. Reconcile counts and totals against the source. Have a depot manager check twenty vehicles by hand, including two awkward ones.
Decide explicitly how much maintenance history to migrate. Common answer: full open work orders, plus 24 months of closed history for cost trending, plus lifetime major events (engine replacement, accident repair). Migrating ten years of line-level history is expensive and rarely used.
Weeks 9–11: Integration
Telematics first, since it drives odometer capture and therefore PM accuracy. Then fuel cards. Then finance.
For each integration, agree in writing: field mapping, direction, frequency, error handling, who is alerted on failure, and who fixes it. "The vendors will sort it out between them" is not an answer, and it will be tested in month two.
Weeks 11–13: Testing and training
Test with real scenarios, not click-throughs. A vehicle fails a check, is taken off road, is repaired by an external vendor, returns to service and the cost lands on the right cost centre. Run the whole chain.
Train by role, in short sessions, close to go-live. Workshop staff, drivers, depot managers and administrators need different sessions. Training delivered eight weeks before go-live is forgotten by go-live.
Write the quick reference cards. One page per role. The single highest-return training artefact, and the one most often skipped.
Weeks 13–14: Go-live
- Freeze the source system for changes 48 hours before cutover.
- Final delta migration.
- Reconcile again.
- Run both systems for a defined, short overlap — two weeks, with a hard stop.
- Daily stand-up for the first two weeks, with a visible issue list.
Weeks 14–16: Stabilisation
Expect a dip. Productivity falls before it rises, and the organisation's confidence is decided in this window.
Watch for: PM schedules firing incorrectly (usually an odometer mapping issue), work orders being created outside the system (a workflow gap), and reports disagreeing with the old numbers (usually a definition difference, occasionally a real error). Fix these publicly and quickly.
Month 4 onwards: the part everyone forgets
Assign the ongoing owner of data quality, configuration changes and report definitions. A system without a named owner degrades within a year: schedules stop matching reality, permissions accumulate, and the report pack fills with numbers nobody trusts.
Schedule a formal three-month review against the original success criteria. If a criterion has not been met, decide whether it was wrong or the implementation was — both are legitimate answers, and neither is served by silence.
Frequently asked questions
Can we implement faster than 16 weeks?
Yes, if the asset register is already clean, integrations are simple and the scope is genuinely narrow. What cannot be compressed is data validation and the decision workshops. Projects that "save time" by skipping those pay for it in months three to six.
Should we do a pilot depot or go fleet-wide?
Pilot with one depot if you have more than three, or more than about 150 vehicles. The pilot's purpose is to find your process gaps cheaply, so pick a representative depot with a cooperative manager — not the easiest one and not the worst.
Who should be on the project team?
A business owner with authority, a workshop or maintenance lead, an operations representative, an IT contact for integrations and identity, and a data owner. Five people who can decide beats a committee of fifteen.
How much internal effort should we budget?
For a mid-sized fleet, roughly 0.5–1.0 full-time equivalent across the project for the business owner and data work, plus workshop time from operational staff. Under-budgeting internal effort is the most common cause of schedule slip, and vendors rarely raise it.
What if the data is too bad to migrate?
Then migrate the asset register only, start collecting clean data from day one, and keep the old system read-only for historical queries. It is a legitimate, often correct decision — far better than importing history nobody can trust into a system whose credibility you are trying to establish.
