Site-wide launches of inspection software fail in a predictable way. Every unit converts at once, every inspector retrains at once, and every data problem surfaces at once. The team that was supposed to support adoption spends its time firefighting, the field reverts to paper and spreadsheets, and six months later the new system is a second place to look rather than the system of record.
The alternative is boring and it works: pick one unit, run it end to end, then expand on evidence.
Why one unit is the right scope
A single process unit is large enough to be real and small enough to be recoverable. It exercises everything the site rollout will need: equipment hierarchy, CML layouts, historical data migration, offline capture in the field, report generation, and the handoff into planning. But when something breaks, the blast radius is one unit's inspection program, not the site's.
One unit also gives you a control group by accident. The rest of the site keeps running the old way, so you can compare cycle times, report turnaround, and rework directly instead of arguing from memory.
Choosing the pilot unit
Resist the temptation to pick either the easiest unit or the worst one. The easiest unit proves nothing; the worst one entangles software adoption with every other problem the unit has.
- Pick a unit with an engaged owner. The unit inspector or reliability engineer should want this. A skeptic assigned by management will document every friction point and fix none.
- Pick a unit with upcoming work. A pilot during a quiet quarter tests data entry. A pilot that runs through a scheduled inspection campaign, or better a small turnaround, tests the product.
- Pick a unit with representative mess. Some legacy spreadsheets, some scanned history, a few renamed vessels. If the pilot data is clean, the site migration plan will be fiction.
Define exit criteria before you start
Write down, before day one, what would make you expand and what would make you stop. Reasonable criteria look like:
- Field adoption. Inspectors complete their routes in the app, offline where needed, without parallel paper copies, by week four.
- Report cycle time. Findings reach the reviewed-report stage measurably faster than the unit's historical baseline.
- Data integrity. Migrated history spot-checks clean against source documents, and new readings land on the correct CMLs.
- Backlog visibility. Open recommendations and overdue inspections for the unit are visible in one place and trusted by the unit owner.
If the pilot misses these, stopping is a success, not a failure. You spent one unit's worth of effort to avoid a site-wide mistake.
Expanding without losing the plot
The expansion sequence matters less than the discipline: each wave inherits the checklists, the migration crosswalk templates, and the training materials the pilot produced. The pilot inspectors become the trainers. Do two or three units in the second wave, then batch by area. Keep the old system read-only, not deleted, until each unit's history is verified in the new one.
The common failure in expansion is declaring victory after the pilot and handing the rest to a project manager with a deadline. The pilot's value is the evidence and the artifacts it generated. Use them.
This staged pattern is how we recommend running intelliSPEC deployments, and the 30-day trial exists so the first unit can start without a procurement cycle. Whatever platform you deploy, earn the site rollout one unit at a time.
