6 Proven Steps of THE CLEARS METHOD™ Business Turnaround Framework

I didn’t walk into my first turnaround with a plan. I walked in with a process. Forty years and dozens of companies later — call centers, software shops, manufacturing lines, financial services operations, telecom carriers — that process hasn’t changed much. What has changed is that I finally sat down and wrote it out, step by step, so you don’t have to spend four decades learning it the way I did: the hard way, one expensive mistake at a time.

This article is that process, laid out in full. I call it THE CLEARS METHOD™ business turnaround framework — Collect, Learn, Evaluate, Architect, Run, Sustain — and I’m going to walk you through all six steps, in order, with the real stories behind each one. Not theoretical case studies borrowed from someone else’s consulting deck. Mine. A company that was about to lose its biggest customer. An Oracle migration that had already failed once. A call center quietly losing five percent of every transferred call and nobody noticing. An IVR redesign where I had the right answer sitting in front of me and talked myself out of believing it. A staffing model that looked airtight until it wasn’t.

If you’re a leader who’s just been handed a struggling business — or a healthy one you’re responsible for keeping that way — this business turnaround framework is built for you. It doesn’t require a big consulting budget. It doesn’t require a title change. It requires discipline, in a specific order, applied consistently, and I’m going to show you exactly what that looks like. I am in the process of writing a book on THE CLEARS METHOD™ which will dive even deeper into the methodology which will be released in early 2027, if not sooner.

I’ve applied this same sequence to companies you’d recognize by their category even if I’ve changed a few identifying details out of respect for the people involved — a claims-processing software vendor watching its biggest customer walk out the door, a financial services call center running a computer migration that had already failed once, a multi-site operation quietly losing customers in a transfer nobody thought to check, an IVR redesign where the data was right and I talked myself out of believing it anyway. Different industries. Different decades, some of them. The same six steps, every time, because the steps aren’t about the industry. They’re about how organizations actually break, and how they actually get fixed.

A quick note on how to use this information. This is the master overview of THE CLEARS METHOD™ business turnaround framework. Each of the six steps below links out to its own full-length guide, where I go much deeper into the tools, the templates, and the additional stories that wouldn’t fit here. Think of this page as the map, and the six linked guides as the terrain.

What Is a Business Turnaround Framework, and Why Do Most Efforts Fail? A business turnaround framework is a repeatable, ordered process for diagnosing what’s actually wrong inside a struggling organization and fixing it — as opposed to a one-time strategy session, a consultant’s slide deck, or a gut-level reorganization. The word that matters most in that sentence is repeatable. Anyone can get lucky once. A real framework is something you can pick up and apply to a twelve-million-dollar software company or an operation with five thousand employees, in an industry you’ve never worked in before, and trust it to hold up.

Most turnaround efforts fail for one of two reasons, and I’ve watched both play out more times than I can count. The first is that the leader walks in with a diagnosis already formed — usually borrowed from a similar-looking problem at a previous company — and starts fixing before they’ve actually understood what’s broken. The second is that the leader does understand the problem correctly but has no disciplined way to move from understanding to a working solution, so good diagnosis dies in a strategy binder nobody ever implements.

A working business turnaround framework solves both failure modes at once. It forces you to understand before you diagnose, and it forces you to implement in a way that actually sticks instead of drifting back to the old way of doing things within six months. That’s the whole promise of what follows. Not a clever insight. A sequence.

I want to be direct about something before we go further: most of what passes for a business turnaround framework in the popular business press is really just a financial framework wearing a turnaround costume — cut costs, renegotiate debt, sell off the unprofitable division, install new leadership, wait. Those levers matter, and I’m not dismissing them. But financial restructuring answers the question “how do we stop the bleeding,” not the question “why is the patient bleeding in the first place.” THE CLEARS METHOD™ business turnaround framework I’m about to walk you through answers the second question, and in my experience, answering it correctly usually solves the first question as a byproduct.

My Story: What 40 Years Inside Broken Businesses Taught Me

I’ve spent the better part of forty years walking into companies that were losing money, losing customers, or losing both, and being asked to turn them around. I started in call center operations, learned Six Sigma from the inside out, ran technology migrations, managed manufacturing lines, and eventually led operations with more than five thousand employees across health insurance, telecommunications, financial services, and manufacturing.

Here’s what I want you to understand about that career, because it’s the entire reason this business turnaround framework exists: I didn’t set out to build a methodology. I set out to solve problems, over and over, for forty years, and at some point I noticed I was solving them the same way every time, regardless of the industry. Collect first. Then Learn. Then Evaluate. Then Architect. Then Run. Then Sustain. The sequence never changed even when everything else about the business did.

I’ll give you the short version of the story that convinced me this business turnaround framework is genuinely industry-agnostic, because I’ll come back to it in full detail in Step 1. I was asked to take over a software company selling claims-processing technology to health insurance carriers. Twelve million dollars in annual revenue, losing money, already lost several major customers, and the single biggest customer remaining was sitting across the table threatening to walk. I didn’t walk in with a turnaround plan. I walked in with a process — the same one I’d used before and would use again, in industries that had nothing to do with health insurance software. That’s the point. The framework doesn’t care what business you’re in. It cares whether you follow the sequence.

This is the process I have used, in one form or another, for forty years, across companies ranging from a twelve-million-dollar software shop to operations with over five thousand employees.

Introducing THE CLEARS METHOD™ Business Turnaround Framework

THE CLEARS METHOD™ business turnaround framework has six steps, and the order is not a suggestion — it’s the mechanism. Skip a step, or run them out of sequence, and you’ll design a technically competent solution for a problem that doesn’t actually exist, which is a special kind of expensive failure because it looks like progress right up until it isn’t.

Step	What It Does	The One-Line Discipline
C — Collect	Gather the truth from every angle before forming an opinion	Refuse to diagnose on day one
L — Learn	Turn raw discovery into one coherent map of how the business actually runs	Map the workflow, not the org chart
E — Evaluate	Trace every symptom back to its real root cause	Find the gap or bottleneck underneath the complaint
A — Architect	Design a fix with the people who’ll live inside it, then test it	Trust the test over your own confidence
R — Run	Implement with discipline — predicted impact, dependencies mapped, a back-out plan ready	Implementation is a discipline, not an event
S — Sustain	Turn the fix into a permanent control so it doesn’t quietly unravel	Monitor what you built, don’t just admire it

Every one of those six steps depends on the one before it. You cannot Architect a solution for a root cause you haven’t traced in Evaluate. You cannot Evaluate a business you haven’t mapped in Learn. You cannot Learn a business you haven’t actually listened to in Collect. That dependency chain is what makes this a business turnaround framework rather than a loose collection of good ideas — each step is load-bearing for the one that follows it.

Let’s go through all six, one at a time, with the real stories behind each.

