I want to talk about a failure mode that almost never shows up in a technical review, because it is not technical. I have seen tracking systems go fully live, work as designed, get through evaluation, and still end up shelved or cancelled a year or two later.
I want to talk about a failure mode that almost never shows up in a technical review, because it is not technical. I have seen tracking systems go fully live, work as designed, get through evaluation, and still end up shelved or cancelled a year or two later. When you dig into why, the tags and readers are almost never the reason. The reason is almost always one of three things: the person who championed it left, the team who was supposed to use it day to day never really adopted it, or the organization’s priorities shifted underneath the project before it had time to prove itself.
I think this deserves more attention than it gets, because everyone in a technology evaluation spends their energy stress-testing the hardware and the software, and almost nobody stress-tests the organizational side of the plan, even though that side fails more often.
Every deployment I have seen succeed had one person who understood the problem well enough to keep pushing it through the inevitable friction of getting a new system adopted. And every deployment I have seen quietly die had that same thing happen: that person moved to a different role, a different department, or a different company, and nobody fully inherited their context. The system kept running. The champion was gone. Within a matter of months, the project was effectively orphaned, still technically live, nobody advocating for it, no plan to expand it or fix its rough edges.
This is not a reason to avoid building anything, because every project needs a champion at the start regardless. It is a reason to build a little bit of succession into the plan. Document the reasoning, not just the configuration. Get a second person inside the organization who understands why the system exists, not just how to operate it, so the project survives one personnel change without losing its reason for being.
The second pattern is quieter and, I think, more common. A system gets installed correctly, tested correctly, and handed over to the team that is supposed to use it every day, and that team never fully changes its habits. The tags get applied inconsistently. The handheld sits in a drawer more than it gets carried. The data slowly stops reflecting reality, not because the technology failed, but because the daily workflow around it never actually changed. I have seen this happen even when the system worked exactly as intended from a technical standpoint. Getting a piece of hardware installed and getting a team to build a new habit around it are two different projects, on two different timelines, and treating installation as the finish line is how the second one gets skipped.
The honest fix here is unglamorous. It is training that continues past the first week, a clear owner on the floor who is accountable for the habit sticking, and an early, deliberate look at whether the data being collected actually looks right, because if it does not, that is the signal the habit never formed, and it is far cheaper to catch that in month two than to discover it in year two when someone finally asks why the reports have not matched reality for a long time.
The third pattern is the hardest to plan around, because it is not really about the project at all. Leadership priorities shift, budgets get reallocated, a reorganization changes who owns what, and a system that was working fine simply stops being anyone’s job to maintain or expand. I do not think there is a clean technical fix for this one. What I have seen help is keeping the original business case, in writing, short and plain, somewhere it can be found again. When a program comes back into focus after a gap, and it often does, having a clear record of what problem it solved and what it delivered makes it far easier to pick back up than starting the whole justification over from nothing.
None of these three patterns is a knock on the technology, and none of them should be read as pessimism about whether a tracking project is worth doing. They are worth naming because a project that accounts for them going in has a real advantage over one that only accounts for the hardware.