T Level Digital: Problem-Solving Strategies and Root Cause Analysis

The problem-solving content of the Pearson digital T Level cores goes beyond computational thinking. It also asks how a problem is approached as a whole, how the real cause of a recurring fault is found, and what a support team does between the first report of a failure and the lesson it records afterwards. That content is shared by the Digital Software Development, Digital Support and Security and Digital Data Analytics cores, which are assessed through two written papers and an employer-set project; incident management appears in the support and security core in particular.

The quiz has twelve questions set in invented workplaces. Three are calculations: a risk priority number for four failure modes of a warehouse scanner system, where the most severe failure is not the one to fix first; the probability that a hosting service is lost when both a backup battery and a generator fail, worked along one path of an event tree; and what a detection rating of 9 actually means. Others ask you to find the root cause at the end of a five whys chain about a late payroll run, to choose between five whys, FMEA and event tree analysis for a described task, and to decide what happens after the analysis when only a supplier can fix the fault. The rest cover top-down against bottom-up design, the benefit of a stable module interface, the order of the six stages of the problem-solving strategy, and the difference between an incident and the problem that caused it. Each explanation shows the working or the rule and why the tempting alternative is wrong.

The flashcards give the definitions and formulas you need to recall quickly: the three approaches, the three root cause techniques, the risk priority number, how event tree paths are multiplied, the six stages and the three phases of incident management.

The written work has eight tasks to answer on paper: a five whys analysis of duplicate confirmation emails, an FMEA table with three risk priority numbers and a limitation of the method, an event tree with three outcomes that must add up to one, and a walk through all six stages for a Wi-Fi fault. Three are longer, evaluative answers of the kind used for the higher-mark questions on the papers: top-down against bottom-up for a new booking system, modularisation for a team of four, and which root cause technique a small practice should use. Each has a model answer and the points a marker would look for.

There is also a short oral practice with an examiner, who gives every number in the question, asks one thing at a time and gives brief feedback at the end.

  • Choose between top-down, bottom-up and modular approaches and state a benefit and a drawback of each
  • Use five whys to separate a root cause from its symptoms
  • Calculate and use risk priority numbers in a failure mode and effects analysis
  • Calculate the probability of an outcome in an event tree by multiplying along its path
  • Decide whether to log, close or escalate after root cause analysis
  • Apply the six stages of the high-level problem-solving strategy in order
  • Distinguish an incident from a problem and describe the detection, response and intelligence phases

Practice material written by Zestly, based on the core content of the Pearson T Level Technical Qualifications in Digital Software Development, Digital Support and Security and Digital Data Analytics (first teaching September 2025), content area 1.3: problem-solving strategies, root cause analysis and, in the Digital Support and Security core, incident management.

Sample question

The payroll run at Hebden Mills, an invented manufacturer, finished a day late. The IT team asks 'why?' five times. Why late? The server ran out of disk space. Why? Log files filled the disk. Why? Old logs were never deleted. Why? The nightly clean-up job was switched off during a server migration and never switched back on. Why? The migration checklist has no step for re-enabling scheduled jobs. Which finding should the team act on to stop this happening again?

See the answer

The migration checklist has no step for re-enabling scheduled jobs

The five whys technique keeps asking why until it reaches a cause that, if fixed, prevents the chain from starting again. Freeing disk space or deleting the logs treats symptoms, and switching the job back on fixes this occurrence only; the next migration would switch it off again. Adding the missing step to the checklist removes the root cause.

← Digital

↑ T Levels and BTEC