Step 1 of THE CLEARS METHOD™ Business Turnaround Framework — Collect: Refuse to Diagnose the Business on Day One

Every business turnaround framework has to start somewhere, and where you start determines almost everything about whether the rest of the process works. THE CLEARS METHOD™ starts with Collect, and Collect has exactly one job: gather the truth, from every direction, before you let yourself form an opinion about what you think is wrong.

The Company That Was Losing Its Best Customer

I told you a piece of this story already, but I want to walk you through it properly, because it’s the clearest example I have of Collect actually working. Dakota Imaging was a software company selling claims-processing technology to health insurance carriers — software that took paper claims and turned them into clean, structured data a payer could process. When I was asked to take it over, the company was in trouble on every front that mattered. Revenue was around twelve million dollars, the company was losing money, it had already lost several of its largest customers, and its single biggest customer — the one whose logo everyone pointed to when they wanted to say the company mattered — was sitting across the table in contract negotiations, actively threatening to walk.

I want to be honest about something: I did not walk in with a turnaround plan. I had a process, and the first move in that process is always the same, no matter the industry, the company size, or how bad the fire looks. I go learn. I met with the leadership team. Then the current customers, the ones still writing checks. Then the ones who had already left, because a departed customer will tell you things a current one never will. Then the service organization, the people fielding complaints every single day. Then I kept going, function by function, until I’d talked to nearly everyone who touched the product from the inside and the outside.

What came out of those conversations was a disconnect nobody inside the company had named, even though everybody was living with its consequences. The software architects and developers were deeply skilled — genuinely excellent at their craft — but they had stopped using that expertise the way their customers actually needed them to. Health insurance claims processing runs on industry-standard code sets. The customers, though, were running old legacy systems that had already claimed many of those standard fields for other purposes over the years. When Dakota’s team ran into that mismatch, they didn’t push back. They just did what the customer told them to do. “We have to follow their direction,” they told me, like it was obvious.

It wasn’t obvious to the customer. The customer had hired Dakota because Dakota was supposed to be the expert. When I told the team that their clients expected them to use that expertise to guide the engagement — even when it meant disagreeing with what the client was asking for — I remember the surprise on their faces. That single insight explained why installations that should have taken one pass were taking three. Once we built a translation layer into how we approached every implementation, a three-install process became a one-install process. Less labor. A better customer experience. Trust that had been draining out of the relationship started flowing back in. We kept our largest customer. We won back some we’d lost. A year later, the company that had been bleeding money was profitable, with revenue climbing instead of shrinking.

None of that came from a strategy session. It came from Collect. That’s the payoff this entire step is built around: not a clever insight, but a disciplined refusal to guess.

The Skills You Need Before You Walk In

Collect goes a lot better if you’re not learning its underlying skills for the first time under pressure. You need at least a working knowledge of project management — not certification-level expertise, just an intuitive feel for time, dependency, and sequence, so that when someone tells you “we can’t close the books until receivables are completed,” you instantly recognize you’ve just been handed a dependency, not a complaint. You need a practical grasp of how processes function, because every function you walk into is really just a sequence of inputs, transformations, and outputs, whether the people doing the work think of it that way or not. And you need interpersonal skill sharp enough to make people want to tell you the truth, because Collect is only as good as what people are willing to say to you.

Gorilla or Sponge

Here’s the mistake I see leaders make constantly when they step into a new organization: they come in like a gorilla, trying to prove something, trying to establish dominance, trying to show everyone how fast they can spot the problems. The people you’re about to meet are already braced for exactly that. They’re ready to resist you before you’ve said a word. Don’t challenge back. When someone pushes on you, meet it with acceptance. Be a sponge instead. Absorb everything you can about the business, the people, and the processes before you try to change a single thing.

One habit I’ve kept my entire career is walking the floors — I learned it early at American Express, where they called it MBWA, management by walking around. In today’s world, the same result comes from a two-line instant message that has nothing to do with a deliverable, a camera turned on when you’d rather leave it off, the extra ninety seconds of small talk before you hang up a call. Small, repeated, genuine. That’s the whole formula, in person or on a screen.

Setting the Stage for the Whole Organization

Individual introductions work for the leadership layer, but stepping into a larger organization means you also need a way to introduce yourself to everyone at once without disrupting the business. I hold large employee meetings designed to minimize disruption, share a little background so people know who they’re dealing with, and then tell them, honestly, that I value the work they do. I mean it, and people can tell the difference.

I open the lines of communication in that same meeting. I invite anyone with a question or concern to bring it to me directly, and I make it explicit that there will be no recourse for speaking up — none. I give out my email and mobile number in the room, which is as much a message to the leadership layer as it is to the frontline: don’t try to filter what reaches me. I also address the question sitting unspoken in the back of everyone’s mind: what does this mean for me? I tell people plainly that I’m not coming in to make dramatic changes right away, because I genuinely don’t know yet what changes, if any, are needed. If changes do become necessary down the road, I promise we’ll communicate openly, ahead of time, and give everyone room to adjust. That’s not a soft promise. It’s good change management, and it starts paying dividends the moment you make it, because people relax enough to actually talk to you honestly.

The First Ninety Days: Don’t Get in a Hurry

As a general rule, it takes a solid ninety days to genuinely understand a new organization — what it does, and who the people in it are. My wife has a line she’s told me more times than I can count: “Just listen. Don’t try to fix it.” That’s exactly the discipline this step requires. I’ll give you the honest exception, too: I have changed things within the first three days when I saw a problem serious enough that it couldn’t wait. In Six Sigma terms, sometimes you just have to get it done. But that’s the exception, not the rule, and you shouldn’t reach for it as your default.

Will or Skill Problem?

As early as possible, I make it a point to identify the complainers, because complainers come in two very different flavors and telling them apart matters enormously. The question I’m asking about every one of them is: is this a will or a skill problem? A skill problem usually sounds like genuine effort paired with genuine confusion — the person wants to get it right, asks real questions, and visibly struggles with the how. A will problem sounds like excuses that shift each time you ask, a story that doesn’t hold together the same way twice. Skill, you can often build with training or a better-matched role. Will, in my experience, almost never changes no matter how much runway you give it.

I also make it a point to find the people who are deeply knowledgeable — the go-to person for half the building, the one everyone tells you they’d be terrified to lose — because after some time in the role, I often discover that person is the actual source of most of the organization’s problems. That’s a lesson I learned the hard way, and I’ll tell you the full story of how in Step 2. For now, the discipline to remember from Collect is simple: gather the truth from every direction, resist the urge to fix anything on sight, and don’t let yourself form a diagnosis until you’ve genuinely listened. Everything else in this business turnaround framework depends on getting this first step right, because you cannot design a solution for a problem you don’t actually understand.

