A shipping window that almost derailed an entire project

The deployment takes place at a construction materials producer: sands, gravels, aggregates. Trucks leave throughout the day, loads are consolidated, and the shipping department is at the heart of the activity.

During the workshops, its manager made a clear request: to find in the new ERP a window for grouping shipments identical to that of the old system.

In the old tool, he would mark the lines to be shipped with a cross, then adjust the quantities as he went along, line by line.

The standard ERP system being deployed operates differently: the consolidated shipment is a single document, to which lines are added or removed, and whose quantities are updated before validation. The end result is the same; only the method differs.

The request seemed innocuous. Yet, the development undertaken to address it quickly veered towards modifying the shipment validation process itself. But altering validation means altering standard inventory management: movements, valuation, traceability, and all the tests that depend on them. A question of usability was becoming a complete overhaul of a critical process.

The solution to the crisis came neither from outright refusal nor complete acceptance. The project manager forged a compromise with the manager: a new window, closely aligned with their usual work practices, based on the standard document without altering the validation process, in exchange for agreeing to work slightly differently. The shipping department retained a user-friendly interface, and the project kept its standard inventory management system.

Why a reasonable demand becomes a drift

This story encapsulates the mechanism of scope creep. No request, taken in isolation, seems unreasonable. The shipping manager's request was legitimate: he knew his job, his production quotas, and wanted to avoid wasting time at the loading dock. The problem didn't stem from his need, but from the way he expressed it.

A user rarely describes a need. They describe a solution, most often one they already know. "A window identical to the old system" is a solution. "Quickly prepare a load combining several orders" is a need. As long as the project focuses on the requested solution rather than the need, each workshop adds developments, and the scope expands without anyone's consent.

The conditions are all the more favorable given the vagueness of the initial objectives. A project launched to "modernize the information system" or "improve efficiency" provides no criteria for making a decision. Without a measurable target, any request can be justified.

Drift, clarification, or forgetting: three situations to distinguish

Not everything that is added during the course of a project is a deviation.

Before saying yes or no, the request must be qualified, because each case requires a different approach.

The real drift

A new request has emerged along the way, unrelated to the approved objectives: a supplier portal "while we're at it," an additional dashboard. This will require a decision, a later phase, or an amendment.

The clarification

A previously validated need is becoming clearer: the exact rule for calculating a price, the details of a preparation step. This is the normal functioning of a project, and it fits within the existing scope.

The framing oversight

A need that existed from the outset was overlooked in the analysis, for example, a regulatory requirement for traceability. This is not a business whim but an analytical error, which is being addressed with the sponsor, without assigning blame.

The shipping manager's request fell into a fourth category, the most frequent and the most deceptive: habit presented as a need. It deserves careful consideration, followed by negotiation regarding the form it should take.

Warning signs

Certain signs allow us to spot the drift before it impacts the schedule. The first is the vocabulary: "as before", "identical to the old system", "we've always done it this way".

The second is the area affected: a request that modifies a validation, a stock calculation, cost or accounting is never a small request, regardless of the simplicity of the screen that carries it.

Next come the pilot signals: a number of fit-gap analysis deviations that continue to increase after design validation, load estimates that swell from one committee to another, requests accepted in the workshop without costing, and phases that lengthen without an identifiable technical cause.

The integrator's share of responsibility

The drift is not solely the responsibility of business units.

A significant portion of the process originates with the integrator. In a workshop setting, when asked if a function is feasible, the consultant readily replies "it's doable," which is almost always technically true. The user, however, hears "it's planned."

The type of contract exacerbates this phenomenon. With a fixed-price contract, every unpriced addition is billed as a markup or in terms of quality, and the amendment that no one dares to open ends up straining the relationship. With a time and materials contract, the meter runs, and the cost overrun is less noticeable until the invoice arrives. In both cases, the role of the experienced consultant is to clearly state the cost of a request, even when the answer is unsatisfactory.

What a drift really costs

The cost of development doesn't end with its completion. It must be tested, documented, user-trained, and then maintained with each ERP version upgrade. A change to the shipment validation process would have required retesting all inventory flows with every update, for the entire lifespan of the system.

The human cost is just as real. When the target keeps shifting, the project team loses sight of the finish line, the start date is repeatedly postponed, and the project loses credibility with the organization. With resources remaining constant, each addition is ultimately financed by shortening testing, resulting in a system that covers everything only approximately, rather than a robustly controlled scope.

Maintaining control of the perimeter without disrupting operations

Outright refusal rarely works; the rejected user will either circumvent the system or hinder its adoption. Several practices allow you to maintain control while remaining responsive.

Rephrase the solution as a need

With each request, the first question focuses on what the user is trying to accomplish, not on the screen they are describing. This is often where the compromise lies.

Separate the engine interface

Adapting a window, a list, or a shortcut is inexpensive and remains local. Modifying a validation, a stock calculation, or an accounting entry affects the entire system. This boundary is the most important to defend, and it's what allowed us to successfully navigate the shipping process.

Ask the sponsor the right question

"What, being absent at the start, prevents invoicing, shipping or closing the month?" What does not pass this filter can wait for a later phase.

Apply the rule of one input for one output

After the design is validated, any added request indicates what it replaces or shifts.

Reserve a perimeter envelope.

A reserve of capacity, visible to the steering committee, makes the decision-making process concrete. When this reserve is used up, new requests can wait.

Keep a record of requests

Each request is assessed, quantified, and reviewed. Those that are postponed are included in a phase 2 list presented to each committee, so that the postponement is not perceived as a rejection.

Conclusion

Scope creep almost never stems from bad intentions. It arises from legitimate requests, framed as solutions, that no one takes the time to reframe. The shipping manager wasn't wrong to want to work efficiently. He had simply described his old tool instead of his actual need.

Mastering the scope therefore does not consist of saying no, but of knowing what you are protecting, the standard, the schedule and the team's ability to deliver.

At the next steering committee meeting, a simple exercise will suffice to begin. Open the list of requests accepted since the design validation, and count those that were costed before being accepted.