A technician has tested and confirmed a theory that a failing uplink in the outpatient annex is caused by a bad fiber patch cord. What is the next correct step in the troubleshooting methodology before the fix is actually applied?
Select an answer to reveal the explanation.
Short Explanation
Knowing the cause isn't the same as knowing how to fix it safely. Once your theory checks out, the next move is building a plan: what you'll change, when, and how you'll back out if it goes sideways. Only after that plan exists do you actually touch the fiber.
Full Explanation
After a theory is confirmed, structured methodology calls for a plan of action to be established before implementation: this covers the specific steps to take, the timing of the change, potential side effects, and a rollback path if the fix does not resolve the issue. On a hospital campus, this step matters because even a single annex uplink can carry traffic for biomedical devices, so an uncoordinated swap risks an unplanned outage during a bad moment. Replacing the patch cord immediately skips this planning step and, on a live production link, bypasses the kind of change coordination that a healthcare environment generally requires. Documenting the completed resolution is a later step in the process, one that only makes sense once the fix has actually been implemented and validated, not before. Asking end users to verify restoration is part of validating the resolution, which also comes after implementation, not before a plan exists. A useful operational check at this stage is confirming whether a maintenance window or change approval is needed before the physical swap, since that requirement is exactly what a plan of action should capture.