The system project is asking for rules the business has not decided

The project is real and underway. The business has been mapped, the workflows documented, the master data reviewed. Then the integrator opens the pricing configuration and asks the question the platform needs answered before it can run: how is the price set for this account. The answer is the matrix, plus the overrides the team learned over the years, plus the file the analyst keeps open beside it, plus what the senior rep remembers about the renewal. The integrator asks which of those is the rule. The room does not have a rule. It has a history.

It is not one workshop. The same configuration that needs a pricing rule needs the rest of the commitments written down too, and each one lands in the room the same way.

Four records the platform needs, four questions the business cannot cleanly answer, each one the business has been answering by hand for years. The team in the room is not failing to fill in a form. It is being asked, for the first time, to decide things it has been getting by without deciding. The platform asks for the rules, and there is history, not rules.

The project is the event that exposes the condition, not the cause

The reason the room cannot answer is not the part most people reach for first, so it is the part worth slowing down on.

This is the move the whole piece turns on. The records the platform asks for are precisely the records the business never had to decide while a few experienced people could hold the detail between them. The standard configuration wants a clean pricing rule, a stable availability number, a structured account treatment, a defined substitution authority. The business has a matrix plus overrides, a number the branch re-checks on the floor, a treatment in a CSR’s memory, and a rep’s case-by-case judgment. None of those is a rule. Each is the accumulated record of decisions that were made one order at a time and never written as logic, because at a smaller scale the people who made them could simply carry them. The platform is the first thing that ever asked for all of them at once, in a form a system can run.

So the project stalls, and it is worth being precise about why, because the reflexive answer is the wrong one. The workshops do not stall because the platform is weak or the integrator got it wrong. An integrator can map fields, configure modules, and run a clean workshop. What an integrator cannot do is decide, on the business’s behalf, what the substitution rule is, or which override is a rule and which is leakage. The workshops stall because the decisions were the business’s to make and had not been made. There is nothing coherent to encode, and the project is the first event in the company’s history that required there to be.

That distinction is the one the platform’s request keeps surfacing, account by account. The platform may be where the problem appears. It is not where the problem began. A capable platform on undecided rules inherits them and runs them faster, and the deeper reason the rules could never be handed over cleanly in the first place is its own subject. What the project does here, now, in this room, is simpler and more exact: it is the first instrument that ever forced every undecided rule into one place at one time, so it surfaces the whole of the condition at once.

Where the undecided rules actually go

The project still has to ship. So the question is what a project does with rules the business never decided, and the answer is the concrete shape of everything above.

Take the three destinations one at a time, on the records the platform asked for.

The decided rules go in clean. A standard payment term, a published list price, a stocked item with a lead time the branch trusts: the business could state these, so the platform takes them and runs them. This is the project working as it was sold, and where a rule was decided, the platform forces the discipline the business wanted from it. The price comes from the configured rule and holds. That part is genuinely better, and the steering pack shows those modules live on schedule.

The undecided rules the platform must still hold become exceptions. The account whose billing treatment nobody could state becomes a custom field on the customer master. The substitution that is sometimes allowed and sometimes leakage becomes a hardcoded exception for the accounts that had one. The pricing override that protected a renewal becomes a permanent entry in the configuration that no one owns. The platform carries each of them, faithfully, but it carries them as the same unowned exception they always were, now wired into a configured system and harder to change than when they sat in a file, because changing them now means a change request.

And the rules that fit nowhere clean go back outside the platform, to where they came from. The availability number the branch still does not trust, so the planner keeps the stock file open beside the new screen. The account rule that never made it onto the customer master, so the senior CSR’s memory is still the only place it lives. The EDI exception the standard mapping cannot carry, so a line is still mapped by hand against the new integration. The screen is newer. The file beside it is the same file.

None of the three destinations is a decided rule. The project sorted the rules by whether the platform could hold them, not by whether the business had decided them, and the undecided ones survived the cutover in a custom field, an exception table, or a spreadsheet beside the new screen. The system is live. The decisions are still not made.

