The TRACIO Programme Method.
A four-stage, gate-driven model for vendor-neutral RTLS, RFID and IoT programmes — built from twenty years of running them, recovering them, and sitting on the vendor side of the table when they failed.
Most RTLS programmes fail at the same three points.
After twenty years of running and recovering RTLS, RFID and IoT programmes, the failure pattern is consistent: an unsurveyed architecture, a pilot that never tested production load, and an integration that nobody owned past go-live.
The TRACIO Programme Method exists to make all three impossible.
1 · Skipped survey
Vendors pitch off a spec sheet. We require a predictive RF site survey before any architecture is signed, because the physics of metal, liquid, multipath and density does not care about the brochure.
2 · Demo-load pilot
Pilots that prove only the happy path are the single biggest source of failed rollouts. Our gate-2 criteria force the pilot to run at full production volume, with real users, for long enough to expose the edge cases.
3 · No post-launch owner
By gate-3 we have a signed operational handover: who owns drift detection, who calibrates, who recalibrates when the building changes. Without it, accuracy quietly erodes and nobody notices until something breaks.
Each stage closes with a gate. No gate, no spend.
Every stage produces specific, board-ready deliverables and ends with a written go/no-go decision tied to evidence. You can stop the programme at any gate and exit clean — that is what protects the budget.
01 · DESIGN
What we produce: Discovery report, KPI tree, predictive RF site survey, vendor-neutral architecture, business case with NPV / IRR / payback, and a multi-year roadmap aligned to your corporate strategy.
What we hand over at gate 1: A defensible architecture decision, a costed programme plan, and a quantified ROI model the board has signed.
02 · VALIDATE
What we produce: Hypothesis-led proof of concept and in-situ pilot with measurable go/no-go criteria; pilots designed to mirror production load — not marketing load.
What we hand over at gate 2: Empirical evidence that the chosen architecture, vendor and accuracy budget hold up under real conditions. If they do not, you exit before scaling the spend.
03 · DEPLOY
What we produce: Multi-site, multi-region rollout governance with PMO reporting, MES / ERP / WMS / EMR integration, OT cybersecurity to IEC 62443, change management, UAT scripts, and as-built documentation packs.
What we hand over at gate 3: A production system signed off by IT, OT and the business, with a named operational owner and an SLA in place.
04 · OPTIMISE
What we produce: SLA-backed launch support, quarterly performance audit, drift analysis, optimisation cycles, and a loop back to Design when the operation evolves.
What we hand over each quarter: A measured-vs-baseline performance report, root-cause analysis on any drift, and a prioritised optimisation backlog tied to the same KPI tree we set up in stage 1.
Five gate criteria that survive procurement scrutiny.
Accuracy budget
The architecture proven to meet your defined accuracy requirement under production conditions — not a vendor demo.
Integration evidence
Data actually flowing into MES, ERP, WMS, EMR, CMMS or your bespoke stack. Not a "future-state" diagram.
TCO defended
Five-year TCO and ROI modelled with sensitivities, signed by finance. Hardware, software, integration, change and operations all costed.
Security signed off
OT / IT segmentation to IEC 62443, identity, encryption and audit trails reviewed by your CISO. RTLS is operational technology and must hold up.
Operational owner
A named individual or team that owns calibration, monitoring, drift and optimisation post-launch. No owner, no go-live.
Exit option
The contract permits a clean exit at any gate. The programme cannot become a sunk-cost trap. That is the structural protection.
The difference is structural, not stylistic.
A vendor-led RTLS programme is, by design, structured to get the hardware order signed. The pilot is designed to win the deal, not to expose the edge cases. The architecture is sized to fit the catalogue. The post-launch support is a separate, optional contract.
The TRACIO Programme Method inverts those incentives. We do not sell hardware. We do not earn margin on the vendor we recommend.
Every gate is designed to protect your ability to exit, not to protect a sales target. The pilot is designed to expose problems early, not late. The architecture is sized to your operation, not to a product line.
That is why our programmes survive board scrutiny — and why a third of our engagements start as rescues of someone else's stalled rollout.
Where the method is most often applied.
Services that apply the method.
Frequently asked questions
What is the TRACIO Programme Method?
A four-stage, gate-driven methodology for delivering vendor-neutral RTLS, RFID and IoT programmes. The stages are Design, Validate, Deploy and Optimise. Each stage ends with a written gate decision tied to evidence, so the programme can exit cleanly at any point.
Is it tied to specific vendors or technology?
No. The method is technology-neutral — UWB, BLE-AoA, RAIN RFID, Wi-Fi RTT, GNSS, GNSS-RTK, SLAM and vision are all valid outputs depending on the use case and physics. Vendor selection happens inside Stage 1 (Design), evaluated against your environment and TCO.
Can we adopt only part of the method?
Yes. Clients commonly engage us for a single stage — a discovery, a pilot recovery, or a quarterly audit — without committing to the full programme. The gates are the protection mechanism, not a lock-in.
How is this different from a typical SI methodology?
System-integrator methodologies are usually built to deliver a specified system. Ours is built to protect the buyer's ability to exit at every stage, because we have no hardware to sell and no platform to defend. The economic incentive is to be right, not to grow the SOW.
Does it support compliance requirements (IEC 62443, 21 CFR Part 11, AS9100, IATF 16949)?
Yes. Compliance is built into the Design and Deploy stages as a non-negotiable gate criterion, scoped to your specific regulatory and certification needs.
How long does a typical programme take, end to end?
Discovery and design typically run 6–12 weeks. Validation (PoC + pilot) usually 8–16 weeks. Deployment depends entirely on scope — a single site can be live in months, a global multi-site rollout in 12–24. Optimisation is continuous.
Last updated: