The unofficial tracker is already architecture
The company bought the platform. The workflow still lives in a file.
Someone stood up a tracker because the official system did not cover the exception, the handoff, or the Friday job that has to finish. It was supposed to be temporary. It is not. People copy it, wait on it, and treat the number in it as true. If it disappeared on Tuesday, work would stop.
That is not a workaround anymore. That is a spreadsheet as a system of record.
A shadow process is a system you already have
A shadow process is not a messy habit sitting next to the real stack. It is the stack the company actually runs.
SpirZon, in a WIPFLI-style shadow-process frame, describes unofficial workflows that survive outside enterprise systems, often in spreadsheets, email chains, or manual trackers. They persist "not because employees love spreadsheets, but because the official systems failed to fully solve the real work."
The file is not a rejection of the platform. It is the adaptation. When a spreadsheet becomes a database, the purchased system is the copy.
We already wrote about why context-right beats vibe-coded and about the last mile after the demo. This is a different chapter. Not the prototype that looks finished. Not the finish after go-live. The unofficial tracker the week already depends on.
A one-screen test
Ask this on one screen. No workshop required.
- What process stops if this file disappears?
- Who is allowed to write to it?
- Whose decision depends on the number in it?
- If the person who built it left tomorrow, could anyone else run the week?
If the answers are the operation, one person, a real decision, and no, the workaround became the system. You do not have a temporary tracker. You have a database with worse manners: no access control worth the name, no history you can trust, and a formula nobody wants to touch.
Do not ban the spreadsheet
Banning the file does not recover the process. The file exists because the work needed somewhere to live. Take it away and the work finds another inbox, another shared drive, another side tracker.
The move is not governance theatre, and it is not another package that still misses the exception (what off-the-shelf cannot see). Encode the real process: the columns, the tacit rules, the Friday case, who actually owns the write. Then put that in software that fits this company.
Custom software is that encoding. Consulting is the map of the job the file is doing before anyone commissions a replacement. Skip the map and you rebuild the same gap with a nicer interface.
What a replacement has to capture
A replacement that copies the columns and drops the exception path is a second unofficial system. People will keep the spreadsheet.
Capture at least this:
- The job the file actually does, not the job the org chart says it does
- Who may write, who may read, and what happens when two people edit the same row
- The exception the official system still cannot hold
- The handoff: where the number goes next, and who is waiting on it
- What must still be true if the original author is gone
If those are not in the replacement, the shadow process will sit down next to it.
When the person who built it leaves
Often only one person knows which tab is live, which formula is load-bearing, and which version to ignore. When they leave, the company inherits a process it cannot explain and cannot run.
That is the moment to encode, not the moment to hope a generic tracker absorbs the logic. Software that fits this company is the version of the file that other people can operate.
If the unofficial tracker is already the system, talk to us about encoding it. Do not add another package beside it.
Questions
When is a workaround actually the system?
When the company cannot run the week without it. When writes happen there, decisions depend on it, and the official platform is the copy.
Should we ban the spreadsheet?
No. A ban does not recover the process. Find the job the file is doing that the purchased stack still does not do. Encode that.
What must a replacement capture?
The real job, write ownership, the exception path, the handoff, and enough of the tacit rules that the original author is not the only person who can run it.
What happens when the person who built it leaves?
The company is left with a file it depends on and cannot maintain. Encode the process while they are still here.