IT Problem Management: Finding the Root Cause Instead of Fixing Symptoms

IT problem management investigates recurring faults or a single serious incident, and also looks for likely causes before an outage occurs. For a UK small business, failed booking confirmations or an early storage warning can be enough to start. The work ends when agreed evidence shows whether a change helped.

Keep incident evidence, assign an investigator and distinguish service recovery from prevention.

Understand the incident, the problem and the lifecycle

An incident is an unplanned interruption or reduction in service quality. It might be reported by a colleague, discovered through monitoring or noticed as a transaction that has become unusually slow. Restoring that service is the immediate job. A problem is a cause, or potential cause, of incidents, including a cause discovered before anyone is affected.

Restarting an application might clear a stuck queue and restore booking confirmations. If the worker that should empty that queue keeps stopping, so jobs pile up unprocessed, the restart is a workaround. The investigation concerns why the worker stops and how to deal with that condition.

PeopleCert's ITIL guidance, checked on 8 November 2026, identifies ITIL (Version 5) and says its management practices remain largely the same. The process detail used here comes from Atlassian's Jira Service Management problem-management process, written for ITIL 4, which covers linked incidents, root causes, workarounds, known errors and changes.

The ITIL problem management practice uses three phases: problem identification, problem control and error control. Identification means finding and prioritising a recurring or emerging risk. Control means investigating the cause and recording a usable workaround; error control means managing the analysed fault, implementing a suitable change and checking whether it worked. A restricted document can track this work.

A fault can have several contributing causes. Separate suspected causes from evidence-backed findings.

Recognise related incidents without merging unrelated faults

Descriptions rarely match neatly. One person reports a slow booking page, another sees a failed confirmation, and monitoring shows an unusual queue. They may or may not share a cause.

Use support emails, monitoring alerts, supplier notices and staff reports as starting points.

1. Describe what happened. Record the affected activity, what the person or system attempted, the observed failure and the business effect. Keep the report in the person's own words and record any technical interpretation separately; ask them only when something is unclear.
2. Capture the circumstances. Note the event time, affected account or location, and any recent changes. Compare logs or alerts and mark any missing evidence.
3. Look for genuine matches. Compare the service, failure behaviour and conditions. Also look across different services for a shared dependency such as DNS, sign-in, hosting or the office network. Check the original records before grouping them.
4. Open a problem record. Give the suspected issue an owner, an impact statement, linked incident references and a next review point. For a serious or risky fault, ask a second person with the right knowledge to check the grouping where one is available.
5. Preserve a useful baseline. Save relevant errors, monitoring observations and supplier replies before making changes. Verify authorised staff can read it without exposing confidential material.

Times need care. Note whether each system records UTC or local time, account for daylight saving and clock drift, and flag rotated or missing logs. Where a request or correlation ID exists, use it to match events across systems instead of relying on a timestamp alone.

There is also a proactive route. A growing disk-space warning or a supplier security notice can justify investigating a likely failure before there is an incident. Confirm it applies to your system, investigate the dependency and verify any remedy clears the warning without affecting other services. A notice about an actively exploited vulnerability is different: escalate it at once for containment or an urgent update.

Decide which investigation comes first

Frequency matters, but it cannot determine priority alone. Use this practical order of questions: how seriously is work disrupted, could information or transactions be lost, how urgent is the exposure, how risky is the available workaround, and how often does the fault happen? The potential impact of silent lost enquiries may outweigh a frequently failing printer with a safe alternative.

Record why one investigation takes priority. Payroll access, a broken order process or unexplained missing records may demand earlier attention than a nuisance which staff can avoid safely. If the fault appears to belong to a supplier, collect a local timeline and compare it with supplier notices rather than changing unrelated settings.

Name an owner for each active investigation and agree when its priority will be reconsidered.

Investigate a cause that can be tested

Root-cause analysis starts with a question: what condition needs to exist for this failure to appear? Evidence must support the explanation and proposed action.

Build a timeline from available evidence

Place the last known working event, the first failure, relevant changes, recovery actions and later recurrences in order. Use application logs, monitoring and supplier records where they exist. A preceding change is a clue, not proof.

Compare a failing request with a successful one under similar conditions, or an affected account with an unaffected account. Keep originals separate from summaries. If logs include personal information, restrict access and remove unnecessary identifiers from summaries shared with others.

Use the 5 Whys technique carefully

Start with the observable symptom and repeatedly ask why it happened. Each proposed answer should carry a matching observation and a question that could disprove it. If the answer is "the server was busy", establish what was constrained and whether that constraint coincided with the incident.