Read the full guide: Collect — Why the Best Leaders Refuse to Diagnose a Business on Day One

Step 2 of THE CLEARS METHOD™ Business Turnaround Framework — Learn: Turn a Pile of Interviews into One Map Everyone Trusts

Collect gives you raw material — conversations, documents, half-formed impressions. Learn is where you turn that pile into one coherent map of how the business actually runs: the technology, the process, and the people quietly running the whole thing on leverage instead of legitimate expertise. Miss any one of those threads, and you’ll design a beautiful solution for a business that doesn’t actually exist.

The Company With No Vision, Just a Deadline

I took over a small company in South Carolina in the middle of a computer system migration that had already gone badly sideways. Their existing system was running out of capacity and the company had committed to moving everything onto Oracle before that capacity ceiling brought the business to a stop. On paper, they had the right person for the job — the IT project lead had actually been part of the original Oracle design team. In practice, the project team had made essentially no real progress in the previous year since the day it started.

This was my first real introduction to formal project management, and I want to be honest about how I handled it. I bought a handful of project management books, downloaded the PMBOK (Project Management Body of Knowledge), and spent a few weeks studying how to apply real discipline to the mess in front of me. What I found wasn’t a technology problem. It was a vision problem. The team didn’t know the systems well enough to design the migration properly, and their entire plan, if you could call it that, amounted to “we have to move to Oracle.” That’s not a vision. That’s a destination with no route.

We released the existing project team and started over. My head of technology found a bridging tool that would let our current applications run on Oracle with minimal changes — and that discovery reshaped the entire strategy into three clear moves: migrate current applications using the bridge, get the technology team formally trained on Oracle, and only then begin writing new applications natively on the new platform. We were moving from old flat-file data storage to a relational database, and from linear programming to object-oriented design — fundamental shifts in how a developer has to think, not just what tools they use. We invested heavily in training, removed the artificial timeline pressure that had been crushing the original team, and completed the migration successfully, without incident.

Credentials Aren’t the Same as Understanding

There’s a second half to this story that’s just as much a Learn-step lesson as the technical migration was. Digging into “how do we operate today” surfaced something uncomfortable: the original head of IT — the person who had originally written the legacy system — had spent years using his knowledge and control of the technology team as leverage. He’d already outlasted five general managers before I arrived. When I started asking the detailed, connect-the-dots questions this step requires, he escalated, staying home until I agreed to pay him and his team more. I told him the company couldn’t afford an increase, and that if he didn’t return the next day, I’d treat his absence as a resignation. He came back, without the raise.

That bought time, not a resolution. Shortly after, I let him go entirely. The board of directors was nervous — this was the one person who understood the legacy system inside and out — but I’d already identified his second-in-command as someone to trust, someone who clearly understood how inappropriate his boss’s behavior had become. We built a detailed plan, briefed the board, and called the outgoing IT head in to let him go. I followed him out to his car afterward, because I could see he intended to try recruiting the rest of the team to walk out with him. Once he realized I was watching, he left. We changed badge access, rekeyed the locks, and had the new IT lead close every system access point. We had no negative impact from the transition, and for the first time, I had a genuine partnership with IT leadership instead of a hostage negotiation.

A person who genuinely understands a system can walk you through it live, in real time, and answer a follow-up question they didn’t prepare for. A person running on reputation alone will start reaching for generalities the moment you ask them to get specific. That gap is one of the most reliable signals you’ll find in this whole business turnaround framework.

One Diagram, Four Threads: A Service Center Example

Let me show you what it looks like to actually weave the threads together on one diagram, because it’s a lot clearer with a real example in front of you than it is described in the abstract. I was working with a customer service operation handling inbound calls for a mid-sized insurance business. On paper, the process looked simple: a call comes in, an agent handles it, the call ends, the case is resolved or escalated. Leadership described it to me in almost exactly those four steps. That description wasn’t wrong. It also wasn’t remotely complete, and the gap between the two became obvious the moment I started drawing it with the team instead of just listening to the summary.

The process thread started clean enough — intake, triage, resolution attempt, close or escalate — but as agents walked me through an actual call, the boxes multiplied. Triage wasn’t one step. It was a decision tree with at least six distinct paths, most of which nobody had ever written down anywhere. The technology thread is where the first real gap showed up: agents were working across three separate systems during a single call, none of which talked to each other, requiring the same customer information to be manually re-entered into each one. Nobody in leadership had mentioned this, not because they were hiding it, but because they’d genuinely never watched a call happen from the agent’s seat.

The people thread surfaced something else entirely. A handful of senior agents had, over years, built their own personal shortcuts for the trickiest escalation paths — informal workarounds that weren’t written down and weren’t taught to new hires. Everyone else routed those calls to them informally, and nobody had ever measured how much the whole operation had come to depend on it. The customer thread tied the first three together: customers calling about the specific claim types that hit those undocumented workarounds had dramatically longer call times and a noticeably higher callback rate. Nobody had connected that customer pattern to the technical and process gap causing it until all four threads sat on the same page.

None of those four discoveries would have surfaced from any one thread alone. That’s the entire argument for weaving them together instead of mapping them separately in your own business turnaround framework: the value isn’t in any single thread. It’s in what only becomes visible where they intersect.

The Four Threads: Technology, Process, People, Customer

Once discovery is underway, Learn asks you to diagram what you’re finding, using a whiteboard before you ever open a formal tool like Visio — the wished-for-state trap is real, and drawing the current state first, messily, on a whiteboard, keeps you honest. I map every business I walk into along four threads: the technology involved, the process steps, the people performing each step, and the customer experience at every point of contact. I walked a claims-supervisor through her own workflow once, and when I asked what happened to a piece of paperwork after a certain step, she told me, honestly, “I think it goes in a folder.” That’s not a character flaw. That’s a fit problem — a skills gap in the role, not a judgment about the person in it — and the four-thread map is what surfaces it without turning it into a performance conversation before you’ve even understood the business.

What Happens When You Skip Learn

Skip this step, and you’ll be designing fixes for the org chart instead of the actual workflow — a map that looks tidy in a slide deck and explains nothing about why work actually gets stuck. The map belongs to no single function. It has to cross department lines the same way the work itself does, or it isn’t a real map of the business turnaround framework you’re trying to apply. It’s just a map of one department’s assumptions about itself.

Read the full guide: Learn — How to Turn a Pile of Interviews Into One Map Everyone Trusts

Step 3 of THE CLEARS METHOD™ Business Turnaround Framework — Evaluate: Find the Hidden Problems

Learn gives you the map. Evaluate is where you use it to find out, with real precision, why things are actually broken — not the symptom everyone’s pointing at, but the root cause underneath it.

The Five Percent Nobody Noticed

