
By this point, if you've been following this series, you've built something meaningful. You understand why fundamentals matter and you've done the work to establish them. You've developed a more honest, rigorous relationship with your vendors and partners, one based on scrutiny rather than hope. You've stress-tested your assumptions and done real due diligence, not just the ritualized version.
That's a strong foundation. But there's one more question most organizations get wrong, and it's deceptively simple: How big is this change, really?
Most transformation plans contain an implicit assumption about scale that was never explicitly examined. The initiative was scoped based on the original vision, then refined based on budget constraints and political considerations, and what emerged may have very little relationship to what the change actually requires across the full organization.
Teams underestimate scope for predictable reasons: they scope from the center outward rather than the edge inward, they think about the technology rather than the people and processes it touches, and they plan in silos rather than mapping the full connected system of changes.
Scale needs to be examined after you've cleared the trust issues, not before, because scale assessments done in the wrong relational environment are almost always wrong. Vendors will scope conservatively in the proposal to win the deal. Internal teams will scope conservatively to avoid making the business case look expensive. And everyone will unconsciously exclude the parts of the organization that are politically difficult to include.
Once you've built the habits of honest assessment and rigorous scrutiny that the previous section was about, you're in a much better position to do a scope analysis that reflects reality rather than convenience.
The next category is about getting the scale right before you commit to a plan. That means mapping who this change actually touches:, systems, people, processes, partners. It means understanding why successful pilots so often fail to predict enterprise outcomes. It means honestly assessing the human change curve, which is almost always longer and steeper than the technology deployment curve.
And it means building a plan that's actually sized to the change you're making, not the change you wished you were making, or the change you could afford, but the actual change in front of you.
Because a plan that's too small for the problem is just a slow path to the same place you started.