Sideways, Not Sunk: Getting retail technology implementations back on track without starting over

A technology implementation can have the right solution, experienced people, and a reasonable plan and still get into trouble. The real test comes when delivery starts slipping and the retailer, vendor, and implementation partner have different explanations for why.

At Cambridge Retail Advisors, our team has worked through those conversations from every side. We have all worked directly for retailers, some for technology vendors, and others as independent consultants. We've been the people asking why something wasn't delivered, and we've been the people explaining what was preventing delivery.

When the First Code Arrives

The project starts with an agreed scope, budget, and implementation schedule. Requirements are documented, designs are underway, and development begins. On paper, the plan makes sense.

Then the first few code deliveries arrive, and the workload changes considerably.

QA begins finding defects while developers are already working on the next release. Architects are still finalizing customizations, enhancements are entering the backlog, and production issues need attention. A defect gets fixed, but the change breaks something that previously worked. QA starts retesting, developers return to troubleshooting, and the release date hasn't moved.

These pressures can begin before the pilot and continue long afterward. The same people are being pulled between workstreams, while the original plan may still assume they're available for everything.

When Scope Grows Without a Business Case

Delivery problems aren't always on the vendor's side. Early in the project, the retailer agrees to a defined set of requirements. Then the business starts seeing the system in action, and new requests begin to arrive.

Each one seems reasonable on its own: a report a merchandising team needs, a workflow store operations would like changed, an integration someone assumed was included. None of them looks large enough to slow the project down. Together, they consume the same developers, testers, and architects the original plan depends on.

Without a clear business case and change control, scope creep turns into schedule slippage, budget overruns, and disputes over what was actually promised. The vendor sees new work, while the retailer sees features it expected all along.

Before a new request enters scope, the retailer should be able to answer three questions:

• What business outcome does it deliver, and who owns that outcome?
• What will it cost in budget, schedule, and team capacity?
• Does it need to be in this release, or can it wait for a later phase?

Some changes are worth making. A disciplined change process makes sure they're chosen deliberately, rather than added one conversation at a time.

When Partners Start Disagreeing

The retailer's business teams have stores to run, and IT must keep existing systems operating. Vendors have development commitments of their own. Consulting partners are trying to coordinate activities across groups that may have very different priorities.

Eventually, those pressures show up in project meetings. The retailer questions missed milestones, the vendor is waiting on decisions, and disagreements develop over what was originally promised.

Transparency matters on both sides.

Retailers need to acknowledge delayed decisions and changing priorities. Vendors and implementation partners need to be open about delivery problems and what they can realistically accomplish.

Another challenge is simply keeping track of everything that gets discussed. Over a lengthy implementation, hundreds of meetings, design discussions, emails, and changes can leave people with different recollections of what was agreed upon.

Agree Before Moving Forward

Disagreements over responsibility are one issue. An implementation that continues missing delivery commitments requires another kind of intervention.

Before another code release, MVP, pilot, or broader rollout, the parties should agree on what must be completed and what constitutes an acceptable result:

Not every defect has to be fixed before moving forward. Some can be accepted with documented workarounds and remediation plans, provided the business understands and approves the risks.

Resetting the Plan

When problems continue from release to release, changing another date accomplishes little. The team needs to look at how work is organized and whether the delivery approach still makes sense.

Additional resources can help when capacity or expertise is genuinely missing, but adding people to an already poorly coordinated project won't automatically improve delivery.

The first priority is understanding what's preventing progress. From there, CRA can help the parties establish workable commitments, improve project oversight, or provide targeted expertise where it's needed.

Before Changing Vendors

Replacing a technology vendor or system integrator is sometimes necessary, particularly when agreed corrective actions repeatedly fail. It's also a significant decision with consequences for the budget, the timeline, and the work already completed.

Before making that call, the retailer should establish whether the current relationship can deliver against a realistic recovery plan. An independent advisor can help assess the true state of the project, separate vendor performance issues from scope and decision-making issues, and define the commitments each party can actually meet.

Those conversations have to be honest on every side of the table.

That includes the retailer.