I was managing a large, multi-location call center operation when we acquired a competitor and needed to integrate their call center into ours. Their team transferred calls between two sites — call them Site A and Site B — as a routine part of daily operations, and as far as anyone there could tell, everything about that transfer worked fine. Nobody had a ticket open about it. By every account I got in discovery, it was a solved problem.

I didn’t take that at face value, because “nobody’s complained” and “nothing is wrong” are not the same statement, and conflating them is one of the more expensive mistakes a leader can make. I pulled the outbound call volume from Site A intended for Site B, and the inbound volume Site B was actually receiving, and put them side by side. They didn’t match. We were losing about five percent of calls in that transfer — not dropped dramatically, just vanishing silently, call after call, for who knows how long before anyone thought to check. Five percent doesn’t sound like much until you translate it into what it actually is: real customers who picked up the phone, got transferred, and got nothing.

Finding the gap wasn’t the hard part. Reconciling an output against an input is straightforward arithmetic once you decide to actually do it — the numbers had been sitting there the whole time. The hard part was tracing every one of those lost calls to find out exactly why they were disappearing, because “five percent are getting lost somewhere” is a symptom, not an answer. Once we traced the pattern down to its actual causes, we addressed each one and got calls arriving as intended, every time. There’s a critical lesson in this example – reconciliation is an important tool to ensure a business is truly operating as intended.

Symptom Versus Root Cause, and the Five Whys

A symptom is what you notice. A root cause is what’s actually producing it, and root cause is usually a chain, not a single event. The tool I lean on most for tracing that chain is the Five Whys — a technique with real roots in Six Sigma and lean manufacturing discipline, and one the American Society for Quality has written about extensively as a method for digging past the surface-level cause of a problem. You ask why, and then you ask why again about the answer you just got, typically five times, until you land on something you can actually fix instead of something you can only patch.

Other tools earn their place in the kit depending on the shape of the problem: a fishbone diagram when a symptom could plausibly have several unrelated causes and you need to organize the search; a Pareto chart when you’re facing a long list of possible causes and need to find which handful account for most of the impact; a Gemba walk — going to where the work actually happens — when the data alone can’t tell you what a five-minute walk down the hallway would show you in thirty seconds.

Gaps and Bottlenecks Are Different Animals

Two different failure shapes show up constantly once you start evaluating a business properly, and they call for different fixes, so telling them apart matters. A bottleneck generally traces back to one of three causes: the step before it moving faster than the current step can absorb, the step itself creating unnecessary internal delay, or unreliable tooling creating lag that piles up behind it.

My father owned and managed a small company, and he won a contract to supply materials to an apartment complex being built nearby. He bought all the iron and steel he’d need up front, financed through a bank loan, to lock in a fixed price. It looked like a smart, disciplined move. Then the construction schedule slipped. His materials sat, his loan payments kept coming due, and the income he’d counted on to cover the purchase wasn’t there yet, because the work that would have generated it hadn’t started. That’s a pacing bottleneck in its most human, most costly form — buying only what you need for the work directly ahead of you keeps revenue flowing and avoids tying up capital in inventory that isn’t moving yet. You’ll see the same dynamic on a factory floor: one station working quickly while work piles up at the next station because that station isn’t ready to receive the volume. Speed alone isn’t the goal. Pacing, matched deliberately across every step, is what keeps work flowing.

Gaps are a different animal entirely — usually a step that requires manually provided information, a place where the process depends on a person physically moving something from one system to another instead of the systems talking to each other directly. I was managing mobile roaming testing services at a company acquiring our top competitor. During due diligence, our M&A team was told about an impressive set of advanced service capabilities believed to be in their designed systems and platforms. Nobody knew to look underneath those claims to verify how they were actually delivered. Once we completed the acquisition, we found out: much of what had been presented as delivered ability was actually being provided through what’s sometimes called a sneaker net — someone saving information to a disk on one system, physically walking it across the floor, and loading it onto another, because the two systems had never been built to talk to each other. Despite that unpleasant discovery, we successfully integrated the acquired company within a year and retained ninety-five percent of their client base, using this same business turnaround framework.

A second common source of gaps is when operating procedures don’t actually match the work being performed. I had a customer service operation with persistently low quality scores, and when I dug into the root cause, I found new hires being handed a training manual that didn’t align with what the trainer was actually teaching, and the standard operating procedures on the floor didn’t match either the manual or the training. The system access provided to agents didn’t align with the SOPs either — they literally didn’t have the access needed to do what the procedure told them to do. Some of these agents had been on the job for thirty-five years. I conducted a knowledge assessment and nobody even the highly tenured people scored above thirty-five out of a hundred on the assessment. Nobody in that tenure had ever laid the training manual, the SOPs, and the system access side by side to check whether they still agreed with each other. That’s a broken knowledge chain, and once you start looking for it deliberately, you’ll find it hiding in more places than you expect. By the way, getting those tools and sources aligned is only the first step. They must then be maintained to ensure on-going alignment.

Watching It Work: Two Symptoms, One Cause

Let me put the whole diagnostic sequence together in one continuous example, so you can see the pieces working as a system instead of as separate tools. Picture a service operation with two visible symptoms: quality scores have been declining for months, and rework — work that has to be redone because it didn’t pass the first time — has been climbing over the same period. A leader moving too quickly might launch two separate initiatives: a quality coaching push for one, a process-efficiency review for the other.

Building the process map first, the way Learn requires, reveals something the two-initiative approach would miss entirely: both symptoms trace back through the workflow to the exact same handoff point, where a specifications document moves from the design team to the execution team. Following the Five Whys from the quality symptom: scores are dropping because execution teams are making inconsistent judgment calls on ambiguous specifications. Why are the specs ambiguous? Because the documentation template hasn’t been updated to reflect a product change made eight months earlier. Why hasn’t it been updated? Because no one owns the responsibility of syncing it.

Now follow the rework symptom down its own Five Whys chain, independently: rework is climbing because execution teams frequently redo work after the design team catches inconsistencies during final review. Why so late? Because the same outdated template is what execution teams are working from, so their output naturally drifts from what the design team intended. Why does that drift only get caught at final review? Because there’s no checkpoint between the initial handoff and the final review where the two teams reconcile understanding.

Both chains, run independently, land on the identical root cause: an unmaintained specification template with no owner responsible for keeping it synchronized with product changes. What looked like two unrelated problems reduces to one underlying cause once you actually trace both chains instead of treating each symptom as its own investigation. That’s the value this entire step exists to deliver in any business turnaround framework worth using: not two initiatives chasing two separate ghosts, but one clear, defensible root cause that Architect can actually build a fix around.

Read the full guide: Evaluate — How to Find the 5% Nobody’s Complaining About — and for more on the underlying technique, ASQ’s overview of root cause analysis is a solid companion resource if you want to go deeper on the formal methodology behind the Five Whys.

