Delivering a first AI project in maintenance: a 90-day roadmap
How to run a first AI project in industrial maintenance without spreading yourself thin: the scope to pick, the first 90 days, and the traps that sink it.
A first AI project rarely fails on the technology. It fails because it was too ambitious, poorly scoped, or launched on a subject nobody really needed solved. People want to "do AI", they hunt for an impressive use case, they tie up weeks of effort, and six months later all that remains is a demo nobody opens any more.
A successful first project aims at the opposite. It takes one specific irritant, solves it on a narrow scope, and proves it quickly enough that the organisation believes in it. Here is how to run it in a single quarter.
The essentials
The right first project is not the most spectacular one, it is the most verifiable. It targets a task that costs measurable time, on a scope small enough to finish in three months, using data you already hold. The opening question is never "what can AI do" but "which repetitive work costs us the most, and can AI prepare it". Everything else follows from that choice.
Choosing the right case, the one you can prove
Most first projects are chosen back to front: people start from the technology and look for somewhere to apply it. You have to start from the work.
A good first case meets four conditions. It targets a task that is repetitive and time-consuming, the kind you redo every week without thinking. Its cost is measurable, in hours and in people, so you can compare before and after. The data already exists, with no data-collection project needed first. And a mistake is recoverable, because a first project should never be launched on a decision that affects safety.
In maintenance and inspection, three cases almost always tick these boxes. The consolidation of scattered inspection reports, to rebuild the history of an asset base. The extraction of data from documents nobody re-keys, covered in turning PDF reports into usable data. And searching the history, when finding what was done on a piece of equipment takes half a day.
Conversely, two subjects make poor first cases, however appealing they look. Failure prediction, which assumes sensor data most sites do not yet have. And any fitness-for-service decision, which carries liability and should not be handed to a first project, for the reasons developed in what AI decides and does not decide.
The 90 days, in three phases
Days 1 to 30: scope and measure
Pick a narrow, dated scope: one equipment family, one workshop, a known deadline such as an upcoming turnaround. Measure what the task costs today, in hours spread across how many people. That figure is your baseline, and it will justify what comes next to management. Build a control set of twenty documents whose contents you know by heart: it will tell you whether the tool is faithful.
Days 31 to 60: run it on your real data
Never on demo samples, which are always clean. Your documents are scanned at an angle, signed by hand, produced by several contractors in different formats. That is where the project is won or lost, and that is where the hard cases surface. Check every result against your control set, and note where the tool gets it wrong: those errors map out its real limits.
Days 61 to 90: prove, document, decide
Compare the time spent before and after, on the same scope. Write a one-page note: what worked, what failed, what you conclude from it. That document is what will circulate and decide the next step, not the demo. Then decide, on evidence: extend, adjust, or stop. A project stopped on clear data is not a failure, it is a decision.
The traps that sink a first project
The most common is too broad a scope. Wanting to process the whole asset base on the very first project guarantees finishing nothing in three months. One workshop that works pulls the rest along; a total project that drags demoralises everyone.
The second is the absence of a starting measure. Without the figure for the time consumed today, no progress will be visible and nobody will be able to defend the extension. You will feel that "it helps", without being able to prove it, and a feeling does not fund a deployment.
The third is the demo on ideal data. A tool that works on clean samples and fails on your real documents has proved nothing. The test only has value on real material, with its skewed scans and its unusual formats.
The fourth is leaving verification out of the calculation. AI does not remove processing time, it shifts it towards a shorter, more qualified verification. An honest gain calculation counts that time; a calculation that forgets it announces savings that will never materialise.
The last, and more insidious, is staying alone. A project understood by a single person dies on their first holiday. Bringing a second person up to speed from the very first project turns an experiment into a practice, and that is what separates a trial from a real start. The change management around this point is covered in training a maintenance team on AI.
A March turnaround as the deadline
A chemicals site wanted to "get into AI" without knowing where to begin. Rather than a grand project, the team took a concrete deadline: the scheduled March turnaround, which every year requires rebuilding the inspection history of around a hundred pieces of equipment from scattered reports.
The scoping showed that this consolidation cost roughly two hundred hours, spread across three people, every year. The scope was naturally bounded by the turnaround, the data existed, and a consolidation error was recoverable since everything was re-checked.
In three months, on that single scope, the team was able to show a measured time saving and, above all, a one-page note that served to decide on extending to a second workshop. The project did not succeed because it was ambitious, but because it was finished.
After the 90 days
A successful first project is not judged on the time saved, which is real but modest on a narrow scope. It is judged on what it makes possible: an organisation that has seen a verifiable result, a second competent person, and a note that lets you decide the next step on facts.
The extension then follows its own logic. You move from one workshop to a site, you add a neighbouring use case, you connect the tool to the CMMS or the integrity software so the extracted data feeds the monitoring rather than sitting in a corner. The choice of these tools is covered in how to choose a CMMS.
What does not change, from one project to the next, is the discipline: a bounded scope, a starting measure, a counted verification, a decision on evidence. It is less seductive than a promise of transformation, and it is what separates a blog of demos from a plant that moves forward.
- Choosing the most impressive case.The right first case is the most verifiable, not the most spectacular. Failure prediction looks exciting and fails for want of data; history consolidation pays off straight away.
- Launching without measuring the baseline.Without the current cost in hours, no gain can be demonstrated. The starting figure is worth more than the demo.
- Testing on clean samples.Your real documents are imperfect, and that is where the project is decided. A demo on ideal data proves nothing.
- Targeting the whole asset base from the outset.Too broad a scope will not finish in three months. One workshop that works pulls the rest along.
- Forgetting verification time.AI shifts the work towards a shorter verification, it does not remove it. An honest gain counts it.
- Staying the only person who understands the project.It dies on the first holiday. Two trained people turn a trial into a start.
Where should you start an AI project in maintenance?
With the repetitive task that costs you the most measurable time and whose data already exists. In practice, that is almost always the consolidation of the inspection history or the extraction of data from reports nobody re-keys.
How long does a first project take?
A quarter is enough if the scope is bounded: thirty days to scope and measure, thirty to run it on your real data, thirty to prove and decide. Beyond that, it is often the sign of too broad a scope.
Which use case should you avoid for a first project?
Failure prediction, which assumes sensor data most sites do not have, and any fitness-for-service decision, which carries liability and should not be handed to a first trial.
How do you prove the project succeeded?
By comparing the time spent before and after on the same scope, then writing it up in a one-page note. That document decides the next step, not the demo.
Do you need a big budget to start?
No. A first project is run on existing data and a narrow scope. The main cost is not the licence but the time for scoping, verification, and training a second person.
Written by Adama CamaraAI Consultant · Industry · view profile
Published on June 29, 2026
Software and data
Industrial AI: What It Really Is, and What It Changes on the Plant Floor
Industrial AI without the jargon: use cases by function and by sector, limits, costs, financing and a roadmap to get started in your plant.
Skills and transformation
Training your team to use AI in industry: what actually works on the shop floor
Why AI training fails in technical teams, and the sequence that works when people are on shift, in the field, and nowhere near a desk.
AI and maintenance
Can AI Replace the Inspector? The Line Between Preparing and Deciding
What AI can genuinely do with inspection and maintenance data, what it must never decide on its own, and why the sign-off stays human.
Software and data
How to choose a CMMS: the method, the traps, and the spreadsheet nobody dares abandon
What a CMMS does and does not do, how to choose one without regret, when a spreadsheet still does the job, and where AI genuinely changes things.