Repair a repetitive office task when its business purpose is still valid and the defect is narrow, replace it when the purpose remains but the design no longer meets the need, and retire it when the outcome is no longer required. The decision should come from evidence about the process, not loyalty to the current tool or frustration after one bad run.
Confirm that the task still has a purpose
Write the task's intended outcome in one sentence. Identify the customer, employee, record, or decision that depends on it. Then measure recent volume, completion time, correction time, failure rate, and the impact of late or wrong output. If nobody can explain who uses the result, pause the process and verify demand before spending time on repairs.
A temporary failure is not automatically evidence that the whole task should be replaced. Separate an isolated credential expiration, bad input file, or changed field name from a recurring design problem. Keep a short history of incidents and changes so the decision is based on a pattern.
Repair when the baseline remains sound
Repair is appropriate when inputs and outputs are still correct, ownership is clear, the tool remains supported, and the fault can be isolated and tested. Examples include updating a filter after a documented data change, correcting a schedule, or replacing an expired connection. Record the previous setting, proposed fix, expected result, test sample, approver, and reversal step.
NIST's configuration-management guide explains the value of an approved baseline and controlled changes that are analyzed, tested, approved, implemented, and verified. For a small office process, the practical version is simple: know what “working” looked like, make a traceable change, and prove that the result matches the expected output.
Replace when the method has become the constraint
Replacement is justified when repairs repeatedly fail, the tool is unsupported, required security controls are unavailable, the process cannot handle current volume, data cannot be exported reliably, or review effort exceeds the benefit. Compare alternatives using the same real sample, including the existing manual method. Measure output accuracy, operator time, access controls, portability, failure visibility, and total switching effort.
Plan coexistence instead of a sudden cutover when the task affects money, customer messages, access, or official records. Run old and new methods in parallel on a safe sample, compare results, and define a rollback point. Preserve source records until the replacement is verified.
Retire when the outcome is no longer needed
Retirement is not merely turning off a schedule. Confirm downstream dependencies, notify the owner, export records that must be retained, remove credentials and unnecessary permissions, disable triggers, and update documentation. Keep the final successful output and the retirement approval where future reviewers can find them.
NIST's contingency-planning guide recommends evaluating systems and operations to set recovery requirements and priorities. Apply that principle before repair or replacement: decide how long the task can be unavailable and what manual alternative can sustain the business. A low-impact task with a reliable manual fallback may not justify a costly rebuild.
Make the decision reviewable
Use a one-page decision record: purpose, current owner, recent incidents, measured burden, risk if stopped, repair estimate, replacement estimate, manual fallback, selected action, approver, and review date. Avoid pretending the estimates are exact. State assumptions and the evidence still missing.
The strongest choice is the least complicated option that preserves the required business outcome at acceptable risk. Repair the narrow defect, replace a method that has become structurally unsuitable, or retire work that no longer creates value.
Sources
- SP 800-128: Guide for Security-Focused Configuration Management of Information Systems — National Institute of Standards and Technology, Oct. 10, 2019
- SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems — National Institute of Standards and Technology, May 1, 2010