Simple explanation
A structured, repeatable process for solving network problems, rather than randomly trying fixes until something works.
Technical explanation
The standard methodology:
- Identify the problem — gather information, question users, identify symptoms, determine if anything changed recently.
- Establish a theory of probable cause — question the obvious first, but consider multiple possibilities.
- Test the theory to determine the cause — once confirmed, proceed to a solution; if not confirmed, establish a new theory or escalate.
- Establish a plan of action to resolve the problem and identify potential effects — think through what else the fix might impact before applying it.
- Implement the solution or escalate as necessary.
- Verify full system functionality and, if applicable, implement preventive measures — confirm the fix actually worked, and consider whether this can be prevented from recurring.
- Document findings, actions, and outcomes — the step most often skipped under time pressure, but essential for building institutional knowledge and speeding up the next similar issue.
The key discipline: this is a loop, not a strictly one-way path — if testing a theory disproves it, you go back and establish a new one, rather than forcing a fix that doesn't actually address the confirmed cause.
Synonyms / related terms
| Term | Means | |---|---| | RCA | Root Cause Analysis — closely related to "establish a theory of probable cause" | | Escalation | Passing an unresolved issue to someone with more access/expertise | | Change log | Related documentation often referenced during "identify the problem" |
Concept Check
"A technician immediately reboots a router the moment a user reports slow internet, without gathering any other information first." This skips the crucial identify the problem step — jumping straight to a fix (however common a fix rebooting might be) before understanding symptoms, scope, and recent changes risks masking the real cause or fixing the wrong problem entirely, even if it happens to work this time.
Interview-style Q&A
Q: Why does documentation matter as an official step in the methodology, not just a nice-to-have? A: "Because the value of troubleshooting compounds if it's recorded. The next time a similar issue occurs — possibly to a different technician entirely — documented findings can turn a two-hour investigation into a five-minute lookup. Skipping it means every recurrence starts from zero, regardless of how much was actually learned the first time."
Memory trick
"Identify, Theorize, Test, Plan, Implement, Verify, Document" — the seven-step loop, in order — say it as one phrase and the whole methodology comes back intact.