The 5 Whys technique is useful for a straightforward chain, but a complex outage may involve several contributing causes. List those factors and examine how they interacted instead of forcing everything into one chain. A login failure, for instance, could involve a saved credential, an account lockout or an unavailable identity service; the affected scope and authentication records help distinguish them.

Test without putting live work at risk

Use observation and reversible checks before changing a production service. Reproduce the failure in a suitable test environment with non-sensitive information where possible. When reproduction requires a risky live change, preserve the evidence and obtain authorisation from the service owner before continuing.

Record the hypothesis, the result expected if it is correct and an outcome that would reject it. Compare the diagnostic result with a known working case so a faulty test setup does not become a false diagnosis. Stop if the next experiment threatens orders, customer data, access controls or continuity; keep the safe workaround in place and involve someone with suitable access.

Worked example: booking notifications that sometimes fail

Imagine a business whose website stores bookings but intermittently fails to send confirmations. Staff can resend a message, yet customers may still be unsure whether a booking exists.

First establish whether an application booking record was saved, a notification job was created and the delivery provider accepted, rejected or retried the message. Each stage is separate: the application submitting the message, the provider accepting it, the recipient's mail server accepting it and the message reaching the inbox. Use authorised records without circulating customer details.

Suppose bookings are saved while some notification jobs remain pending. One hypothesis is a stopped worker; retry delays, rate limits, scheduling errors and failed authentication can leave jobs pending too. The questions are which component processes them, what state they are in and whether the failures correlate with a change or external interruption. Before a manual resend, inspect the original message's accepted, delivered and retry status and check for an existing duplicate. Where the system keeps no message-level status, or a retry is still queued, stop or clear the automatic retry first so a manual resend does not race it. Record who resent which message and when, so another member of staff can avoid sending it again.

For verification, use a test account and a slot unavailable to real customers, with payment test mode, sandbox credentials and production notifications switched off, so hooks and background jobs cannot reach real customers or charge a card. Check that the test reaches the expected application and provider states, confirm that normal business actions still work, and remove the test records afterwards under the site's normal data-handling procedure.

If the sending provider accepted the message but it failed later, investigate that hand-off before changing application code. The acceptance criteria must cover the original failure pattern, not merely whether a fresh message can be generated.

Keep one problem record and classify it accurately

A suspected fault with a useful workaround is still an investigation. A known error is a problem that has been analysed but remains unresolved, with the understood failure documented so staff can recognise it and use any safe workaround. Move the record to known-error status after the investigation supports the failure mechanism; do not label an untested guess as established fact.

A small record can hold all the information needed to decide what happens next. For illustration, an unresolved website notification problem might contain these fields:

• Incident references: Links to the relevant failed notifications and their original reports.
• Evidence: Application job states, provider replies and the normalised event timeline.
• Hypotheses: A possible stalled worker, with the finding explicitly marked suspected until checked.
• Owner: The person responsible for the next investigation and its review.
• Priority: The effect on customer confirmations, possible loss and workaround risks.
• Workaround: A controlled resend only after delivery and duplicate checks.
• Next action: Establish whether the responsible worker processed the pending jobs.
• Closure decision: Pending agreed acceptance checks under comparable booking activity.

The actual record should link to original evidence, state who can authorise the workaround and explain when its use must stop. A workaround used during disruption should be written as a tested procedure, including prerequisites, expected results, unsafe conditions and how to undo the action.

Keep the record's status (open or closed) apart from what it holds: whether the cause is still under investigation or is a known error, whether a workaround exists, and whether a named person has accepted the remaining risk with a review date. A known error can carry an accepted risk while it stays open; accepting a risk records a conscious decision to tolerate a remaining cause, and it is not a fix. If the evidence or business exposure changes, reopen that decision.

Apply a correction with a recovery route

A supported cause suggests a corrective action, but changing production can create another outage. A corrected setting or repaired component might remove the cause. Monitoring, warning alerts and containment measures instead detect a recurrence or limit its impact; they are worthwhile controls, but do not automatically amount to a permanent repair.

The Cabinet Office's GOV.UK service-management guidance was written for Public Services Network organisations and their providers. Its change authority, owner, change window and back-out plan are adapted here as safeguards for a small business, not presented as legal duties for that business.