Step 4 of THE CLEARS METHOD™ Business Turnaround Framework — Architect: Design Fixes You Trust More Than Your Gut

Everything in Collect, Learn, and Evaluate builds toward this step. You understand the business, you’ve mapped how it flows, and you know — with real, traced confidence — why each gap and bottleneck exists. Architect is where that understanding finally becomes something you build. It’s also the step where your own confidence becomes the single biggest risk to getting it right.

The Test Results We Chose Not to Believe

We were designing a new IVR — an interactive voice response system — to automate a portion of our call center’s inbound volume. We built the design and tested it properly: real assumptions, real scenarios, a genuine process model instead of a hunch. The test results came back showing handle times and transfer rates that didn’t match what we had already decided, ahead of time, they would be. Instead of accepting what the test was telling us and adjusting our design, we explained the results away. We told ourselves the test was measuring something slightly off, that our operational experience knew better than a simulation.

The result was entirely predictable, in hindsight. When we went live, the real-world outcome matched the test’s predictions almost exactly — not our assumptions. We ran well over our planned operating costs and struggled with service levels until we finally made the adjustments the test had been telling us to make from the start. I’ve repeated some version of that mistake a couple more times over the years, which tells you how easy it is to make even when you know better. The honest answer for why it happened is that we weren’t lacking data. We were lacking the willingness to let the data cost us something in the moment — a delayed launch, an uncomfortable conversation with executives who’d already been told the project was on track.

Start With the Gaps, Then Design With the People Who’ll Live Inside It

Fix your gaps before your bottlenecks. A gap fix usually changes what information flows where; a bottleneck fix usually changes pacing, capacity, or process flow and applying a bottleneck-shaped fix to a gap-shaped problem — or the reverse — wastes real time and real trust. When you get to an actual design session, keep the group small, state the root cause you’re solving for at the very start of the meeting so the conversation doesn’t drift back to symptoms, and ask the room directly: “what would make this fail?” That single question surfaces more real risk in twenty minutes than a week of email threads.

Build the model before you build anything real. A spreadsheet that lets you test your assumptions against different volumes and scenarios costs you an afternoon. Skipping it costs you the mistake I just told you about. And once you’ve built and tested the model, choose your rollout method deliberately: a shadow run alongside the existing process, a small pilot, or a full rollout, depending on how much confidence your testing has actually earned you.

You Can’t Fix Everything: A Simple Way to Prioritize

I want to say something plain here that doesn’t get said enough: you will not get to every gap and bottleneck you’ve identified, at least not all at once, and pretending otherwise only frustrates you and everyone working with you. You will always have more requests than you have resources to deliver on, and a fair amount of what does get prioritized ends up shaped more by internal politics than anyone likes to admit. That’s not a failure of planning. It’s the actual shape of resource-constrained reality.

Given that reality, your job in Architect isn’t to design a perfect fix for every gap Evaluate surfaced. It’s to pursue the opportunities that matter most. I use three questions for every item on the list: how much is this actually costing in quality — errors, rework, dissatisfaction? How much is it costing in hard dollars — labor, materials, lost revenue? And how directly does it touch the customer’s actual experience, the way the five-percent call loss did? You don’t need a formal weighted spreadsheet. You need the discipline to ask those three questions honestly about every item, instead of defaulting to whichever gap is loudest in this week’s meeting.

Run your list through those three questions and you’ll often find the ranking that emerges isn’t the one you’d have guessed walking in. The bottleneck everyone’s complaining about loudest might turn out to carry almost no dollar impact and no direct customer visibility — annoying, but not actually expensive. The quiet gap nobody’s mentioned in months, the one you only found because you insisted on checking numbers that were supposedly fine, might be bleeding real dollars every day, specifically because nobody’s been watching it closely enough to complain. That mismatch between volume of complaint and actual cost is exactly what this exercise exists to catch.

Read the full guide: Architect — Why Smart Leaders Ignore Their Own Test Results (and How to Stop)

Step 5 of THE CLEARS METHOD™ Business Turnaround Framework — Run: Implementation Is a Discipline, Not an Event

Architect gives you a tested design. Run is where that design meets reality, and reality has a way of finding the one assumption you didn’t test.

The Automation That Broke a Team I Never Looked At

I was managing a company in South Carolina that included a large inbound call center providing financial card and cash transactions to its customers. Transactions were only about 45% automated, against an industry standard of 65% or better, so I knew there was real opportunity on the table. I entered into an agreement with the major point-of-sale provider in the industry, which would immediately give us a 20% increase in automation. On paper, this was a clean win. I had the primary measure nailed down cold.

Where I stumped my toe was in incorrectly assuming the impact on secondary measures — the adjacent processes that either feed into or receive output from the one you’re changing. The automation had a direct, primary impact on the inbound call center, and my assumptions worked out fine there: automation went up, inbound volume went down, exactly as modeled. But we also had a second-tier call group that received transfers from the inbound team, and I assumed their volume would decline in the same proportion. That assumption was wrong. Their volume was actually tied to overall financial transaction volume, not inbound call volume specifically. Once we implemented the automation, the second-tier group’s service level sank almost immediately, because I had understaffed them based on the wrong driver.

We corrected our modeling, recalculated staffing, and recovered service within about two weeks. But we recovered it after customers felt the pain, not before. That lesson has stayed with me for thirty-seven years, and I keep that lesson in my mind with every new engagement or challenge faced.

Predict the Impact, Have a Back-Out Plan, Test Small First

Before you implement anything, you should know, in writing, what you expect to happen to every metric that could plausibly move — not just the primary measure, but everything downstream, upstream, or adjacent to it. Build a back-out or recovery strategy before you go live, not after something breaks. And design an incremental first step — a trial, a pilot, a limited rollout — before you commit to the full implementation, because the gap between a model and reality always shows up somewhere, and you want to find it small.

Monitor It, Measure It, and Know What to Do If It Fails

Your monitoring plan during a live implementation needs to be tighter and faster than your everyday reporting. The biggest mistake I see leaders make here is monitoring the same metrics at the same weekly cadence the business is used to, which is nearly useless during an implementation window. Build the plan before you go live, not during: the full metric list in one place, a cadence that moves from weekly to hourly or real-time for the first 24 to 72 hours, one named person whose only job during that window is watching it, green-yellow-red thresholds agreed to in advance, and a communication line everyone’s tested before the incident, not during it.

Once you’re live, measure outcomes against what you predicted, side by side. If the results don’t match, decide with the same team that built the plan — not alone, not in a panic — whether the miss is material enough to back out or manageable enough to continue and monitor. And don’t let a result that beats your prediction go unexamined either. A metric that overperforms can mean your prediction model missed something, and that gap might be hiding a problem in a different metric you haven’t checked yet.

