Most Maximo rollouts that visibly stall do so at a single, predictable point in the operating model. Not the technician on the wrench. Not the planner at the desk. The front-line supervisor: the foreman, team leader, area lead, or shift supervisor who stands between the work that has been planned and the work that actually gets done. A surprising number of Maximo rollouts spend most of their adoption budget on people on either side of that role, and almost none of it on the role itself.
That asymmetry is not a detail. It is a structural property of how these programmes are scoped, and it explains a recognisable failure mode: a Maximo rollout where the system is technically live, the technician app is in everyone’s hand, the dashboards are green, and yet the work is still being run on a parallel set of paper sheets, WhatsApp groups, and supervisor knowledge. The rollout has stalled at the supervisor, and the rest of the operating model is quietly working around it.
The role Maximo rollouts under-design
The supervisor is the only role in a maintenance operation whose primary output is decisions about other people’s work. They release jobs, prioritise the day, reassign when reality breaks the plan, sign off completion, push back on bad scope, escalate safety risk, and protect the crew from interruptions the planning system cannot see. Industry bodies that work on the role, including SMRP, treat front-line supervision as one of the highest-leverage points in any maintenance organisation.
Inside Maximo, that translates into a specific set of activities: approving work orders so technicians can start, vetting job plans against site reality, owning daily and weekly schedules, accepting or rejecting completion, raising follow-on work, and protecting compliance evidence on safety-critical jobs. None of these are exotic features. They are exactly what Maximo has always been designed to support, and IBM’s own documentation positions the supervisor as the work-order approver who gates execution. The problem is not the product. The problem is that programme teams routinely scope around this role rather than for it.
What programmes typically deliver to the supervisor
A clean way to test this is to look at what the rollout actually ships into supervisor hands on go-live day. In a recognisable share of programmes, the answer is one of the following.
- A copy of the planner’s screen, on the assumption a supervisor is “basically a planner with a different hat”.
- A read-only manager dashboard, optimised for reporting upwards rather than directing the day.
- The same Maximo Mobile build the technicians use, with no thought given to what an approver, prioritiser, or daily-plan owner actually needs.
- A workflow that routes approvals into an inbox the supervisor checks twice a day, while the field is running in real time around them.
None of these are wrong on their own. Together they describe a rollout that has not been designed for the role. The supervisor ends up with the union of everyone else’s tools and none of their own. The predictable response is to keep working off-system: a printed schedule, a marker board, a WhatsApp group, a spreadsheet of priorities. That is the point at which adoption stalls. The technician is in Maximo, the planner is in Maximo, but the operational decision layer between them is not.
Where the design effort actually goes
Programmes do not arrive at this position by accident. They arrive at it because the visible, demo-friendly investments are elsewhere. Mobile experience is the first draw: a modern technician app with offline work, photos, attachments, and signatures demonstrates well in steering meetings and is genuinely valuable. The supervisor view, which is harder to demo because it is about decisions rather than transactions, gets whatever time is left.
Reporting is the second draw. Sponsors want dashboards. Programmes ship them, and the dashboards become a proxy for “the supervisor’s tool”. They are not. A dashboard tells a supervisor what already happened. It does not help them release tomorrow’s work, defend today’s schedule against a breakdown, or decide which of three competing PMs to drop when the crew is short.
Workflow is the third draw, and the most damaging. Approval ladders are imported from existing paper or email processes without being redesigned for a system where work is released in near real time. A four-step approval chain that took two days on paper becomes a four-step approval chain that takes two days in Maximo, except now the technicians are idle on a mobile app waiting for it. The supervisor inherits the operating model’s friction without inheriting the tooling investment that would make it tractable.
What a supervisor-centred rollout looks like
The pattern is fixable. It does not require a different product, and it does not require the rollout to start over. It requires the supervisor role to be designed against with the same seriousness applied to the technician and the planner. A few moves carry most of the value.
- Treat the supervisor as a distinct user, with their own Start Center or workspace. The supervisor’s landing page should show the work awaiting their approval, today’s crew assignment, the open backlog by priority, the safety-critical PMs in the next seven days, and the work that came back rejected. Nothing more.
- Redesign approval before automating it. A supervisor approval that exists only because it always existed on paper is a candidate for retirement, not for replication. Approvals that genuinely add control should be visible in a single place, with the data needed to make a sound decision on screen.
- Make daily scheduling a first-class supervisor activity in the system. Where Scheduler or a comparable tool is in scope, the daily-planning view belongs to the supervisor. Where it is not, the work-list view should be designed for re-prioritisation, not just review. A supervisor who has to fight the system to move work between technicians will keep the real schedule on a board.
- Decide explicitly what runs on mobile and what does not. Maximo Mobile supports supervisor approvals and work review, and that is appropriate for some operating contexts. A supervisor at a desk in a control room may be better served by the full web client. The rollout should make this an active design choice rather than a default.
- Measure adoption at the supervisor layer. Most dashboards count technician transactions and call that “Maximo usage”. The harder question is whether the supervisor’s decisions are being made in the system: approvals turned around inside the shift, schedules committed in Maximo, rejections recorded with a reason, follow-on work raised against the asset history. If those are happening, the operating model is working. If they are not, the rollout is hollow regardless of how many work orders the technicians close out.
This is the same argument that runs through any credible discussion of field service management on Maximo. The rollout succeeds or fails on whether the operating model around the platform has been designed, and the supervisor sits at the centre of that operating model.
The position
The honest read on the stalled-rollout pattern is this. Maximo, in its current form, gives the supervisor everything the role needs. The work-order approval gate, the configurable workspace, the mobile approvals capability, the workflow engine, and the integration into planning and scheduling have been mature parts of the product for years. What is missing is not technology. It is design intent.
Programmes that treat the supervisor as a residual user, served by whatever is left after the technician and the planner have been looked after, produce stalled rollouts. Programmes that put the supervisor at the centre of the day-of-execution operating model produce rollouts that survive the first six months after go-live, when the original sponsor has moved on and the system has to defend itself on operational merit alone.
The role is not glamorous. It is not where the demo lights up. It is where the work is decided, and any Maximo programme that intends to change how work gets done has to design for it.
For more on how the team approaches operating-model design and adoption inside MAS programmes, see the MaxIron services overview.