Read the left column down: that is what the platform needed. Read the middle: that is what the business actually had, which in every row is history, not a rule. Read the right: that is where each one ended up, loaded as an exception or pushed back outside. The platform held what it was given a rule for and held the rest as configuration because it was asked to ship, which is exactly what a capable platform does with what it is handed.

This is also where the most common belief about a go-live quietly fails. The belief is that the system will force the discipline: once it is live, people will have to operate the clean way, and the side files and the memory will retire because the platform makes the clean path the only path. A platform forces discipline only where it carries a decided rule. Where the rule was undecided, the platform did not impose one. It held a custom field, an exception table, or pushed the work back outside, so the side file is open beside the new screen on day one. The system enforces the rules it was given and routes around the ones it was not. Going live did not decide the undecided rule. It shipped it as an exception.

The project is blamed for the problem it revealed

What follows the cutover is a particular kind of cost, and it is not a collapse. It is a misreading.

Two things happen, and both are visible from the chair.

The project absorbs the blame. The steering committee, the board, the sponsor record the platform as the thing that went over budget and under-delivered. The change-request log is the tell: it grew for three quarters running, and each request was the price of a decision no one could make in the workshop. The cutover date moved twice. The go-live narrowed in scope. So the integrator is changed, or the remaining scope is cut, and the next planning cycle reads the lesson as the platform did not work, which is the wrong lesson, because the platform did exactly what a platform does. A second capable platform on the same accumulated overrides would produce the same outcome faster.

And the business case is judged unmet. The case promised standardization, a release of working capital, and a single operating model, on the assumption that the system was the bottleneck. None of those arrived, because each depended on a decided rule the project could not produce. The gap is widest in a roll-up, where each add-on arrived with its own masters before the platform could standardize the last, so the masters were migrated, not reconciled, and the platform now runs several commercial histories on one screen. From the review chair, this is the project that shows up in the next board pack as a write-down of capitalized cost or a re-baselined plan, named by its nearest initiative rather than by what is actually producing it.

The platform changed; the question did not

The business does not stop here. So the consequence has a resolution, and it is the reason the close is what it is.

The next platform asks the same questions because the questions were never the platform’s to answer. The fixes do not compound, because neither project touched the thing underneath. One project, then the next; the same workshop, the same four records, the same history handed across the table. The platform changed. The question did not.

Decide the rule before the system can carry it

The decision the project has been waiting on the whole time is not the one the business keeps reaching for.

This is a different kind of work than the project, and it comes before the project, not after it. It is not picking a better platform, and it is not delaying the cutover until it is ready, because time does not decide the rule, only the business does, and a delayed cutover on undecided rules is a longer project that ships the same exceptions later, at more cost. It is not documenting the requirements harder, either. A requirements document can only record a decision the business has already made. You cannot document the substitution rule before the business decides what the substitution rule is, and writing the four side files and the CSR’s memory into a longer binder just moves the undecided rule into a longer document. The hard part was never writing the rule down. It was deciding it.

And the rule has to live where the next quote uses it, or the next override will erase it. The decision is not made in a slide or a target operating model. It is made in the records the next order actually runs through: the pricing configuration, the customer master, the availability the portal publishes, the substitution the system enforces.

The proof that this work happened is not that the system went live on schedule, and it is not a green cutover dashboard. The proof is that the workarounds retire. The price comes from the decided rule, and the analyst stops rebuilding it beside the matrix. The availability number is one the branch will promise, so the planner stops keeping the file open beside the screen. The substitution authority is a rule the system enforces, so the rep stops carrying it case by case. The account treatment is on the record, so the CSR’s memory is no longer the only copy. When those four go quiet, the platform is finally carrying decided rules, and the project the business funded is doing the thing it was bought to do. Until then, every new platform meets the same undecided rules.