The rollouts that work

After enough rollouts, the same patterns repeat. They have nothing to do with company size or industry, and almost none of them have to do with the tool.

These are the five traits that show up in the ones that work, and the four that show up in the ones that stall halfway.

What the ones that work do

1. They start small

Critical assets, not the full inventory. The equipment that halts production or service if it fails, and the equipment with regulatory obligations: usually fewer than fifty.

With that, preventive maintenance is already being generated and orders are closing with real data within weeks. The rest comes in afterward, once the habit is already in place.

2. They bring the technician in from the start

Before deciding on the purchase, not after. A technician can tell within two minutes whether the app is going to waste their time, and that’s the test with the most predictive value in the whole process.

Then they start with a small group for a few weeks. That trial reveals the adjustments nobody had planned for and — more importantly — the arguments to convince everyone else: one technician telling another that they no longer call the office convinces more than any training session.

3. They have someone in-house in charge

They don’t have to be technical. They have to understand the operation and be able to make decisions without calling a meeting for every configuration question.

Without that person, every small decision turns into an email and startup drags on for months.

4. They ask for few fields

And the rule behind it: every field you ask for has to come back to someone as something useful. If a piece of data is never looked at, it gets removed.

Multiplied across every order in the year, one useless field means hours, and one more reason to fill things in carelessly.

5. They close the loop

What the technician records has consequences. A detected anomaly turns into an incident with an owner and a date, or into an explicit decision to do nothing.

It’s the trait that stands out the most. If it’s logged and nothing happens, the technician stops logging it after the third time, and from then on the history is incomplete exactly where it had the most value.

What the ones that stall halfway do

1. They start with the full inventory

Six months loading data before seeing a result. It’s the most common mistake and the one that stalls the most projects: the team gets tired before the system returns anything.

2. They configure it in a meeting room

Without whoever’s going to use it. The result collides with reality on the first day in the field, and by then there’s already a configuration in place that’s hard to change.

3. They use it to monitor the team

It’s the most damaging one and the least recognized. A team that senses the system exists to watch them logs things late, rounds off times, and stops noting anomalies.

Once that happens, reports describe a reality that doesn’t exist, and at that point the system doesn’t just fail to help — it actively misleads.

4. They expect it to fix the process

If today nobody decides who handles what or with what priority, the system will just record the same disorder more precisely. That conversation comes first, costs no money, and is the single biggest determinant of the outcome.

The signs at the three-month mark

If you want to know early which path you’re on, look at three things.

The complaints are specific. “This field gets in the way,” “this alert is annoying.” It means they’re using it. Silence is the worrying sign.

The questions change type. From “how do I do this” to “how do we configure that.” A sign the team has moved from learning to adapting.

The data makes sense. If logged hours and completed plan line up with what everyone knows actually happened, the record is accurate. If the plan shows 100% completion and corrective work isn’t dropping, someone is closing orders without doing them — and that’s a trust problem, not a software one.

The moment it gets decided

There’s a specific point on the calendar where almost every rollout’s outcome gets decided, and it arrives sooner than expected: the third or fourth week.

That’s when the initial enthusiasm has worn off, the system still isn’t returning useful reports, and the team has spent days entering data with the feeling that it’s for nothing. If there’s nothing tangible to show at that point, the project starts losing priority and never gets it back.

What saves it is having something ready to show right then: usually the first preventive orders generating themselves and closing in the field, with their actual times.

That’s why the startup scope isn’t chosen based on what would be ideal to cover, but on what can be up and running in three weeks.

What doesn’t predict anything

For what it’s worth: company size, project budget, and the number of modules activated don’t predict the outcome.

There are small rollouts that work very well and big projects that end up as an unused license. The difference is almost always in the five traits above.

One more trait, present in all of them

The rollouts that work have something in common that isn’t a practice but an expectation: they understand that value arrives in stages.

The first few weeks return nothing visible beyond work no longer getting lost. By the third month, the first uncomfortable data point shows up, usually that the real hours weren’t what people thought. By the first year, decisions can be made about frequencies and replenishment. And by the second year, full periods get compared.

The ones that get frustrated are the ones expecting year-one decisions in month two. And the ones that give up usually do it right before the third month, which is exactly when something was starting to show.

Saying this up front — that for a few weeks it’s going to look like data is being entered for nothing — prevents a fair amount of burnout.

If yours has stalled

It’s almost always the same thing: too much was attempted. The way out isn’t asking for more support, it’s reducing scope: going back to critical assets with their checklists and frequencies, and leaving the rest for once that’s been running smoothly for weeks.

And if it hasn’t started yet, the best investment beforehand isn’t choosing a tool: it’s writing the list of critical assets and, for each one, what gets done to it and how often. That work holds its value regardless of the system, and it’s the part that takes the longest.

If you’d like to compare notes on how yours is going, you can get in touch or request a demo.