Diagnose Where the Problem Actually Lives

It is not a surface problem

There is a particular kind of frustration that comes from fixing something that keeps breaking.

Not because you didn't try. Not because the fix was poorly designed. But because three months later, sometimes six, the same situation is back. Maybe the details are slightly different. Maybe they're exactly the same. Either way, you're back where you started, wondering why something that seemed resolved keeps resurfacing.

This is what happens when a solution gets applied at the surface of a problem that originates somewhere deeper. And it happens more often in IEC practices than most advisors realize, not because they're making bad decisions, but because the diagnostic step between defining a problem and solving it almost always gets skipped.

This article is part of the 12-part Business Architecture for IEC Practices series. Section 9 focused on defining a problem specifically enough to make the right solution visible. This section takes the next step: identifying where the problem actually originates so that whatever comes next addresses it at the source.

Download the Section 10 PDF
This includes the Diagnose framework and guided prompts to identify where one specific problem in your practice actually originates.

Download the IEC Business Tool Evaluation Guide Part 2: Diagnose
Part 2 of 3: A standalone decision framework you can use right away to evaluate any tool, system, or operational change you’re considering in your practice.

Why the Same Problems Keep Coming Back

Most IECs are good problem solvers. That's part of what makes them effective advisors. They see what's needed, they respond, they move forward.

That same instinct is what makes the diagnostic step easy to skip.

When something keeps coming up, the focus naturally goes to the most visible version of it. A student isn't completing tasks, so reminders get added. A parent is sending too many emails, so a response policy gets put in place. Scope keeps expanding, so the agreement gets revised.

Each of those responses makes sense in the moment. Each one addresses something real. And yet the same problems surface again the following season because the response addressed where the problem showed up, not where it started.

The policy didn't stop the emails because the emails weren't the problem. They were the symptom of a communication structure that was never established at the start of the engagement. The revised agreement didn't contain scope because scope wasn't drifting due to unclear contract language. It was drifting because the work itself had no defined sequence to operate within.

Fixing the symptom feels productive. It creates visible change. But it doesn't touch what's actually driving the issue, which is why the same situation returns.

The Question Most Advisors Skip

When something in a practice keeps breaking down, the question that gets asked is almost always: What should I do about this?

The question that actually matters is: where is this coming from?

Those are not the same question, and they don't lead to the same answers.

"What should I do about this?" leads to a response. "Where is this coming from?" leads to a diagnosis. And a response applied without a diagnosis is just another layer on top of a problem that hasn't been identified yet.

In my experience working with IECs one-on-one and watching patterns emerge across practices of every size and model, most issues trace back to one of four places: process, expectations, structure, or tools. Not a combination of everything. One primary source that, once identified, makes the right solution obvious.

What Each Source Actually Looks Like

A process problem means there is no clearly defined sequence for that part of the work. The student doesn't know what to do next because nothing has told them. The advisor is filling that gap manually, every time, with every student, because the process itself hasn't been designed to run without them.

An expectations problem means something that should have been established at the start of the engagement wasn't. Families are operating on assumptions because no one gave them a framework to replace those assumptions with. The miscommunication isn't happening because families are difficult. It's happening because the information that would have prevented it was never delivered in a structured way.

A structure problem means the work has no defined container. There is no clear beginning, no defined scope, and no point where the engagement formally ends. The work expands to fill whatever space is available because nothing has been designed to hold it.

A tools problem means the platform or system being used isn't connected to a defined process. The tool is being asked to organize work that hasn't been structured yet. Which is why students don't use it, why it feels like more work than it saves, and why switching platforms never actually solves anything.

Why This Step Changes Everything That Follows

Once the source is correctly identified, something shifts in how the problem looks.

It stops feeling like a recurring frustration and starts looking like a specific gap. And specific gaps have specific solutions that address them at the level where they originate rather than at the level where they show up.

More importantly, a correctly diagnosed problem prevents the next common mistake: reaching for a solution before knowing whether what you need already exists or whether you're about to spend significant time building something from scratch that may not address the source anyway.

That's what Section 11 gets into. Because once you know where a problem lives, the next question isn't just what to do about it. It's about whether the solution you're considering actually fits what you've just identified, and what it's really going to cost to implement.

Where This Leads

Defining and diagnosing a problem are the two steps that determine whether everything that follows actually works.

Most advisors skip one or both of them, not because they don't care about solving things well, but because something feels urgent and the instinct is to move. The work of these two sections is exactly the kind of work that feels slow until you realize it's the only thing that makes the solution stick.

Section 11 addresses what comes next: evaluating whether the solution you're considering actually addresses what you've just identified, and what it genuinely takes to fix something at the source rather than at the surface.