Sometimes, despite doing everything right, it fails anyway. When it does: back out using the plan you built in advance, not one you’re improvising in the moment. Then go back to Architect and ask a specific question — was the solution design flawed, or was the implementation choreography flawed? Those are different problems with different fixes. This is exactly why THE CLEARS METHOD™ is a method, not a straight line. A failed Run doesn’t send you back to Collect. It usually sends you one back to Architect, with better information than you had the first time, and then back through Run again. That loop between Architect and Run is, in my experience, the single most underappreciated part of this entire business turnaround framework. Leaders who haven’t internalized it treat a failed implementation as proof the whole approach was wrong. It isn’t. The method is built to absorb a failed Run and hand you straight back into Architect with more information than you started with.

Read the full guide: Run — Why Implementation Fails More Leaders Than Bad Strategy Ever Does

Step 6 of THE CLEARS METHOD™ Business Turnaround Framework — Sustain: Keep the Fix From Quietly Unraveling

Here’s a truth I’ve learned the hard way, more than once: a fix that isn’t monitored has an expiration date, even if nobody sets one deliberately. People move on, priorities shift, and the discipline that produced the fix quietly erodes unless something is actively holding it in place. In truth, there are so many small variables in each process it’s unlikely all of the combined variations are considered in the Architect and Run steps. It’s likely weeks, months, even years later some version of those variables cause a fail. Monitoring closely on-going is necessary.

Remember that five-percent call-loss reconciliation from Step 3, the one that found real customers vanishing silently in a transfer between two sites? Finding and fixing that gap wasn’t the end of the story. That same reconciliation check needed to become a permanent control mechanism once the fix was stabilized — something run quietly in the background, so the next miss gets caught before it costs five percent of anything for months on end without anyone noticing. That’s the whole discipline of Sustain in one example: don’t just close the gap and walk away. Build the thing that keeps it closed.

Sustain is where a business turnaround framework earns the right to be called permanent instead of a temporary rescue. It’s the step most leaders skip, because it doesn’t produce a visible win the way Architect and Run do — nobody throws a launch party for a control mechanism that quietly keeps working in the background. But skip it, and you’ll find yourself running the same turnaround again in eighteen months, on the same problem, because nothing was actually holding the fix in place once everyone’s attention moved on to the next fire.

Read the full guide: Sustain — How to Keep a Fix From Quietly Unraveling (coming soon)

Why This Business Turnaround Framework Works When Other Playbooks Don’t

Most of what gets called a turnaround strategy is really a set of financial levers — cut costs, refinance, restructure leadership — applied without ever answering why the business got into trouble in the first place. Research on turnaround leadership, including Harvard Business Review’s work on the psychology of turnarounds, has increasingly recognized that restoring an organization’s confidence in itself is just as vital to a real recovery as the financial and strategic decisions leaders make, and that’s a piece most cost-cutting playbooks miss entirely, because it can’t be captured on a spreadsheet.

THE CLEARS METHOD™ business turnaround framework works because it treats diagnosis as a discipline instead of an assumption. Collect forces you to gather the truth before you’re allowed an opinion. Learn forces you to see the whole system instead of one department’s version of it. Evaluate forces you to trace symptoms to their actual root cause instead of patching what’s visible. Architect forces you to trust tested data over confident instinct. Run forces implementation to be a discipline with predicted outcomes and a back-out plan, not a leap of faith. And Sustain forces the fix to survive past the moment everyone stops paying attention to it.

Every one of those disciplines is learnable. None of them require a title, a big budget, or a specific industry background. That’s the actual difference between this business turnaround framework and a consultant’s slide deck: a slide deck tells you what good looks like. This framework tells you, in order, how to get there.

There’s also an accountability built into this sequence that a lot of turnaround approaches quietly avoid: every step produces something you can point to and defend later, in front of a board, a boss, or your own team. Collect produces a sequence you can show someone before you start, not just a memory of who you happened to talk to first. Evaluate produces a traced root cause, not a hunch dressed up as a conclusion. Run produces a predicted-versus-actual table, not a vague sense that things went “pretty well.” When the fix works, you can explain exactly why. When it doesn’t, you can point to the specific step that needs correcting instead of throwing out the whole effort and starting over from a blank page. That kind of defensible clarity is rare in turnaround work, and in my experience it’s the single biggest reason this business turnaround framework holds up under real organizational pressure instead of collapsing the first time someone in the room asks a hard question.

How THE CLEARS METHOD™ Business Turnaround Framework Compares to Other Change Models

If you’ve spent any time around organizational change work, you’ve probably run into SWOT analysis, Kotter’s eight-step change model, or Six Sigma’s DMAIC cycle. All three are genuinely useful, and none of them are competitors to this business turnaround framework so much as tools that live inside it, in the right place, at the right step.

A SWOT analysis — strengths, weaknesses, opportunities, threats — is a snapshot. It’s a reasonable way to organize what you already believe about a business, but it has no built-in mechanism for verifying whether those beliefs are actually true, which is precisely the gap Collect and Learn are designed to close. I’ve watched leadership teams produce a confident, well-formatted SWOT analysis without ever leaving the conference room, and every quadrant of it was somebody’s opinion, not a traced fact. By the way, I’ve conducted SWOT analysis for a company as part of building a sales growth plan and it took weeks of research into the market, competitors, existing customers, and other elements of the products being sold.

Kotter’s model is strong on the organizational-change and communication side — creating urgency, building a coalition, communicating the vision — and if you’ve read Step 1 of this business turnaround framework closely, you’ll notice real overlap with how I talk about setting the stage with a new organization. Where Kotter’s model stays largely silent is on the diagnostic front end. It assumes you already know what needs to change. THE CLEARS METHOD™ doesn’t make that assumption, because in my experience, that assumption is exactly where most turnarounds go wrong before they even start.

DMAIC — Define, Measure, Analyze, Improve, Control, the backbone of Six Sigma — actually maps fairly closely onto Evaluate, Architect, and Run inside this business turnaround framework, and if you have Six Sigma training, you’ll recognize plenty of its DNA in Steps 3 through 5. What DMAIC doesn’t formally include is anything resembling Collect or Learn as I’ve described them here — the deep, function-by-function discovery work that happens before you ever define a problem statement. DMAIC is often applied to a problem someone has already identified. THE CLEARS METHOD™ exists partly to make sure the problem someone identified is actually the right one before a single DMAIC cycle gets spent on it.

In my own experience, each of these tools is useful and should be used in the right context, but each is incomplete, I believe. None of that makes those other tools wrong. It’s why I built a business turnaround framework that gives each of them a specific, sequenced home rather than treating any single one as the whole answer.

7 Warning Signs Your Business Needs This Turnaround Framework Right Now

You don’t have to be staring down bankruptcy to benefit from applying this business turnaround framework. In fact, the earlier you apply it, the less dramatic the fix usually needs to be. Watch for these seven signs:

