Somewhere in your organisation there is a spreadsheet.

It tracks changes in flight, or which parts are really released, or what the supplier was last sent — pick your organisation's version. Someone maintains it carefully. It is more current than the PLM system for the specific question it answers, and everyone who needs that answer knows to ask its owner rather than open the platform you paid for.

The standard response is to call this an adoption problem and address it with training and a reminder from management about using the approved system. That response fails reliably, and it fails for a reason worth understanding: the spreadsheet is not a discipline failure. It is a requirements document.

Nobody maintains a parallel system for fun. It costs its owner real time. It exists because it answers a question the official system does not, and the person maintaining it has judged that cost worth paying. That judgement is information you are not getting any other way, because nobody files a ticket saying "the system cannot tell me what is waiting on me" — they just quietly build something that can.

The four things workarounds are usually telling you

"I cannot see what is waiting on me." By far the most common. The system holds the data but offers no view answering the one question a person has every morning. The workaround is a personal list. The fix is a view, and it is usually a day's work.

"Getting the answer takes too many clicks." The information exists but extracting it means four screens and a mental join. Anything performed daily that takes more than a few seconds will be cached in a spreadsheet, because humans optimise their own workflow whether or not you approve.

"The process does not match how the decision is actually made." The workflow says three approvals in sequence. Reality is that two people decide together in a five-minute conversation and the third has never rejected anything. So the decision happens in the conversation and the system is updated afterwards, as a formality. Covered at length in the change process paper — the workaround is a symptom, the ceremonial approval is the cause.

"I could not get access and I needed it today." So a colleague emailed the file. Now a controlled document exists as an uncontrolled copy. This is the failure mode discussed in the permissions paper, and it is the most damaging of the four, because it converts a security control into a security hole while leaving the system reporting full compliance.

Notice what none of these are: laziness, resistance to change or insufficient training. Every one is a rational response to a real gap.

How to find the workarounds

They will not be reported, so asking "is anything wrong with the system?" returns nothing. People have adapted, and adapted friction stops registering as friction.

Three techniques that do work:

Ask what they have open. Not "do you use spreadsheets" — ask someone to show you the windows they have open on a normal working day. The shadow system is usually the second or third one.

Watch a real task, silently. Ask an experienced user to do something real while you say nothing. Watch for the hesitations, the second window, the moment they say "you just have to know that this one is different." Every one of those is a defect that will never appear in a ticket queue.

Ask the leavers. Anyone who stopped using the system will explain why in one sentence, and it is usually the sentence you most need to hear.

Then ask the owner of each workaround one question: what does this let you do that the system does not? They will have a precise answer, because they built the thing.

The trap: automating the workaround

Once you find a spreadsheet, the tempting move is to rebuild it in the platform — same columns, same layout, now official.

Sometimes right. Often it copies a structure that exists because of the spreadsheet's limitations rather than the business need. Ask what question it answers before you replicate its shape. "Which changes are waiting on me" is a requirement. A grid of forty columns is one person's way of answering it with the tools they had.

The other trap is the opposite: banning the spreadsheet without closing the gap. That does not eliminate the shadow system, it drives it somewhere you cannot see. The next version lives on someone's personal drive and you have lost your best diagnostic instrument.

Fix the top three, publicly

You will find more gaps than you can close. Rank them by how many people are paying the tax, close the top three properly and — this is the part that gets skipped — tell people you did it, and say what prompted it.

"You told us finding your own open changes was painful. Here is the new view."

That sentence does more for adoption than any training programme, because it demonstrates the thing users have usually stopped believing: that reporting a problem leads to the problem being fixed. Once people believe that, they start telling you about the next one instead of quietly building around it — and you gain a feedback loop that keeps working long after any rollout communications plan has been forgotten.

The measure that matters

Login counts tell you nothing. People log in and then go to the spreadsheet.

Better questions, none of which need a dashboard:

  • How many parallel trackers exist, and is the number going down?
  • When someone needs an answer urgently, do they open the system or message a person?
  • Is the emergency route used routinely? If a third of changes are emergencies, the standard route is too slow and everyone has quietly agreed to bypass it.
  • Do new joiners get told "the system says X but really we do Y"? That sentence is how a workaround becomes permanent culture.

A PLM system is working when it is the fastest way to get the answer. Not the mandated way — the fastest. Until it is, people will keep routing around it, and they will be right to.

Working paper. If you have a shadow system you would rather understand than outlaw, get in touch.