Routine Dynamics and Why Processes Keep Reverting to the Old Way

Six months after a major ERP go-live, a process analyst at a manufacturing company spent a day watching how the purchasing team actually used the new system. What she found was that the team had spent the previous six months building an elaborate workaround. They were entering data into the ERP because they had to, but they were still maintaining the old Excel-based tracking sheet in parallel. The official process, the one in the training materials and the SOP, showed a clean digital workflow. The actual process included the ERP as a compliance step followed by the real coordination happening in a spreadsheet. The go-live had succeeded. The process had not changed.

This is not an unusual story. And Feldman and Pentland's work on routine dynamics explains why it keeps happening, even in organizations that did everything right in implementation.

The distinction that matters is between what they call the ostensive routine and the performative routine. My study-hub sources do not contain the Feldman and Pentland (2003) paper directly, so what follows draws on my understanding of the broader organizational theory literature, which consistently describes their framework this way. The ostensive routine is the abstract idea of how a process works: the documented procedure, the flow chart, the training manual, the workflow built into the system. The performative routine is what people actually do when they execute the work on a particular day, with particular constraints, particular coworkers, and particular pressures. The two are related, but they are not the same thing, and they routinely diverge.

The reason they diverge is that performative routines are local, adaptive, and tied to the specific circumstances of execution. When a purchasing agent encounters a vendor situation that does not fit the standard case, she adapts. When a workaround saves ten minutes and the standard process wastes them, the workaround becomes the performative routine. When the new system cannot quickly reproduce a capability the old system had through a shortcut, the team finds a way to get the result outside the system. None of this is malicious. It is how organizational work actually happens. People optimize locally, and local optimization diverges from the designed process.

The IS implementation problem is that most measurement of "system adoption" is really measurement of the ostensive routine, not the performative one. Clickstream data shows that users logged in and navigated to a particular screen. Usage counts show how many transactions were processed through the system. These measures capture compliance with the surface of the process. They do not capture what is happening in the margins, the parallel spreadsheets, the email chains, the messenger threads where the actual coordination is occurring alongside or instead of the system.

I have seen this framed as a user behavior problem. The more useful frame is that routines have their own dynamics that are separate from the technology they are embedded in. Feldman and Pentland's contribution, as I understand it, was to show that routines are not just stable patterns but active performances. Each execution of a routine is a fresh performance that can reproduce the pattern or slightly vary it. The variations accumulate. Over time, the performative routine drifts from the ostensive one, and the drift is not visible unless someone actually watches the work happen rather than reading the process documentation or the clickstream data.

This has a specific implication for how IS researchers should think about measuring implementation success. If you measure the ostensive routine, through system logs, process documentation, and compliance checks, you get one picture. If you measure the performative routine, through direct observation, shadowing, or qualitative interviews about how work actually gets done, you may get a very different picture. A system can score high on every clickstream adoption metric while the actual business process is still running on Excel.

The practical implication for implementation design is about what happens after go-live. Most implementations concentrate resources in the period before and immediately after cutover. The assumption is that once users are trained and in the system, the work is done. But from a routine dynamics perspective, the interesting period is the months after go-live, when the team is adapting the performative routine to the new context. If there is no mechanism for surfacing those adaptations, some of them will be improvements that should be incorporated into the process design, and some of them will be workarounds that undermine the goals of the implementation. Without visibility into the performative routine, you cannot tell which is which.

There is also a design implication for IS researchers working on process change studies. Observing the ostensive routine, reading the SOP, interviewing managers about how the process is supposed to work, tells you what the organization says it does. Observing the performative routine requires watching people work, which is slower and harder to scale but captures something fundamentally different. The two produce different data and should not be treated as interchangeable sources of evidence about what a system implementation actually changed.

Gartner research on digital process improvement consistently notes that process adherence tends to degrade over time after initial implementation without reinforcement and feedback mechanisms (see Gartner newsroom). From a routine dynamics perspective, degradation is the wrong frame. What looks like degradation is often the performative routine reasserting itself, which is not a failure of discipline but a natural consequence of how routines work. The question is whether the organization can see it and respond to it, or whether it only sees the ostensive routine and thinks everything is fine.

The workarounds in that manufacturing company's purchasing team were not evidence that the implementation failed. They were evidence that the implementation changed what people had to do while leaving much of what they actually did intact. Those are different things, and confusing them is probably why so many IS implementations report high adoption rates and modest operational improvement.