Problem-solving methods: a systematic approach

Every day something fails to go as expected: a shop runs out of stock, learners arrive late for class, a computer will not connect to the internet. In these situations many people immediately apply the first solution that comes to mind or start looking for someone to blame. As a result, the problem often comes back a few weeks later. In this guide you will learn to solve problems systematically in seven steps: defining the problem clearly, separating facts from assumptions, finding the root cause with the “5 Whys” and an Ishikawa diagram, developing solution options and evaluating them with a decision matrix, drawing up an action plan and checking the result with the PDCA cycle. We also look at working under stress, in a team and with technical faults, walk through an example from a small shop, cover common mistakes, and finish with a practice exercise and a checklist.

Step 1: define the problem clearly

A problem well defined is a problem half solved. “Everything is going wrong”, “the staff are not working” or “the computer is broken” is not a definition, it is a mood. It gives you no idea what to do.

Symptom versus cause

A symptom is the visible result: customers complain, a report is late, stock runs out. A cause is what produces that result. “Treating” a symptom only brings temporary relief. For example, you can finish an overdue report by staying up one night, but if the data for it arrives late every month, next month you will be up all night again.

So at the first step, do not draw conclusions about the cause — simply write down what you observe.

The problem statement

A problem statement describes the problem precisely in one or two sentences. It answers five questions: who (who is affected), what (what exactly is happening), when (since when, at what time), where (in which place or department) and how much (how often, on what scale). A hypothetical example:

Who: learners in the evening group.
What: they arrive 10–20 minutes late for class.
When: since the start of September, mostly on Mondays and Thursdays.
Where: at the centre’s second branch.
How much: several people from the group in every lesson.

Notice that the statement contains neither a solution nor a culprit. There is no “the learners are irresponsible” — that is still an untested assumption.

Step 2: gather information

To understand a problem you need information. The most important skill here is telling a fact from an assumption.

• A fact is something you can check: “Over the last two weeks, 6 people were late for Monday classes” (the number is hypothetical), “The printer is reporting a paper jam”.
• An assumption is a confidently stated but untested idea: “They are late on purpose”, “The printer is too old”.

An assumption is useful as a hypothesis to test; the mistake is treating it as a fact. Simple ways to gather information:

1. Observe. Watch the process with your own eyes: when and in what form does the problem appear?
2. Ask. Ask the people involved: “What happens?”, “When did it start?” Instead of an accusing “Why do you do that?”, ask “What is getting in your way?”
3. Keep a record. For a week or two, keep notes in an ordinary notebook or a spreadsheet: date, time, what happened.
4. Compare. Where does the problem occur and where does it not? If the first branch has no late arrivals, the difference between the two branches is an important clue.

The habit of keeping records also helps with bookkeeping in a shop or tracking working hours.

Step 3: find the root cause

The root cause is the deepest cause: once it is removed, the problem does not return. There are two simple, well-known ways to find it.

The “5 Whys” method

You start with the problem and ask “why?” again and again, with each answer becoming the basis for the next question. “Five” is not a strict rule: sometimes three questions are enough. What matters is not stopping at a superficial answer.

Dilnoza, the head of a training centre, looks into late arrivals in the evening group (a hypothetical example):

1. Why are the learners late? Most of them come by bus, and the bus reaches the stop just before the lesson starts.
2. Why does this happen only in this group? Almost everyone in the group lives in the neighbouring district and travels on the same route, which slows down in evening traffic.
3. Why does the lesson start at exactly this time? The timetable was drawn up for the previous group and was not changed for the new one.
4. Why was it not changed? When the group was formed, nobody asked the learners what time suited them.
5. Why did nobody ask? The centre has no procedure for agreeing the timetable with learners when a new group is opened.

The root cause is not “undisciplined learners” but the lack of a procedure for agreeing the timetable. Remove it, and the problem will not recur in future groups either.

Each answer must be backed by facts; otherwise the chain will lead you to the wrong conclusion.

The Ishikawa (fishbone) diagram

When there are several causes, an Ishikawa diagram comes in handy. It looks like a fish skeleton: the problem is written at the “head”, and the “ribs” branching off the “spine” are categories of causes. You can draw it on paper or a whiteboard.