Nobody’s complained about a process in a long time, and everyone assumes that means it’s fine. As you saw in Step 3, absence of complaint is not evidence of correctness — it’s evidence that nobody’s checked closely enough to complain yet.
Your best-known employee is also your biggest single point of failure. If one person’s departure would genuinely stall the business, that’s not a compliment to their value. It’s an unmanaged risk sitting in plain sight.
Projects keep launching on schedule and then requiring emergency fixes within weeks of go-live. That pattern almost always traces back to a skipped Architect or Run step — a design that was never properly tested, or an implementation with no predicted-impact model behind it.
Credentials get treated as proof of understanding. If your team defers to a resume instead of asking someone to show their work live, you have a Learn-step blind spot waiting to surface at the worst possible time.
You can’t say, with real confidence, what the root cause of your last three recurring problems actually was. If the honest answer is “we patched the symptom and moved on,” Evaluate hasn’t happened yet, no matter how many times the symptom has been “fixed.”
A fix that used to work has quietly stopped working, and nobody can say exactly when. That’s a Sustain failure — a control mechanism that either was never built or was built and then abandoned once the crisis passed.
Every new leader who walks in starts making changes within the first week. If that’s the pattern in your organization’s history, you’re watching the gorilla instinct win out over the sponge, over and over, and it’s costing you the trust every future turnaround will need to draw on.

Real Results This Business Turnaround Framework Has Actually Delivered

I’d rather show you numbers than adjectives, so here’s a plain accounting of what following this business turnaround framework, in sequence, has actually produced across the stories in this article:

Dakota Imaging (Collect): retained its largest customer, won back previously lost accounts, and moved from losing money to profitable within a year.
The South Carolina Oracle migration (Learn): completed a full platform migration — flat-file to relational, linear to object-oriented — without incident, after a prior attempt had stalled completely.
The Site A/Site B call transfer (Evaluate): closed a silent five-percent call loss that had been running undetected for an unknown period of time.
The competitor acquisition (Evaluate): integrated the acquired company within a year and retained ninety-five percent of its client base, despite discovering the “advanced capabilities” it was buying were a manual sneaker net.
The point-of-sale automation (Run): recovered a service-level miss in about two weeks once the correct secondary-measure driver was identified and staffing was corrected.

None of those outcomes required a large consulting engagement. Every one of them came from applying the same six-step sequence, in order, to a specific real problem.

A Quick Self-Assessment: Where Does Your Business Stand Right Now?

Before you move on, take two minutes and answer these six questions honestly. Each one maps to a step in this business turnaround framework, and a weak answer tells you exactly where to start.

Collect: Could you name, right now, the order you’d talk to people in if you had to understand a struggling part of your business by Friday? If not, start there.
Learn: Do you have an actual, current map of how work flows through your organization — technology, process, people, and customer, on one diagram — or only an org chart?
Evaluate: For your most persistent recurring problem, can you state its root cause in one sentence, traced back through at least three “whys,” or only describe its symptom?
Architect: The last time you designed a fix, did you test it against real data before building it, or did you trust your team’s operational instinct over the model?
Run: Does your last major implementation have a written prediction of what should have happened to every adjacent metric, or only the primary one, or any prediction?
Sustain: Is there a fix from the last two years that you now suspect has quietly stopped working, and nobody’s checked, or, worse, do you know?

If two or more of those questions gave you an uncomfortable answer, that’s not a bad sign. It’s useful information, and it’s exactly the kind of information this business turnaround framework is built to act on. Write your answers down, date them, and revisit them again in ninety days. You’ll either confirm you were right to be concerned, in which case you now have a documented starting point for Step 1, or you’ll find the concern resolved itself once you looked closer, in which case you’ve lost nothing but a few minutes of honest reflection.

Applying This at Any Size: Small Business vs. Enterprise

One question I hear constantly is whether this business turnaround framework really works the same way at a twenty-person company as it does at an organization with five thousand employees. The honest answer is: the sequence stays identical, but the shape of each step changes with scale, and knowing what changes helps you apply it correctly for your own company size.

In a small business, Collect might take a week instead of ninety days, and you might be the one personally conducting every conversation instead of delegating pieces of it to a team. The four-thread map from Learn might fit on a single whiteboard instead of requiring a cross-functional working session with a dozen department leads. That’s a feature, not a limitation — a smaller organization has fewer layers between the leader and the truth, which is exactly what Collect is trying to get you closer to in the first place.

In a large enterprise, the opposite challenge shows up: the sequence is the same, but each step requires more coordination to execute well. Learn’s four-thread map might need input from technology, operations, HR, and customer experience teams that rarely talk to each other directly, which means someone has to own pulling those threads onto one shared diagram instead of letting each function keep its own separate version. Architect’s design sessions need tighter scoping, because “small group” starts to mean something different when the fix touches six departments instead of two. And Run’s monitoring plan needs a genuinely dedicated owner, not someone squeezing it in between other responsibilities, because the blast radius of a failed rollout is simply larger.

What doesn’t change, at either end of that spectrum, is the sequence itself. I’ve used this exact business turnaround framework at a twelve-million-dollar software company and at operations running more than five thousand people, and the six steps never needed to be reordered, only rescaled. That’s the actual test of whether something deserves to be called a framework rather than a one-off playbook: does it hold its shape when the company around it changes size. This one has, every time I’ve applied it.

Who’s Behind This Business Turnaround Framework?

I’ve spent the better part of forty years running operations and leading turnarounds — call centers, software companies, manufacturing lines, financial services operations, telecommunications carriers — in roles ranging from head of the company to senior operations executive to transformation lead. I didn’t build THE CLEARS METHOD™ business turnaround framework in a classroom or a consulting practice. I built it the way most durable things get built: by doing the work, noticing what actually worked across wildly different industries, and writing down the pattern once it became too consistent to ignore. Every story in this article happened. I’ve changed a few names and details where it mattered for privacy, but the mistakes, the numbers, and the lessons are real, because I lived through every one of them.

How to Start Using This Business Turnaround Framework This Week

You don’t need to wait for a crisis, and you don’t need executive sign-off on a six-month engagement to start. Here’s how to begin applying this business turnaround framework. The time required depends on the size and complexity of your business.

First: pick your sequence for Collect, and write it down before you start. Decide who you’re talking to and in what order — leadership, current customers, departed customers, the frontline — before you let convenience decide it for you.

Second: go collect, and resist the urge to fix anything you hear. Keep a running “not yet” list of every fix you’re tempted to make on sight. You’ll revisit it later, and you’ll be glad you didn’t act on all of it.

Third: draw your first whiteboard map. Don’t wait until you’ve finished Collect entirely — start sketching the four threads as you go, technology, process, people, customer, and let the map get messier before it gets cleaner.

