Symptom or Root Cause? Reverse-Engineering a Pain Point

The phone call that keeps coming back

It is a Tuesday afternoon in a program office. A parent calls to move Thursday to Friday. The office makes the change, writes a note so the bill gets adjusted, and goes back to what it was doing. A little later, another parent calls with another change. Then another.

Eventually someone suggests a fix: a form on the website, so parents can send their changes instead of calling. It helps for a while. Then the office is reading form messages instead of answering calls, still making every change by hand, and still writing the same notes for the bill.

That is what happens when a fix lands on the symptom. The calls were real. They were never the problem.

Step three of how we work

Our process has four steps. We listen while you show us how your day really runs. We find the pain points, naming every place your tools slow your team down or force a workaround. We reverse-engineer the problem, tracing each pain point back to its root cause. Then we build the solution to work the way you described, and prove it with your team before it goes live.

This post is about step three. It is the step that decides whether what we build removes a workaround or just moves it somewhere else.

We leaned on it heavily with a YMCA school-age program we built alongside. You can read how we built it on our process page. The team there was clear about what hurt. Parents phoned to change their schedules. Rescheduling, charging accounts and processing refunds were done by hand. Finding declined cards meant searching for them. The work of step three was finding out why each of those kept happening.

A method you can run with a whiteboard

Reverse-engineering a pain point is not complicated. It is just patient. For each pain point:

• Describe the symptom exactly. Not scheduling is hard, but the specific moment: who does what, and what they reach for.
• Ask why it has to happen that way. Write the answer underneath.
• Ask why again. Keep going until the answer stops being about a person's effort and starts being about where information lives or who is allowed to change it.
• Test the root cause. If you fixed only that, would the symptom have anywhere left to come from?

In school-age programs, the root causes we find tend to be one of two things: the same fact kept in more than one place, or a change that only one room is allowed to make. Here are three worked examples.

Three pain points, traced to the bottom

Parents call to change days. The symptom is a phone that rings all afternoon with schedule changes. Why? Parents cannot change their own days. Why? The schedule can only be edited from the office. The root cause: only the office can change a schedule.

The website form failed because it left that root cause in place. The office still had to make every change. The fix that lands on the root cause is letting parents choose and change their own days online. In what we built, that is how it works, and the routine calls about changing days have nowhere left to come from.

Bills are wrong. The symptom is bills that need fixing by hand before they go out, and families calling about charges. Why? The bill does not match what the child was scheduled for. Why? Someone changed the schedule, and the change never reached the billing sheet. The root cause: the bill and the schedule live in two places.

Checking every bill more carefully treats the symptom. It adds a step, and the step depends on someone remembering. The fix that lands on the root cause is building the bill from the schedule, so the two match. In what we built, the bill is built from the schedule, and someone in the office starts one run that bills the whole week.

Closed days show up on the bill. The symptom is a stretch of credits after a snow day or a holiday. Why? The bill charged for a day the program did not run. Why? The closed-day calendar is kept apart from billing. The root cause: the bill does not hear about the program's calendar.

This one looks like a third problem, but it traces back to the second. The bill is being figured somewhere that does not hear about the rest of the program. Once the bill is built from the schedule, days the program is closed are not charged, and there is no stretch of credits to chase.

Three symptoms, two root causes. That is usually how it goes.

This is what we mean when we say software should echo you. The program describes a symptom, and the software answers the root cause underneath it, in the program's own terms.

Run it at your next staff meeting

You can do this without us. Set aside part of your next staff meeting and try it on a single pain point.

• Ask each person to name one workaround they used this week: a sticky note, the second spreadsheet, the binder, a phone call they had to make or take.
• Pick one. Write the symptom on the board in plain words.
• Ask why, and write the answer under it. Ask again. Stop when the answer is about where information lives or who is allowed to change it.
• Ask the test question: if that root cause were gone, would this workaround still be needed?

Then do the same for the next one. You will likely find that several different symptoms trace back to the same root cause. That is the most useful thing this exercise can show a director, because one fix in the right place removes several workarounds at once.

Bring the coordinators from each site if you can. They see symptoms the office never hears about, and they often know the second why before anyone else does.

Tell us the symptom, and we will trace it with you

If your team has a long list of workarounds and no time to trace them, that is where we come in. Tell us how your day really runs at your YMCA, park district or rec center. We will follow your pain points down to their root causes with you, and only then start building.

Request a demo