Big-Bang or Phased Is the Wrong Argument. Here's the One That Decides the Outcome.

This is the first of four articles in the series "Default Is a Decision," on the trade-offs that settle an ERP program's fate before anyone goes live. The thread running through all four: the choices nobody treats as choices are still choices, and the program pays for them either way. This one starts with the one everybody does argue about, and shows why it's the wrong argument.

A steering committee can spend months on big-bang versus phased. The question is tractable, it fits on a slide, and it feels like the central risk decision of the whole program. Debating it lets everyone in the room feel they are steering the thing by steering its rollout.

It is mostly a decoy.

I have sat through programs that argued the sequence at length and then succeeded or failed for reasons that had nothing to do with which one they picked. The outcome was decided somewhere else, and the somewhere else was almost always the same three things.

What was actually deciding the outcome

The first was whether the organization had done this before. Not the IT department, the business. A management line and a set of operational people who have already lived through a transformation program know, in their bodies, what it's going to cost them in attention over the next eighteen months. They don't relitigate the premise every time it gets hard. An organization going through its first big transformation spends the early months discovering that the project is real, that it competes with the day job, and that nobody is coming to do the work for them. That discovery happens whether you went big-bang or phased.

The second was the data. Not whether someone ran a cleansing tool and declared the data clean, but whether the data had been cleaned deeply, which is slow, unglamorous, and owned by people who would rather be doing their actual jobs. A phased rollout doesn't fix dirty data. It just lets you discover it in smaller, repeated doses. Big-bang lets you discover all of it at once.

The third was whether the scope held still. A program where the perimeter is frozen, and stays frozen because real governance defends it, runs on a different physics than one where the scope is quietly reopened at every operational committee. The second kind doesn't fail because of its rollout strategy. It fails because it never had a fixed thing to roll out. The target kept moving, and no sequence survives a moving target.

Why the sequence gets the attention anyway

So why does the rollout question get the committee hours while these three get a line each in the status pack?

Because the sequence is the one you can decide in the room. It's bounded. You can list the pros, list the cons, take a position, and feel like you've managed a risk. The other three are uncomfortable in a way that a slide can't hold. Telling a sponsor the business isn't mature enough to absorb this is a career conversation. Telling them the data work is months behind what the plan assumes means someone owns that slip. Telling them the scope has crept since kickoff, one reasonable-sounding addition at a time, and can easily reach something like forty percent, means naming who let it.

The sequence debate is comfortable precisely because it lets the room avoid the three questions that actually carry the program. It's motion that feels like decision.

Where the sequence does matter, honestly

This isn't to say the choice is empty. Big-bang and phased carry genuinely different risk profiles, and the difference is real where the calendar bites. A go-live dropped on top of a monthly, quarterly, or year-end close is a different animal depending on which way you sequenced, and getting that collision wrong costs you regardless of how ready you are. UAT scheduled across August, when the business is on holiday and the key users who are supposed to test are simply not there, will hurt a big-bang and a phased program in different shapes. These are real considerations, and a competent program weighs them.

But notice what they are. They're scheduling consequences of the sequence, not reasons the sequence decides the program. You handle them by reading the business calendar honestly and refusing to go live into a wall. That's project management. It isn't the strategic fork the committee treats it as.

The decision underneath the decision

Here's the part that connects this to everything that follows in this series. When a committee pours its energy into the sequence and gives the three real variables a glance, it isn't avoiding a decision. It's making one. It's deciding, by default, that organizational readiness, data quality, and scope discipline will be whatever they happen to be, while the smart people in the room argue about something tractable.

That's the pattern this whole series is about. The sequence is the question you can see. Maturity, data, and scope are the questions that decide the outcome, and they get settled, one way or another, whether or not anyone chooses to settle them deliberately.

So the useful move isn't to answer big-bang or phased faster. It's to demote the question. Decide what your organization can actually absorb, get the data genuinely clean, and put governance around the scope that can hold a line. Once those three are real, the sequence becomes what it always was, a planning choice with calendar consequences, not the thing the program lives or dies on.

Which raises the next question this series has to deal with, because once you've decided what to build and what your organization can carry, you still have to choose who builds it with you. That's where most of the control is won or lost, and almost nobody reads the contract the way that fact deserves. That's where the next article goes: Choosing Your Integrator: The Fixed-Price Belief and the Real Lever of Control.