When Employees Break the System, That's a Requirements Document

There is a sticky note on the monitor of almost every nurse I have ever seen in a hospital setting. Sometimes it has a password. Sometimes it has a short sequence of clicks that gets around a menu the system designer thought was logical but nobody who actually uses the system agrees with. The note is not incompetence. It is documentation.

Ferneley and Sobreperez (2006) gave a name to this behavior: the workaround. They defined it as a practice in which users circumvent an information system in order to accomplish a task the system was supposed to support. And they made an argument that I think most IT governance people are not ready to hear: workarounds are not evidence of user failure. They are evidence of system-task misfit. When someone builds a procedure around the edges of the system instead of through it, they are telling you something the requirements document missed.

The paper identifies three types. Working around means bypassing the system entirely for a specific task, doing the work by other means. Working with means using the system in a way its designers did not intend, bending it to fit the actual task. Working through means accepting the misfit and absorbing the cost, doing the work in the inefficient way the system requires. The third type is the one that hides. Nobody complains about it. It just makes everyone's job slightly harder every day, invisibly.

Alter's work system theory provides the frame that explains why misfit happens in the first place. Alter argued through his papers from 1999 through 2013 that a work system includes processes, participants, information, technologies, customers, products or services, environment, infrastructure, and strategies. Technology is embedded in the work system, not separate from it. When a new system is implemented, the question is not whether the software works. The question is whether the software works for the participants, with their information, doing their actual processes, in their actual environment. When the answer to that second question is no, people do not stop working. They find another way. The work system continues. The official system gets bypassed.

I think this is why most post-implementation reviews miss what actually happened. The review asks: did people adopt the system? And the answer is yes, login rates are high, compliance is documented, the project is marked successful. But what the review does not ask is: are there sticky notes on the monitors? Is there an Excel file that the team uses instead of the reporting module? Is there a WhatsApp group that carries information the system was supposed to carry? If you go looking for those things, you find the real requirements document, written in behavior rather than specification.

The examples I keep running into are not exotic. Nurses using personal phones because hospital paging systems have latency that is genuinely dangerous in an urgent situation. Employees creating personal Dropbox folders because the corporate file sharing system is too slow to be usable. Developers running GitHub Copilot on personal machines because the IT procurement process for approved AI tools takes six months. The common thread is not laziness or policy ignorance. It is that the official system cannot do the work at the speed or flexibility the work requires, and the work has to get done anyway.

The shadow IT framing matters here. Most organizational IT governance treats shadow IT as a security risk to be eliminated. Find the unauthorized tools, remove access, enforce policy. I understand the security case. Unauthorized tools create real risks: data leaving the perimeter, version control failures, compliance violations. But treating shadow IT purely as a risk means treating the symptom without understanding the cause. If employees are using personal ChatGPT accounts because the approved corporate AI assistant has so many restrictions it is not actually useful for their work, removing personal ChatGPT access does not solve the misfit. It just makes the misfit invisible again.

My read is that shadow IT is one of the most efficient diagnostics available to an IT organization. The patterns tell you where the misfit is worst. They tell you which tasks the official system handles poorly. They tell you what capabilities users actually need versus what the requirements document said they needed. Ferneley and Sobreperez's contribution is to provide a vocabulary for reading that diagnostic. Working around is a loud signal: the system cannot do this at all. Working with is a quieter signal: the system can do this, but not the way the work actually goes. Working through is the silent signal that is easiest to miss: the system is making this harder than it should be, and people have given up complaining about it.

What this means in practice, I think, is that any system implementation that does not build in a systematic method for discovering and studying workarounds is missing its own most important feedback loop. The post-implementation review should include observation, not just surveys. Go sit with the people who use the system. Watch the full workflow. Count the clicks that go outside the system. Ask about the sticky notes. If you do that honestly, you get a picture of what the system actually does in the work system, not what the project plan said it would do.

Work system theory is useful for exactly this reason. It forces the analysis out of the technical layer and into the layer where work actually happens. A system that works technically but does not fit the processes, participants, information, and environment of the work system is a system that produces workarounds. The workarounds are not a bug in the users. They are a diagnostic about the design.