1. Set acceptance criteria first. Describe the condition the change is intended to remove, the activities that must continue working and the observations that would count as success or failure. Confirm those criteria with the person who owns the service.
2. Secure the current state. Check that appropriate backups and configuration copies are available, recovery access works and the restoration method is understood. Pause if a proposed restore could overwrite valid new bookings or customer data.
3. Plan the back-out decision. Keep previous settings or a recoverable deployment, assign someone to reverse the change and state what failure will trigger that decision. Verify the route to restoration before applying anything live.
4. Try the change safely. Where a suitable staging environment exists, test the suspected fault and unaffected business tasks there. If those checks fail, revise the plan rather than proceeding on an assumption.
5. Authorise and carry out the change. Agree a suitable window if service could be disrupted and tell affected staff. Preserve the working configuration, apply the smallest relevant change and inspect service health before making any further adjustment.
6. Check or revert. Run the agreed acceptance checks, including the original failure scenario. If they fail or unrelated work breaks, use the back-out plan and verify that the restored service works; leave the problem under investigation.

A failed change provides evidence about the diagnosis. Record what happened and review the hypothesis before proposing another alteration.

Verify improvement without claiming permanent certainty

A repair passing an immediate test is a promising result, but intermittent faults may require particular activity or external conditions. Agree acceptance criteria before the change, including what will be observed, how it will be measured, the conditions needed and when the case will be reviewed.

For the booking example, examine whether controlled bookings complete their notification jobs, whether previous pending work was addressed and whether comparable real booking activity produces the former symptom. Monitor silent failures as well as complaints, using legitimate operational records rather than creating transactions in live customer slots.

At review, answer these questions:

• Has the same symptom appeared again, or is a new failure being mistaken for it?
• Did the proposed correction remove the supported cause, or merely hide it?
• Were observations made when the original trigger could reasonably have occurred?
• Did ordinary business tasks, security checks and recovery arrangements still behave as expected?
• Can the owner explain the remaining uncertainty and show the supporting evidence?

Choose an observation period that includes relevant business activity. A finite period without incidents cannot prove an intermittent fault will never recur. Record the observations, what the tests covered and the uncertainty that remains; if the trigger has not occurred again, keep monitoring rather than declaring certainty.

When the agreed criteria are met, record the closure decision and retire obsolete workaround instructions. If the original fault returns, reopen the problem, inspect the new evidence and avoid repeating the earlier change without checking why conditions differ. Broader trends and management summaries belong in IT service reporting; this verification record is about the particular cause and its acceptance criteria. For problem management itself, two measures are enough to start: how many incidents repeat a known problem and how many corrective actions are overdue.

Review serious incidents and separate security duties

After a serious interruption, hold a proportionate review even if service was restored quickly. Record the contributing factors, why warning signs went unnoticed, what prevented earlier detection, and the prevention, monitoring and ownership actions agreed. Assign owners and review results.

Escalate immediately if a fault may involve unauthorised access, missing personal data, a compromised device or an unsafe workaround. Preserve evidence and use the organisation's security incident response arrangements instead of experimenting on the affected system. Routine problem management is separate from responding to a security incident.

A personal data breach needs its own assessment. A controller reports a breach to the ICO without undue delay and, where feasible, within 72 hours of becoming aware of it, unless it is unlikely to result in a risk to people's rights and freedoms; a later report gives the reasons for the delay, and details can follow in phases. A processor tells its controller without undue delay. Affected people must also be told without undue delay where the risk to them is high. Document every personal data breach, its effects and the remedial action taken, whether or not it is reported, and seek appropriate advice if the position is unclear.

Before passing a technical fault to an outside provider, establish who owns the affected system, who holds administrative rights, what contracts restrict, how sensitive the data is and what operational risk outside access creates. A supplier should receive the relevant timeline and checks through a secure route, without unnecessary personal information.

Keep the routine workable for a small business

Set a review in the diary, for example a short monthly look at closed incidents and alerts, and open a problem when the same symptom appears twice or one incident caused serious disruption. Each active problem needs an owner, evidence, an identified next action and a review decision. Keep it separate from support requests that were closed after temporary recovery.

Exported logs and supplier cases can contain confidential or personal information. Share them only through an authorised secure route, retain them no longer than the investigation and any applicable retention obligation require, then delete investigation copies when they are no longer needed. Keep a minimal decision record where a lawful record must remain.

If the workaround is hard to find or follow, the guide to IT documentation that people actually read can help make the instructions usable without expanding the problem record into a manual.

Choose one problem to review properly

Start with a recurring fault, a serious interruption or a credible warning, then preserve the evidence and agree acceptance criteria before proposing a change. For a WordPress or custom PHP site, you can ask about help with the technical change through a short call followed by a written quote. When the record closes, file the evidence behind that decision with it, so the next investigation starts from what IT problem management has already proved.