Opinion · An editorial recommendation
Why a workaround survives
The temporary fix is now eligible for long-service leave. The joke is familiar because a workaround can quietly become part of normal operation: a spreadsheet bridges two systems, a scheduled script repairs an import, or somebody restarts a service every morning.
A workaround may be a sensible response to an immediate problem. The useful question is what makes it acceptable to keep using it. If nobody has recorded the dependency, measured the cost or decided when to replace it, its lifespan is being determined by whoever notices it fail.
Describe what it is doing
Write down the original fault, the workaround and the effect of stopping it. Name the services and people that depend on it. Someone reading the record should be able to distinguish an inconvenient manual step from a control that is preventing an outage or a data error.
For example, a fictional order import might need a daily manual reconciliation after its connector fails. Record which orders are compared, how duplicates are identified and who checks the result. “Run the usual spreadsheet” leaves the most important knowledge outside the record.
Give it an owner and a review trigger
Name the person responsible for operating the workaround and the person who can decide its future. Set a review date, but also specify events that bring the review forward: a volume increase, a failed check, a supplier update or the departure of the only operator.
A review date is not a command to remove the workaround regardless of the consequences. It is a point at which someone must choose to repair the underlying fault, replace the workaround, accept it as a supported process or stop the affected service. Record the reason if continued use is the decision.
Measure the cost of keeping it
Count the time spent operating and checking it, including cover during leave and recovery when it fails. Note which errors it can detect and which it cannot. These observations give a replacement proposal something more concrete than frustration.
If the order reconciliation takes twenty minutes every working day, record that effort over a representative period rather than inventing a yearly saving. A replacement may still need reconciliation, training and support. Compare the total work under both arrangements.
Define a safe way to retire it
Agree evidence that the replacement works before withdrawing the old process. For the import example, use approved test orders, check totals and exceptions, and confirm who investigates a mismatch. Identify any steps that cannot be undone and who may authorise the cutover.
Keep a rollback option where one is technically possible. Do not run two write paths in parallel unless duplicate handling has been designed and tested. Remove obsolete schedules, access and instructions when retirement is complete, then ask the service owner to confirm the resulting process.
A useful record for this week
Choose one workaround and document: original problem; current steps; operator and deputy; checking method; known limitations; review date; retirement condition. Put the record where the team already manages service work.
The aim is to make continued use an informed decision. Sometimes that decision will be to keep a small, well-supported process. Sometimes the record will finally explain why a replacement deserves funding.
Something needs correcting?
Get in touch to explain which claim needs attention and share the supporting source.