Fourth: Involve the knowledge workers to understand where there are gaps and bottlenecks.

None of that requires a consultant. It requires the discipline to follow the sequence in order, and to trust the process even when a shortcut looks tempting. That’s the whole promise of this business turnaround framework: not magic, just a refusal to skip steps.

Every Tool in This Business Turnaround Framework, in One Place

If you’d rather build your own toolkit than take my word for any of this, here’s every tool mentioned across all six steps, gathered into one reference list:

The sequence list (Collect). Who you’ll talk to, in what order, written down before discovery starts — leadership, current customers, departed customers, the frontline, function by function.
The “not yet” list (Collect). Every fix you’re tempted to make on sight during the first ninety days, logged instead of acted on, revisited at day ninety.
The will-or-skill test (Collect). Ask the same clarifying question twice, worded differently, a few minutes apart. A skill problem produces a consistent answer both times. A will problem doesn’t.
The four-thread whiteboard map (Learn). Technology, process, people, and customer, drawn together on one diagram, current state first, before you touch a formal diagramming tool.
The Five Whys (Evaluate). Ask why, then ask why again about the answer, typically five times, run independently for each symptom before comparing chains.
The gap-versus-bottleneck check (Evaluate). Pacing, internal delay, or unreliable tooling for a bottleneck; a manual hand-off or a misaligned knowledge chain for a gap.
The design-session playbook (Architect). Small group, root cause stated first, “what would make this fail” asked out loud, a spreadsheet model tested before anything real gets built.
The three-question prioritization (Architect). Quality cost, hard-dollar cost, and customer impact, asked honestly about every item on your list, gut-instinct ranking compared against the evidence.
The one-page dependency worksheet (Run). Adjacent process, believed volume driver, confidence level — anything below high confidence gets a named owner before go-live.
The monitoring plan (Run). Metric list, cadence, owner, green-yellow-red thresholds, and a tested communication line, built before go-live and dry-run in advance.
The permanent reconciliation control (Sustain). The same check that found the original gap, kept running quietly in the background so the next miss gets caught early.

Frequently Asked Questions About THE CLEARS METHOD™ Business Turnaround Framework

What is THE CLEARS METHOD™ business turnaround framework? THE CLEARS METHOD™ business turnaround framework is a six-step, repeatable process for diagnosing and fixing struggling organizations: Collect, Learn, Evaluate, Architect, Run, and Sustain. It was built over forty years of hands-on turnarounds across software, call center, manufacturing, telecom, and financial services businesses, and it’s designed to work regardless of industry because it focuses on how organizations actually function rather than on industry-specific tactics.

How long does a business turnaround framework take to show results? It depends on the size and complexity of the organization, but the discipline itself calls for patience early on — a solid ninety days to genuinely understand the business before major changes get made, with the rare exception of a problem serious enough that it can’t wait. Most of the stories in this article showed measurable improvement within a year, and some, like the point-of-sale staffing correction, recovered within about two weeks once the actual root cause was identified.

Do I need a big team or a consulting budget to use this business turnaround framework? No. Every tool described in this article — the whiteboard map, the Five Whys, the dependency worksheet, the “not yet” list — can be built by one person with a notebook and the discipline to follow the sequence. The framework scales up to organizations with thousands of employees, but it doesn’t require that scale to be useful.

What’s the difference between a bottleneck and a gap in a business turnaround framework? A bottleneck is a pacing or capacity problem — work piling up because one step can’t absorb what’s arriving from the step before it. A gap is usually a missing connection — information that depends on a person manually moving it between systems that were never built to talk to each other. They require different fixes, which is why Step 3, Evaluate, spends real time teaching you to tell them apart before you move into Architect.

Why does this business turnaround framework put Collect and Learn before any actual problem-solving? Because the single most expensive mistake in a turnaround is solving the wrong problem confidently. Every fix you design in Architect depends on the root cause you traced in Evaluate, which depends on the map you built in Learn, which depends on the truth you gathered in Collect. Skip ahead, and you’ll build a technically excellent solution for a problem that was never the real one.

Can this business turnaround framework be applied to a healthy business, not just a struggling one? Yes, and in some ways it’s more valuable there. The seven warning signs listed earlier in this article — an employee who’s a single point of failure, a fix nobody’s monitoring, credentials substituting for demonstrated understanding — show up in healthy businesses just as often as struggling ones. Applying this business turnaround framework proactively usually means a smaller, cheaper fix than waiting until the warning signs turn into a genuine crisis.

How is this business turnaround framework different from Six Sigma or DMAIC? DMAIC maps closely onto the second half of this business turnaround framework — Evaluate, Architect, and Run share real DNA with Define, Measure, Analyze, Improve, and Control. What THE CLEARS METHOD™ adds is the front end DMAIC generally assumes has already happened: Collect and Learn, the deep, function-by-function discovery work that establishes whether the problem you’re about to run through a DMAIC cycle is actually the right problem in the first place.

What happens if a step in this business turnaround framework fails partway through? It happens, even with discipline. A failed Run doesn’t mean starting over at Collect. It usually means returning one step to Architect, determining honestly whether the design was flawed or the implementation choreography was flawed, correcting what you learned, and running again with better information. That loop between Architect and Run is built into the framework on purpose — it’s a feature, not a sign that the approach has failed.

The Bottom Line

I’ve used this business turnaround framework for forty years, across industries that had almost nothing in common on the surface — health insurance software, call center operations, manufacturing, telecommunications, financial services. What they had in common underneath was this: every one of them got fixed the same way, in the same order. Collect the truth before you diagnose. Learn the whole system before you evaluate a piece of it. Evaluate the root cause before you architect a fix. Architect a solution you’ve actually tested before you run it. Run it with a predicted impact and a back-out plan, not a leap of faith. And sustain it, deliberately, so the fix outlives the crisis that produced it.

None of that is complicated. All of it takes discipline, applied in order, especially in the moments when skipping a step feels faster. I promise you it isn’t faster. It’s just a bill that comes due later, usually with interest, the way it did for me more than once across four decades of learning this the hard way.

If you take one thing from this entire article, take this: the businesses I’ve turned around didn’t get fixed because I was smarter than the people already working inside them. Much of the time, I wasn’t. They got fixed because I refused to skip steps, especially the unglamorous early ones, even when skipping them would have felt faster and looked more decisive in the moment. Decisiveness that skips Collect and Learn isn’t leadership. It’s a guess wearing a leadership costume, and the businesses in this article paid real, measurable costs whenever that guess turned out to be wrong. Discipline, applied in the right order, is slower at the start and faster by the end, every single time I’ve tested that trade-off across four decades of doing this work.

Start with Step 1. Go collect.

Ready to go deeper on any single step? Start with Collect, or explore the full six-step guide series linked throughout this article.

Table of Contents