Every Friday, an operations team exports account data, places it in a spreadsheet, and asks two managers to sign it. The spreadsheet was introduced when two systems could not reconcile automatically. The integration has since been replaced, but the export and approvals continue.
A new manager proposes removing them. Finance objects because the spreadsheet is used during month-end review. A support lead points out that it is also the only place certain exceptions are recorded. The original reconciliation problem may have disappeared, while other work has become attached to the same routine.
Calling this a vestigial process can help identify an inherited arrangement whose role needs examination. It should not settle the examination in advance. The biological comparison is a metaphor; the organisational question is which functions the routine performs now, whether those functions remain necessary, and how they can be supported more effectively.
Observe the routine people actually perform
Begin with a few real instances, including an ordinary week and a week with exceptions. Identify who creates the spreadsheet, what the managers inspect, which changes follow, and who uses the result afterwards. The procedure’s title may describe only its original purpose.
A signature can mean several things. One manager may check totals, another may simply acknowledge receipt, and a third person may interpret the same signature as approval to close a case. Clarify those meanings before deciding whether the approval is redundant or important.
Feldman and Pentland’s work on organisational routines distinguishes the general account of a routine from the particular actions through which it is performed. Their theoretical argument treats routines as possible sources of change as well as stability. It cautions against inferring the whole function of a process from its formal description.
For the Friday spreadsheet, compare written instructions with what staff actually do. The automated reconciliation may have replaced one task while leaving exception handling informal. Removing the spreadsheet could then expose a gap that was hidden by its outdated label.
Separate the original purpose from current dependencies
The historical question is why the routine was introduced. The current design question is which outcomes still depend on it. These questions inform each other without being interchangeable.
The archaeology of organisational decisions can reveal the old integration constraint and any recorded condition for retirement. The present review still needs to identify finance’s month-end use and support’s exception record. A routine can lose its original justification and acquire a different useful role.
Map those uses with their owners:
| Part of the routine | Current use to establish | Possible consequence of removal |
|---|---|---|
| Exported totals | Comparison with the integrated reconciliation | Loss of a distinct check, if one exists |
| Manager signatures | Decision, verification, or acknowledgement | Unclear authority or a missing control |
| Exception notes | Tracking unresolved cases | Cases disappear from the follow-up route |
| Archived file | Evidence used by a later process | Later users cannot reproduce the relevant account |
These are questions for investigation, not assumed benefits. Finance may discover that its month-end work already uses the authoritative system and no longer needs the export. Support may need an exception register but not the duplicate totals or two signatures. Breaking the routine into functions makes those differences visible.
Count the effort and delay as well. Include preparation, chasing approvals, correcting mismatched copies, and work deferred while the file waits. A routine’s usefulness does not establish that its current form is the best way to provide that usefulness.
Identify who notices a failure of each function. If support discovers lost exceptions but finance owns the retirement decision, support needs a route to challenge the proposed design with evidence. If the spreadsheet’s preparer also performs undocumented checks, observe those checks before estimating the effort saved. The work attached to a routine can exceed the work visible in its official sequence, which affects both the replacement requirement and the claimed benefit.
Design a replacement around the functions still required
If the integrated system performs reconciliation adequately, the duplicate manual comparison may be removable. If unresolved exceptions still need an owner and status, move that function into a maintained queue or register. If a consequential decision needs approval, specify what the approver must establish and when their decision takes effect.
Avoid migrating every field and signature into a new tool merely because they exist in the spreadsheet. That can make an inherited process faster to execute while preserving requirements nobody has examined. Each retained step should have a current purpose and a reason for its place in the sequence.
An AI assistant could help identify recurring exceptions or prepare supporting material. Evaluate whether it improves the required check. A generated summary does not independently establish that the totals are correct, and an automated approval message does not clarify an ambiguous decision right.
Keep different functions distinguishable even if one interface supports them. Acknowledging that a report was received is different from verifying its contents. Closing an exception is different from approving a policy deviation. The record should say which action occurred and who was authorised to perform it.
HSE’s guidance on plant modification and change procedures calls for traceable review of changes in its industrial safety setting. A business routine is not automatically subject to those requirements. The transferable practice is to understand the effects of a change, including removal, before assuming that an apparently minor edit affects only the step being deleted.
Make the retirement a controlled operational change
Define what would demonstrate that the new arrangement works. For the Friday routine, the review might require unresolved cases to remain visible, the relevant comparison to be reproducible, and necessary decisions to occur before the actions they govern. Those conditions provide a basis for assessing the change.
Choose a proportionate trial. A read-only comparison or replay of representative weeks may establish some properties without running two live decision paths. If a limited parallel run is necessary, specify which path is authoritative and when the duplicate work will end. Otherwise the trial can become another permanent layer.
Include unusual cases. An ordinary week with no discrepancies says little about exception handling. Test a late correction, an unavailable approver, and a case still open at month end. Follow each through the downstream work that previously depended on the spreadsheet.
Record what happens if the replacement fails. The fallback should address the relevant missing function rather than automatically restore every old step. A reconciliation problem may justify a targeted temporary check, while a queue outage may need a way to record and recover unresolved cases.
Assign ownership after retirement too. Someone needs to review the first affected cycles and respond to evidence that a dependency was missed. Feedback failure in expertise is relevant when teams complete a change but never connect its later consequences to the reasoning that justified it.
Agree how the released capacity will be used. Staff who stop preparing duplicate totals may still need time to investigate the remaining exceptions or maintain the new register. Account for those tasks when reporting the net improvement. This also makes it easier to distinguish a replacement that genuinely reduces work from one that relocates it into less visible activities.
Retirement should include the instructions people encounter. Remove or mark obsolete the old template, update references, and tell downstream users where the necessary information now lives. Leaving an old form accessible without a clear status can encourage well-intentioned staff to restart the retired routine.
Leave a reason for the new arrangement to exist
Document the functions retained, the evidence supporting removal, unresolved limitations, and the conditions for review. Preserve an explanation of the old routine without presenting it as a current requirement. Decision-record guidance from AWS offers a pattern for making supersession visible rather than silently replacing the historical account.
Put an owner and review trigger on temporary replacements. A check introduced during a migration should identify what needs to become true before it can end. If the condition is never evaluated, the next team may inherit another unexplained procedure.
Do not measure the exercise only by steps removed. The relevant outcomes include effort, delay, error detection, unresolved cases, and the reliability of the surviving process. A shorter workflow can be worse if it hides exceptions, while a retained control may be worthwhile when its contribution is clear and its cost proportionate.
The reverse is also important: uncertainty about a routine’s history is not sufficient reason to preserve it forever. If present uses have been examined and required outcomes can be supported through a better arrangement, the organisation can make an explicit current decision. Record the remaining historical uncertainty without allowing it to substitute for present responsibility.
A successful retirement makes the work easier to explain. Staff know which checks remain, which decisions they support, where exceptions go, and why duplicate steps ended. The organisation retains useful functions while removing forms of work whose contribution can no longer justify their continuing cost.
