A Maximo Mobile rollout fails in one of three ways. The app is technically perfect but the field team carries on using paper. The app gets used grudgingly for a quarter and then quietly drops out of daily work. The app gets used everywhere except for the things that actually generate revenue or cost. None of those are technology failures. They are operating-model failures dressed up as mobile projects.
This guide is for the operations sponsor or programme lead who has a Maximo Mobile rollout coming up and wants the candid view, not the marketing one. It draws on the rollouts we have run and on the failure modes we have inherited from rollouts other partners did first.
Decide what “good” means before you ship anything
The single most useful question before any mobile design work starts: what does the technician do today, on what artefact, and what would have to change for them to do it on the device instead?
The answer is rarely “they fill in a form on paper”. The answer is usually “they take a photo, they make four phone calls, they look up a part number in a binder, they ask the supervisor to authorise an overrun, they sign off the job, they hand the docket in at the end of the shift”. A mobile app that handles only the form is a mobile app that survives until the first photo, the first phone call or the first overrun.
The success criterion is binary: does the technician finish the job on the device, without picking up a paper job card or a phone? If the answer is “mostly”, the rollout has failed. If the answer is “yes”, it has succeeded. That bar is the one we agree with sponsors before any wireframes appear.
Device choice: less interesting than people think
Pick the device the field team will actually use. Not the one IT prefers. Not the one finance can amortise. The one the technician can hold with gloves on, in the rain, with the headlamp shining on it, and still see.
In practice, the choices we see work:
- Rugged Android tablets (8 inch) for technicians who carry tools and need to glance at a job card. The category is mature: Zebra, Honeywell, Panasonic Toughbook. Battery measured in shifts, not hours. Glove-touch. Daylight-readable. Drop-rated to a height that survives a real fall, not a desk fall.
- iPads in protective cases for asset-management teams in cleaner environments — buildings, airports landside, manufacturing floors that allow consumer devices.
- Smartphones only for inspectors and supervisors who do not need to do hands-on work on the device.
What does not work: BYOD policies on field teams. The risk of a missed sync because someone’s personal phone was out of storage is exactly the risk a mobile rollout is supposed to remove.
Offline-first or do not bother
This is non-negotiable. If the technician can lose connectivity at any point in the day — basement plant rooms, tunnels, between sites, on a vessel, on an airfield — the app must work fully offline. That includes:
- Loading the day’s work bag at sign-in.
- Capturing meter readings, photos, parts used, time, failure codes, completion status while offline.
- Detecting connectivity returns and syncing back, with conflict resolution that does not require the technician to make a decision.
- Surviving an OS-forced restart mid-shift without losing data.
A “mostly offline” mobile rollout fails the moment the technician learns it loses data once a fortnight. They go back to paper for the things that matter and use the app for the things that do not. That is the worst possible outcome — the cost of the rollout with none of the benefit.
Role-based UI, ruthless
The screens technicians use must be designed for technicians. Not for a supervisor. Not for a planner. Not for a desk-based admin who understands the work-order data model.
We strip the work-order screen down to:
- Job summary in plain language.
- Asset and location, with one tap to a map and one tap to history.
- Task list with check-off.
- Time, parts and meter capture.
- Photo capture with mandatory captions.
- Failure code with a curated list — usually no more than fifteen items, picked by reliability engineering, not the IBM default of 600.
- Sign-off and synchronisation.
Everything else is hidden behind a “more” affordance. The full work-order detail still exists for the planner on their desktop. The technician sees what they need to do the job, no more.
The same is true of asset and inspection screens. Role-based UI is the single biggest difference between a rollout people use and one they tolerate.
Supervisor sign-off in the field
The single most-skipped requirement: supervisors must be able to authorise overruns, deferrals, and parts requests on the device. If the supervisor still needs to sit at a desk to sign things off, the work backs up at the supervisor’s desk, technicians wait, and the field bypasses the system to keep moving.
This means:
- Supervisor role on the same device class, with the right approvals surfaced.
- Push notifications when an approval is waiting (or, on a Maximo Mobile model that does not yet do push, a pull-to-refresh that takes seconds).
- Audit trail of who approved what, when, against which work order.
The supervisor view is the second-priority screen design after the technician view, not an afterthought.
What to integrate, what not to
The temptation on a mobile rollout is to integrate everything. Resist it.
Integrate the things that prevent the technician from finishing the job offline:
- Asset history and prior work, cached at sign-in.
- Parts catalogue and on-hand by store, cached at sign-in.
- The full task plan and any safety documentation.
- The minimum subset of customer or vendor data to identify the asset.
Do not integrate things that the technician does not need at the point of work:
- Real-time finance approvals beyond the supervisor’s local authority.
- Live inventory across the whole estate (versus the cached local view).
- HR, payroll, time and attendance — those go through their normal channels at end of shift.
Each integration is a synchronisation cost and a failure mode. Adding a sixth integration to save twenty seconds on one screen is an exchange we have seen people make and regret.
Pilot like you mean it
The pilot is where rollouts get saved or killed. Two principles:
- Pilot with the toughest crew, not the friendliest. The crew that already runs efficiently on paper will be the harshest critics, and they are right. If they accept the device, the rest of the field accepts it. If you pilot with the friendly crew, you ship to the field and discover the harsh feedback after go-live.
- Pilot for at least one full operating cycle — for most field teams, four to six weeks. Long enough that the first round of seasonal or shift-related issues surfaces. Long enough that the technician stops being polite about the friction.
The pilot output is a candid list of changes, not a slide deck. We write it as a numbered backlog, prioritise it with the field supervisor, and either fix it before broader rollout or document the trade-off.
Training is short and on the device
Mobile training that lasts a day in a classroom is mobile training that fails. The device is the medium. Training is on the device, in the field, with a real work order, supervised by someone the technician trusts. Twenty minutes per technician at induction, ten minutes of refresher when something material changes.
The training material lives on the device too. A short, role-specific video for each screen, accessible from the screen itself. Updated when the screen changes. This is mostly a content problem, not a software problem.
The metrics that tell you it worked
After three months of broad rollout, the numbers we look for:
- Share of work orders completed on the device, by craft and by site. Target: above 90% within three months.
- Share of work orders with meaningful close-out data captured on the device — actuals, parts used, failure codes, photos. Target: above 80%.
- Time from job complete on the device to the work order being closed in the back office. Target: same shift.
- Share of supervisor approvals captured on the device versus on the desktop. Target: above 70% within three months.
- Field-team satisfaction, surveyed quarterly. Not as a vanity metric — as a leading indicator of bypass.
If those numbers are not moving in the right direction by month three, something in the design or operating model is wrong. Adding training will not fix it. Going back to the role-based UI and the offline behaviour usually will.
When AI starts to matter
Mobile is the most natural surface for AI assistance in the work loop. Asking the device “what was the last issue on this asset” or “what spares are typically used for this job” is a much more useful interaction than scrolling through history. We are starting to build that into rollouts on the back of Maximo Field Service Management and the broader MAS suite. It is not a substitute for getting the basics right. Done in that order, it adds genuine speed in the field.
Where this fits in the wider programme
A successful Maximo Mobile rollout is part of a larger work-management programme: master data quality, planning discipline, role-based design, supervisor coverage, and the operational reporting that makes the data the technician captures actually useful. The Maximo health check guide is the right baseline before a rollout. The business process optimisation service is what we deliver alongside.
If you have a rollout coming and want a candid second opinion before you commit to scope, talk to us.
Talk to the people who would actually deliver it
No pitch deck, no pressure. A direct conversation with one of our senior consultants.