Eighteen months after go-live, someone finally asks for one consolidated growth number, and finds out nothing rolls up that far. A requirement existed. It just never accounted for the layer of manager who'd actually need to run that report. Now it's a change order, instead of a decision that should have happened for free.
That's not a reporting inconvenience. That's a sales leader who can't see growth across every account underneath them without someone quietly rebuilding the rollup by hand in a spreadsheet every quarter. No system does that work. A person does, manually, and calls it consolidation.
In the FORGE Frameworkâ˘, Filter already decided this initiative was worth the organization's time. Objective did two things after that: measured where performance stands today, mapped the process end to end. Root comes next.
Its job: take that map and that baseline and actually use them. Locate where performance breaks down. Diagnose why. Name what the process needs to close the gap.
Not select a system. Not compare vendors. Define the need.
That distinction gets lost constantly. Most rooms skip straight from "here's the map" to "what do you want the new system to do," and Root never actually runs in between.
What Root Is Supposed to Produce
Root's output isn't one thing. It's two, paired: a named business capability, and one or more requirements underneath it.
The capability is the umbrella, the thing the organization needs to manage well: order-to-cash, forecasting, customer and master data. Likely the same capability already sitting on the map from Objective, sharpened now that Root has actually looked at where it breaks. The requirement sits underneath, narrower, more specific: the precise, testable thing the process needs in order for that capability to actually work. One capability can carry several requirements beneath it, each traceable back to its own piece of the baseline.
Worth being precise about which layer this sits at, because the imprecision is exactly what causes trouble later. TOGAF draws a clean line: a business capability is what the organization does, measured in process terms, cycle time, defect rate, forecast accuracy. A software or application capability is what a platform does, measured by whether a feature exists and how it's configured. Root stays entirely on the business side. It has no view into any system yet. Deliberately.
Why "What Do You Want the System to Do" Skips This
Ask someone what they need and what comes back is usually a feature: a faster approval button, one less field, a report that already exists somewhere else. That's a want. Filed as a requirement anyway, no distinction drawn between the two.
A requirement, properly, is a determination, what the process actually needs to deliver as expected, grounded in the diagnosed gap. A feature is a mechanism someone believes will help. The two get treated as identical because nobody asked the question sitting between them: does the process actually require this, or does someone just want it.
"A feature answers what would make this easier for me. A requirement answers what the process actually needs to hit its target. Root exists to produce the second one before anyone's allowed to hand over the first."
The SME's Role, and Its Limit
Every serious Root effort leans on subject matter experts, usually more than one, and it should. That's not where this goes wrong. Where it goes wrong is what their input gets mistaken for.
What SMEs have is working knowledge: how the work gets done today, workarounds included, built to keep output moving despite whatever's broken upstream or downstream. Real expertise. Root cannot run without it, they're the fastest way to find out where it actually hurts. With more than one SME in the room, that rarely arrives as a single, agreed-upon story. One describes the pain as a data problem, another as a timing problem. Both accurate to their own vantage point. Neither the full picture on its own.
What they don't have, through no fault of their own, is the diagnosis behind the pain. They can tell you the approval step is slow. They usually can't tell you why, because working knowledge answers what's happening, not why. Their accounts locate where the gap lives. Reconciling those accounts into a diagnosis, and turning that into a requirement: that's Root's job. Not theirs.
Where the friction actually lives, day to day, though rarely the same story twice once more than one SME is in the room.
Why the gap exists, or what the process precisely requires to close it. That's root cause work, reconciling accounts included, not an interview.
Naming the Need: The Customer Hierarchy Example
The capability, at the umbrella level, is managing customer information and master data. That capability sits on plenty of organizations' maps already, and it sounds solved. Most platforms handle "customer data" in some form. That's exactly the trap.
Root cause work on why regional reporting kept breaking down turned up something narrower: the process needed to capture a customer's full hierarchy, parent account down through global region, region, state, to individual office location, several levels deep, rolled up cleanly at every one of those levels. That's the requirement. Not "improve customer data." Not "give us better reporting." A specific, traceable statement of what the capability actually requires to hit its target.
No claim gets made here about whether any given ERP or CRM can do this. That's not Root's question yet. What Root owes Generate is something sharper than "the system should handle hierarchy better": a concrete depth, up to eight levels, given how this organization is actually structured today, and a stated need for the structure to absorb new levels later, a new region split, a new sub-territory, without a rebuild. Depth alone ages badly. An organization that looks eight levels deep today rarely looks the same in three years.
Skip this discipline and the cost doesn't show up at go-live. It shows up eighteen months later, when the country account manager asks for one consolidated number and finds nothing rolls up that high, because region and state were built into the hierarchy and country never was. What that manager actually loses is visibility into growth across every account beneath them, replaced by whoever gets stuck rebuilding the rollup by hand each quarter.
Managing customer information and master data.
Capture and roll up customer hierarchy across parent, global region, region, state, and office location.
Where This Sits at the Capability Gate
The Capability Gate between Root and Generate holds the line the framework has always held: nothing gets selected, configured, or built until root cause is evidence-confirmed. What crosses that gate isn't a feature list and it isn't a capability verdict on any system. It's a named capability, paired with requirements specific and traceable enough to test.
Generate takes it from there. Fit-gap analysis, vendor evaluation, configuration decisions, all of it belongs on the other side of the Gate, applied against a requirement Root already defined. Not against a want someone raised in a workshop before anyone asked why.
Root doesn't ask what a system can do. It defines what the process requires, so that question can be asked correctly later.
A capability named without a requirement beneath it is still a hope. A requirement defined without root cause behind it is still a guess. Root's job is closing both gaps before anything crosses toward Generate.
Next time a capability shows up on a map looking already solved, ask what the requirement underneath it actually says. Most of the time, nobody's written it down yet.
If you lead sales, finance, or operations rather than the initiative itself: the requirement your team signed off on can be completely accurate and still incomplete, and you won't find out until someone downstream needs the piece nobody asked about. Next time someone says a requirement was missed, the useful question isn't whose fault it was. It's why it was never captured in the first place, and whether anyone asked before the money was committed.
Part of an ongoing series on operating model design, process transformation, and what it takes to make change endure.