Commonly used categories:

• People — knowledge, experience, fatigue.
• Methods — work procedures, timetables, instructions.
• Equipment — computers, software, tools.
• Materials — raw materials, goods, documents.
• Environment — premises, weather, transport.
• Measurement — how the result is calculated.

For Dilnoza’s late-arrival problem, the diagram might be filled in like this: People — some learners come straight from work; Methods — the timetable was not agreed, there is no clear rule for latecomers; Equipment — the doorbell at the entrance does not work, so people have to wait; Environment — evening traffic; Measurement — attendance is kept only on paper and lateness is not recorded. You then check the most important causes against the facts. This logic is close to algorithmic thinking: breaking something big into small parts you can test.

Steps 4–5: solution options and evaluation

Developing options

Do not cling to the first solution that comes to mind — write down at least three options. To do this:

• come up with a separate solution for each root cause;
• ask yourself, “What would I do if there were no constraints?”, then adapt the idea to real conditions;
• ask people who have faced the same problem;
• also write down the “do nothing” option — it becomes the baseline for comparing the others.

First lots of ideas, then the selection. Idea-generation techniques are covered in the article on creative thinking.

Dilnoza’s options: (A) start the evening group’s lessons half an hour later; (B) move the learners to the first branch, which is closer to the bus stop; (C) use the first part of the lesson for revision and questions and start the new topic later; (D) change nothing.

A pros and cons table

The simplest method is to list the pros and cons of each option side by side.

A simple decision matrix

When there are many options, a decision matrix helps:

1. Write down the criteria: for example, effectiveness, ease of introduction, convenience for learners, workload for the teacher.
2. Give each criterion a weight: 1 — less important, 3 — very important.
3. Score each option on each criterion from 1 to 5.
4. Multiply each score by the weight and add them up.

An example with hypothetical scores (weighted scores in brackets):

The matrix does not make the decision for you — it organises your thinking. If the result feels “wrong”, you have probably left out an important criterion. When several people agree the scores together, the result is more objective.

Steps 6–7: action plan and checking the result

The decision and the action plan

Once a decision is made, turn it into specific tasks. For each task, answer three questions: who does it, what is done, and by when. A task with no named owner usually stays undone.

Dilnoza’s plan (deadlines are hypothetical):

The last row targets the root cause — without it, everything will happen again with the next group. To keep track of the plan, use a simple board or the tools from the article on project management basics.

The PDCA cycle: check the result and learn

It is a mistake to think the job is done once the solution is in place. Did it actually work? To check, use the PDCA cycle:

1. Plan — define the problem, cause and solution, and agree in advance how to measure the result: “for two weeks we will record the number of late arrivals”.
2. Do — first try the solution on a small scale: in one group, for a few weeks.
3. Check — compare the result with the starting point. Are there fewer late arrivals? Has a new problem appeared?
4. Act — if the solution worked, make it standard practice and extend it to other groups; if not, go back to the Plan stage and try another option.

The cycle turns again and again, and each time the process improves a little. At the end, write a short summary: what worked, what did not, and what you will do differently next time.

Special situations

Solving problems under stress

In an emergency, systematic thinking becomes harder. At such moments:

• first make the situation safe and stop the damage (for example, if water is leaking, turn off the tap first and look for the cause later);
• take a few deep breaths and describe the situation in three or four sentences;
• separate the temporary fix from the permanent solution: what must be done right now, and what can be analysed calmly tomorrow.

For ways to ease the pressure, read the article on managing stress.

Blame-free team discussion

When a team discusses a problem, the key question is not “Who is to blame?” but “What happened, and what will we change in the process?” People who fear punishment hide their mistakes, and the cause never comes to light. Rules for a blame-free discussion:

• stick to the facts and focus on the process, not the person;
• give everyone a chance to speak, starting with those who usually say the least;
• at the end, write down specific actions and who is responsible for them.

This is an important part of a teamwork culture and one of the soft skills that employers value.

Technical problems: change one variable at a time

A common mistake with a technical problem is changing several things at once. Say Javohir’s laptop will not connect to the office Wi-Fi. He restarts the router, re-enters the password, updates the driver and disables the antivirus — and then the internet works. But nobody knows what actually helped.

