it-problem-root-cause

Start by defining the problem statement with affected service, scope, and time window, then build a normalized timeline from logs and incident records. Separate trigger, direct cause, contributing factors, and control failures, and test each causal claim against evidence before assigning corrective actions.

Focus the analysis on system conditions rather than individuals: identify the design, process, or control gap that allowed an ordinary action to cause failure. Record evidence and counterevidence for each causal link, and avoid labeling human error as a root cause.

Use 5 Whys only as a questioning aid and stop where evidence stops. When the next causal fact cannot be established from available data, mark it as unknown rather than continuing into speculation.

Strong actions change the system, such as adding enforced validation, redundancy, automated controls, or actionable monitoring tied to ownership. Weak actions like "be careful" or "retrain staff" require a measurable control or verification step to count as complete.

Yes, the analysis can be performed on user-provided or authorized exported data such as incident records, logs, and timelines. The output should note data dates, versions, and any scope that could not be verified in real time.

Recurrence usually means the corrective action only added documentation instead of breaking a causal link, or the fix was never verified. Reopen the problem record, evaluate action effectiveness, and confirm the control exists and is tested before closure.