So in my Key person of influence (KPI) branding position O sort of come up with this acronym
4. Core Methodology: The S.C.A.L.E. Framework
Ash utilizes a proprietary diagnostic process to transition a business from a "Daily Firefight" to a "Scalable Engine":
Simplify: Removing friction points and "dead wood".
Clarify: Defining value streams that deliver actual profit.
Assess: Evaluating the "critical few" leverage points.
Leverage: Transitioning from manual tasks to system-driven value.
Execute: Bridging the gap between high-level strategy and practical reality.
Does this fit with what I am writing about in my book do you think?
Yes, S.C.A.L.E. is very aligned with what you’re writing about – it’s basically the same spine you already have, just packaged in a reader-friendly acronym that fits your “making the complex simple” promise. How it fits the book
Same core steps: Your book and positioning already describe a journey of Simplify → Clarify → Assess → Leverage → Execute as the process you take SMEs through to untangle complexity and scale. Matches the narrative arc: The transition from “Daily Firefight” to “Scalable Engine” mirrors the core transformation of the book: from messy, complex operations to a streamlined, scalable business model. Consistent with your tools and PDCA: S.C.A.L.E. sits neatly inside your broader PDCA mindset – Simplify/Clarify/Assess is largely Plan/Do/Check, and Leverage/Execute is where you Act and lock in change. Where it’s especially strong
Brand clarity: It gives you a simple, memorable label for the methodology that already underpins your ICP, offers, and the book structure. Positioning as KPI: “The S.C.A.L.E. Framework” reinforces you as the person that turns chaotic SMEs into scalable engines – it’s concrete enough to feel real, but flexible enough to apply across your toolkit of 20+ frameworks. A couple of small tweaks you might consider
Make sure “Assess” explicitly nods to root cause analysis and leverage points (so readers connect it to your root-cause chapters, not just a light review). In the book, you can show how S.C.A.L.E. loops with PDCA (e.g. each S.C.A.L.E. pass is one iteration of PDCA applied to the business model), so it feels integrated rather than “yet another framework”. Would you like to make S.C.A.L.E. the explicit through-line of “The Process” chapter, or keep it more as your personal consulting brand and only lightly referenced in the book?
You’re right to question the order; if it feels off to you, it will feel off to readers too. The good news: your instinct (RCA as part of Plan) is solid, and we can tidy the mapping without breaking S.C.A.L.E. or PDCA.
1. How PDCA is usually grouped
In practice, most continuous improvement people treat PDCA like this:
Plan = understand the problem, analyse causes, choose what to try (so RCA fits here). Do = run the change / experiment. Check = look at the results vs the goal. Act = standardise what worked or adjust and loop again. So your suggestion to move Assess into Plan is entirely aligned with how PDCA is commonly used.
2. A cleaner mapping that respects your flow
Given how S.C.A.L.E. actually feels when you use it, I’d suggest this alignment:
Plan = Simplify + Clarify + Assess Simplify: What are we really trying to achieve, and what obviously doesn’t belong? Clarify: How does the work actually flow to create that result (value streams)? Assess: What’s really going on in those flows; what’s the root cause, where are the leverage points? All of that is “thinking before doing”, which is classic Plan. You run experiments, try new ways of working, test tech or process tweaks. Check = (still part of Leverage / bridge into Execute) You look at what happened in those experiments: did the leverage actually move the needle? In practice, you usually design the “how we’ll check” as part of Leverage, then review results before fully executing. You lock in what worked (SOPs, standard work, governance, training), or adjust and go again. So instead of trying to force a 1:1 letter-to-letter match, you can be explicit that PDCA sits at a different “zoom level”:
Do + Check = L (design → test → review) That’s simple to explain and honest about how you actually work.
3. Updated mapping table
Here’s a revised table that matches your thinking more closely:
And you can make that explicit with one line in the text, e.g.:
“If you’ve used PDCA before, you’ll notice that Plan in S.C.A.L.E. is where we Simplify, Clarify and Assess, Leverage is where we both Do and Check what works, and Execute is where we Act to lock the change in.”
That way you:
Keep S.C.A.L.E. intact and intuitive. Honour PDCA without contorting your steps into an unnatural order. Avoid adding complexity or “framework salad” for the reader. Does this grouped mapping (Plan = S+C+A, Do+Check = L, Act = E) feel closer to how you actually think and work with clients?