Scoping — Deciding what's in scope before anyone talks about software

This is the second chapter of Inside a Large ERP Program, a white paper that walks a full implementation phase by phase. The opening chapter set out the triple lens this document reads every phase through: the technical, the business, and the organizational. Here the walk begins where every program begins, with scoping, the phase that decides almost everything before anyone has talked about software.

Eighteen months into a program, well past the go-live of the core model, the group handed down a decision nobody in the original scoping room had any reason to expect. The in-house timesheet tool, homegrown and working and integrated, was out. A group-wide external solution was in, mandatory, and it had to land during the first rollout, which was already underway.

So we built a second core model. Not for finance, not for logistics. For timesheets. A whole design-build-test loop bolted onto a program that had already scoped itself, costed itself, and signed off on a plan. The plan had no room for it because the plan had never imagined it.

That timesheet decision felt like an external shock, a thing that fell out of the sky onto a well-run program. It wasn't. The specific tool, no, nobody could have called that. But the category of risk, the fact that a group can reach into a running program and reorder its scope, was visible to anyone who had lived through a multi-entity rollout before. The scope wasn't wrong. The problem was who sat in the room when the scope got written.

The declared scope is always the surface

Scoping produces a list of objects. "Financial close." "The target landscape." "Project time recording." Everyone nods, the slide gets approved, the business case quotes a number. What the list almost never contains is the depth of each object, and the depth is where the work actually lives.

Take the close. The scope said "financial close," and the cockpit promised a faster one. What it did not cadre was the depth of the reclassification flows underneath that close: the manual postings that move amounts onto the right cost objects, the magnitude of them, and the fact that the automated program meant to replace those manual entries wasn't going to arrive until later in the year. So at go-live the close worked, in the sense that it closed. But it closed on manual reclassification entries nobody had scoped, carried by people doing them by hand, with the real automated flow pushed months downstream. The object was on the list. Its depth was not. And a close that runs on undocumented manual postings is not the close anyone thought they were buying.

The timesheet was the same failure wearing different clothes. "Project time recording" got scoped as a thing that existed and worked. Its depth, the fact that it sat on a homegrown tool the group could overrule, the integration surface it would expose if anyone ever had to swap it out, never came up. You can list every object in a landscape correctly and still lose the program, because the program gets killed by the depth of the objects, not by the ones you forgot to name.

That's the mechanism. Listing scope and scoping its depth are two different acts, and most scoping does only the first.

Who is in the room

So why does the depth go missing? Look at who writes the scope.

On the business side, the scoping team is almost always light and senior. You get heads of function, transformation leads, people who can speak to strategy and sign a slide. What you don't get, reliably, are the doers, the management accountant who knows exactly which reclassifications run at close and why, the accounts-payable clerk who knows the three exception flows that don't fit the standard. The people who hold the depth in their hands aren't in the room where the depth is supposed to get scoped.

The solution side mirrors it. Scoping is often led by management consultants rather than functional SAP consultants, and that distinction matters more than it looks. A management consultant can structure a workshop, build the business case, run the governance. What they generally cannot do is see the trap, look at a process and know, from having configured it before, where the standard breaks, which flow hides a depth the client hasn't mentioned, which "simple" object is one decision upstream from needing a second core model. The pitfalls worth digging into during scoping are obvious to someone who has lived a close. They're invisible to someone whose deepest contact with the system is a fit-gap template.

Put those two together and you get the thesis of this chapter, stated plainly. The composition of the scoping team is the real scope. Staff the room with senior generalists and you scope the senior, generalist layer, by construction. The blind spots aren't random. They're exactly the things a doer would have caught and a generalist can't.

And the people who scope don't stay

There's an aggravating factor that turns a staffing mismatch into a structural one.

The organizational consultants who run scoping tend to leave early. They cadre the program, hand over the deck, and roll off before build starts. Which means the people who decided the scope aren't the people who'll live inside it. No feedback loop. No accountability of the scoper to what they scoped. By the time the depth surfaces, eighteen months on, and the plan has no room for it, nobody who made the surface-level call is still around to answer for it.

Compare that to how it should work and rarely does. The person who scopes a flow ought to be close enough to its delivery to feel the consequence of getting it wrong. When scoping is a phase that specialists pass through on the way to the next engagement, that loop is cut at the design stage. The scope gets written by people optimizing to finish scoping, not to deliver the thing they scoped.

What scoping decides technically without knowing it

At scoping you build nothing. No system yet, no transport, not a line of config. Which makes it tempting to treat scoping as a pre-technical phase, strategy and business cases now, the real work later. That's the trap.

Scoping makes technical decisions constantly. It just makes them by default, through omission, by people who don't recognize them as technical. Every peripheral application that doesn't make the scope is a technical decision: you've decided, silently, that there's no integration to build there. Until there is. Every interface left unmapped, every local-specific flow nobody surfaced, is a technical commitment made by not making it. The timesheet swap was a technical decision the scoping room made without knowing it, the day it assumed project time recording was settled and would stay settled.

These aren't risks that appear during build. They're decided at scoping and merely discovered during build. The difference matters, because you can't fix at build a decision that was foreclosed at scoping by people who didn't know they were deciding anything.

What it costs when the off-scope comes back

When the depth surfaces, and it always surfaces, the cost doesn't land where the business case can see it.

It lands as overtime first. The team absorbs the unscoped work by working longer, because the plan has no slack. Then it lands as a degraded go-live: things ship before they're ready, because the unscoped depth ate the time that would have made them ready. And then it lands in the place no scoping slide ever models, the people. Sustained overtime on a program that keeps discovering work it should have known about produces stress, and stress on a delivery team produces turnover. You lose the people who hold the institutional knowledge, mid-program, at the moment you can least afford to.

That last cost is the one that compounds. A missed interface is a line item; you can quantify it and recover. An eroded team isn't a line item. The judgment walks out the door inside the person, and the next hire scopes from an even shallower base than the one that caused the problem.

The phase that decides everything, staffed like it decides nothing

The instinct is to treat scoping as the light phase, the strategic warm-up you hand to generalists before the serious people arrive for build. That instinct is backwards. Scoping is where the real scope gets decided, which makes it the phase that most needs the people who can see the depth: the doers from the business who know what runs underneath each named object, and at least one functional consultant who has configured the thing before and knows where it breaks. Not after the scope is written. In the room while it's being written, and still accountable through delivery instead of gone by build.

The scope you can read on a slide describes the surface. The real scope is the depth nobody wrote down, and the only defense against it is to put the people who hold that depth in the room before the slide gets approved. Get the room right and the periphery, the unmapped interface, the reclassification depth that runs on manual postings, the group-level swap that's always possible, all show up as questions during scoping instead of as shocks a year and a half later.

You decide the fate of the program here, before anyone has opened the software. Most programs decide it by accident, through whoever they happened to put in the room.

Once the real scope is on the table, depth and all, the next decision is who you choose to deliver it with, and how you write the contract that binds them. That's where the next chapter goes: Selection — Choosing the vendor, the integrator, and the contract.