The right approach is the logic of debugging:

1. Narrow down where the problem is. Does another device connect to the same network? If it does, the problem is in the laptop; if not, it is in the router.
2. Make one change. For example, only restart the laptop.
3. Check. Did it work? If so, stop and write down what helped.
4. If not, move on to the next single change. For example, go to Settings → Network & Internet → Wi-Fi → Manage known networks, select the network, click Forget and connect again.

Write down every step. Apply the tips on speeding up your computer one at a time as well.

When to ask for help

Asking for help is not a weakness. Turn to a specialist or an experienced colleague if:

• after several attempts you still cannot narrow the problem down;
• the cost of a mistake is high: electricity, gas, health, legal matters, important data;
• the problem is outside your authority.

When you ask for help, briefly give the problem statement, what you have already done and what the result was.

Example: stock shortages in Sardor’s shop

Sardor runs a small grocery shop in his mahalla. Lately customers have been coming in the evening for milk and bread, only to find the shelves empty. The quantities in this example are hypothetical.

1. Definition. “On weekdays, milk and bread run out after six in the evening; every day several customers leave empty-handed. The problem started in September.”
2. Information. For two weeks Sardor keeps a notebook: how many crates of milk and how many loaves of bread were delivered, and what time they ran out. For example, on weekdays milk arrived in batches of 20 crates and ran out by the evening, while at weekends some was left over.
3. Root cause. The “why?” questions: milk runs out → the order is the same every day → it is placed out of habit from last year → a new block of flats was built in the mahalla and there are more customers, but the order has not changed → there is no habit of checking the order against sales records.
4. Options. (A) increase the weekday order to 25 crates and reduce it at weekends; (B) ask the supplier for a second delivery during the day; (C) take advance orders from regular customers.
5. Evaluation. Sardor picks three criteria: stock should not be left over and spoil, ease of introduction, and convenience for customers. The matrix puts option A first, with C as an addition.
6. Plan. Sardor changes the order from the next day, shop assistant Gulnora notes for two weeks when stock runs out, and every Sunday the two of them review the notes and set the order for the following week.
7. Check. Two weeks later the milk lasts until the evening, but a little is left over on Fridays. Sardor slightly reduces the Friday order — the next turn of the PDCA cycle.

The main outcome is the habit of reviewing the order against weekly records.

Common mistakes

• Jumping straight to a solution. A solution is applied before the problem is understood, and it merely hides the symptom.
• Looking for someone to blame. Even if you replace the person, the faulty process remains and the newcomer will make the same mistake.
• Treating an assumption as a fact. “I know what the cause is” — untested certainty wastes more time than anything else.
• Settling for one option. Without a comparison, the better path stays hidden.
• A plan with no owners. A task that “someone will do” gets done by no one.
• Not checking the result. It remains unknown whether the solution worked.

Practice exercise and checklist

Pick a real but small problem: being late for work in the morning, not being able to find things at home, putting off a report until the last day of every month, or the office printer jamming all the time.

1. Write a problem statement using the questions who, what, when, where and how much.
2. For a week, record the facts and write assumptions down separately.
3. Build a “5 Whys” chain and mark each answer as a fact or an assumption.
4. Draw an Ishikawa diagram with at least four categories.
5. Write down at least three solution options, and add the “do nothing” option too.
6. Build a simple decision matrix with three or four criteria.
7. Set out the action plan as a who, what and by-when table.
8. After two weeks, check the result and write a short summary.

Checklist

• The problem statement contains neither a solution nor a culprit.
• Facts and assumptions are kept separate.
• The root cause is confirmed by facts.
• At least three options have been considered.
• The evaluation criteria and their weights were written down in advance.
• Every task has an owner and a deadline.
• How to measure the result was agreed in advance.
• A summary is written: what we will do differently next time.

Systematic problem-solving is a skill that grows with practice. Go through these steps a few times with small problems, and in bigger situations they will become a habit.

If you would like to learn planning, teamwork and task management systematically with a teacher, take a look at our association’s free project management programme and other training programmes. When you are ready, submit an application and our specialists will get in touch.