The Ruha Method, Part 1: Define and Scope
By the end of this module you will be able to take a vague complaint and turn it into a problem statement precise enough to investigate — before touching a single setting.
Write a problem statement worth investigating
Almost every wasted hour in technology support starts in the first two minutes. Someone describes a problem, you accept the description, and then you spend the rest of the afternoon investigating the wrong thing.
Here is the thing worth internalising early: the person reporting the problem is describing what they experienced. That is genuinely useful information, and it is not the same as a description of what is wrong. Your first job is not to fix anything. It is to translate.
"The computer is broken."
"The computer connects to Wi-Fi, but Outlook cannot send messages."
Look at what the second statement has already done. It has told you the network is probably fine. It has told you the machine is powered and usable. It has narrowed the problem to one application and one direction of travel — sending, not receiving. You have not investigated anything yet and you have already eliminated most of the system.
What makes a statement usable
- It names what works. Working things are evidence. They are how you rule regions out.
- It names the specific failure, not the general feeling. "Cannot send" beats "isn't working."
- It uses observable facts, not interpretations. "It says the password is incorrect" beats "the password is wrong" — those are different claims, and the second one is a guess.
A symptom tells you what the person sees. A cause tells you why it happened. Nearly all bad troubleshooting comes from treating the first as though it were the second.
Determine who and what is affected
Scope is the fastest tool you have. One question — who else has this? — can eliminate more possibilities than an hour of investigation.
Think back to the technology map: person, device, network, identity, application, data, service. Scope tells you roughly where on that chain to stand.
- One person, one device. Look at that device and that person's account. A service outage would not politely affect one desk.
- One person, every device. Now it follows the person, not the hardware. That is an identity or permissions shape.
- Several people, one location or one group. Something they share — a network segment, a security group, a printer, an office.
- Everyone, everywhere. Now a service-level problem is plausible. Check the provider's status page before you touch anything.
Notice that the same reported symptom — "I can't get to my email" — lands in four completely different investigations depending on scope alone. You have changed nothing about the technology. You have changed what you know.
If three people cannot access email and twenty can, the email service is almost certainly running. The pattern has already told you something, and it cost you one question.
Establish what changed
Systems that were working yesterday and are not working today changed. Something almost always did. The difficulty is that the person rarely connects the change to the symptom, so they do not mention it.
"Nothing changed" is the most common sentence in technology support and it is almost never true. It is not dishonesty. People genuinely do not think of a password reset, a software update, or a new role as a change to anything.
Ask about changes indirectly
Rather than "what changed?", which reliably produces "nothing," try questions that describe events rather than causes:
- When did it last work properly?
- Has anyone updated a password recently?
- Did anything get installed, updated, or restarted?
- Has this person changed role, team, or permissions?
- Was any new equipment plugged in, or anything moved?
- Did anyone else touch the system — a vendor, a colleague, a family member?
Now put the three lessons together. You have a precise statement, you know the scope, and you know what changed. In most cases you can now name the likely region of the system before you have opened a single settings panel.
A real ticket, before you fix anything
This is the work. Read the ticket, then write the problem statement, the scope, and the change — in your own words, before you look at the model answer.
Write down three things: a problem statement that points somewhere, what the scope tells you, and what you would ask about the weekend. Then reveal the model answer and compare — not to check whether you were right, but to see what you left out.
Problem statement
Two front-desk computers cannot load the scheduling system, while the same system is reachable from at least one phone. Failure presents as an indefinite load rather than an error message. Working since Friday, failing Monday morning.
What the scope tells you
Karen's phone is the most valuable fact in the ticket. It means the scheduling service itself is running and reachable — so this is not a vendor outage, and the practice can keep working from phones while you investigate. That is worth saying out loud in the first sixty seconds, because it changes the client's morning.
The failure is shared by two office computers and absent on a phone that is probably on mobile data. That shape points at something the two computers share and the phone does not: the office network, a DNS setting, or a browser or certificate state common to both.
What to ask about the weekend
Whether anything restarted or updated, whether the router or any equipment was replaced or moved, whether the internet provider did work, and whether anyone was in the office. Monday-morning problems after a quiet weekend very often trace to something that rebooted overnight and came back differently.
What most people miss
"We have patients arriving" is part of the ticket. Scope is not only technical — knowing that phones work means you can hand the practice a way to operate within minutes, before you have found the cause. Solving the business problem and solving the technical problem are two different clocks, and the first one is usually shorter.
Next: Module 4 — The Ruha Method, Part 2: Isolate and Verify. Reproducing the fault, changing one thing at a time, and proving the fix against the original complaint rather than against a feeling.