The biggest risks to a commerce implementation rarely appear during development. By then, they’re already built into the project.
If you’ve spent any amount of time around enterprise commerce projects, you’ve probably heard someone say, “Everything was going well until…”
The sentence usually ends with a missed deadline, a difficult integration, an unexpected customization, or a platform limitation that seemed to appear out of nowhere. By the time those stories are told, they’ve been compressed into a single defining moment—the point where the project supposedly went off the rails.
I’ve never found that explanation particularly satisfying.
Not because those moments don’t happen, but because they rarely explain why they happened in the first place.
After leading commerce implementations across manufacturers, distributors, and enterprise organizations, I’ve become convinced that most projects don’t fail because of a technical decision made halfway through development. They drift. Slowly enough that every individual decision feels reasonable, and gradually enough that nobody notices the cumulative effect until the project has become something very different from the one everyone agreed to at kickoff.
That’s an uncomfortable observation because it shifts the conversation away from technology and toward the organization itself. It’s much easier to point at a difficult integration than it is to acknowledge that leadership never fully aligned on what success looked like. It’s easier to blame the platform than to recognize that every department walked into discovery with a different vision of the future. Technology is visible. Organizational complexity usually isn’t.
That’s one of the reasons enterprise commerce continues to fascinate me. We spend an enormous amount of time evaluating platforms, comparing feature sets, discussing architecture, and planning implementation roadmaps. Those conversations matter, but they’re rarely where a project’s long-term success is determined. More often than not, the trajectory has already been established by the time those discussions begin. Development simply reveals decisions that were made months earlier, when the difficult questions still felt theoretical and there was still plenty of time to postpone answering them.
Looking back, the projects I remember most aren’t the ones with the fewest technical challenges. They’re the ones where the organization had the discipline to answer those difficult questions early. They invested time building alignment before building software. They established decision-making frameworks before decisions became urgent. They agreed on the business they wanted to become before discussing the technology that would help them get there.
Those projects weren’t necessarily simpler. They were simply clearer.
Alignment Isn’t the Same Thing as Agreement
Every kickoff meeting feels optimistic.
The investment has been approved, stakeholders are engaged, and everyone around the table believes they’re moving in the same direction. Marketing wants to create a better digital experience. Sales wants customers to become more self-sufficient. Operations is hoping to eliminate manual work. IT sees an opportunity to reduce technical debt, modernize integrations, and create a platform that will support the business for years to come.
Listen to each department individually and everything sounds perfectly aligned.
Listen a little longer, however, and subtle differences begin to emerge.
Marketing talks about flexibility. Sales talks about customer adoption. Operations talks about efficiency. IT talks about architecture. Executive leadership talks about growth.
None of those objectives conflict with one another. In fact, they’re exactly what you’d expect from a healthy organization preparing for a significant investment. The challenge is that they aren’t the same objective.
That distinction becomes incredibly important once implementation begins.
If every department is quietly optimizing for a different definition of success, the delivery team eventually finds itself trying to build several different projects at once. Marketing requests functionality that improves agility. Sales asks for workflows that preserve existing customer relationships. Operations pushes for standardization. IT resists customizations that will become difficult to support over time. Every request is reasonable when viewed independently, yet collectively they begin pulling the implementation in competing directions.
From the outside, this often looks like scope creep or poor project management. In reality, it’s frequently a symptom of something much simpler.
The organization never reached alignment.
Agreement is relatively easy to achieve. Most executive teams agree that modernization is necessary. Alignment is significantly harder because it requires people to make tradeoffs. It forces leadership to decide which outcomes matter most, which compromises they’re willing to accept, and which requests belong in a future phase rather than the current implementation. Those aren’t technical decisions. They’re business decisions, and postponing them doesn’t make them disappear. It simply transfers them to the delivery team, where they’re significantly more expensive to resolve.
One of the most valuable things a delivery leader can do isn’t create another project plan. It’s helping everyone agree on what success actually looks like before the project becomes busy enough that nobody has time to ask the question again.
Governance Isn’t Bureaucracy. It’s How Good Organizations Make Decisions.
Governance has an unfortunate reputation.
Mention it during project planning and it’s easy to imagine steering committees, status meetings, approval chains, and documentation. It has a reputation for slowing projects down, which is probably why organizations sometimes treat governance as an administrative requirement instead of a strategic advantage.
I’ve come to see it very differently.
Good governance isn’t about creating more process. It’s about deciding how decisions will be made before those decisions become urgent.
Every enterprise commerce implementation reaches a point where priorities collide. A recently acquired business needs to be incorporated into the roadmap. A customer workflow that wasn’t discussed during discovery suddenly becomes essential. Leadership identifies a new opportunity halfway through the project and naturally wonders whether it can be included before launch. None of those requests are unreasonable. In fact, most of them reflect a business that’s actively growing and adapting.
The question isn’t whether those conversations will happen. They always do.
The question is whether the organization has already agreed on how it will evaluate them.
Without a clear governance model, every request arrives with the same level of urgency. Every stakeholder believes their requirement is essential, every new idea feels too valuable to postpone, and every compromise becomes a negotiation. The delivery team gradually shifts from building a solution to arbitrating priorities, often without the authority to make the decisions they’re being asked to implement.
That’s where projects begin drifting.
Not because anyone made a bad decision, but because nobody established a consistent way to make good ones.
Why Scope Creep Is Usually a Leadership Problem
One of the first phrases people learn in project management is scope creep. It gets used so frequently that it’s almost become a catch-all explanation for why projects become more difficult than expected. If delivery slows down, if timelines move, or if budgets increase, someone eventually concludes that the project suffered from scope creep.
I’ve never found that explanation particularly useful because it focuses on what happened rather than why it happened.
In my experience, scope doesn’t usually grow because stakeholders are being unreasonable. Quite the opposite. Most additional requests are completely understandable. A business acquires another company halfway through the project. Sales identifies an important customer workflow that wasn’t discussed during discovery. Finance realizes an approval process that’s been used for years wasn’t documented because everyone assumed it was already understood. Leadership begins thinking about future acquisitions and asks whether the architecture can support them.
Every one of those conversations is legitimate. If I were sitting on the client side of the table, I’d probably ask many of the same questions.
The challenge is that every decision carries a cost, whether that cost appears in the budget, the timeline, or the long-term complexity of the solution. Good governance doesn’t eliminate difficult conversations; it creates a consistent way of evaluating them. Without that structure, every request feels equally important because there’s no agreed-upon framework for deciding what belongs in this phase and what should intentionally wait.
That’s why I tend to think of scope creep as a leadership challenge rather than a delivery challenge. Delivery teams don’t create shifting priorities. They respond to them. When executive teams haven’t established clear business objectives, delivery naturally becomes the place where competing priorities collide. The project doesn’t become more complicated because the technology changed. It becomes more complicated because the organization never agreed on how it would make difficult decisions once the project was underway.
One exercise I’ve found incredibly valuable is asking leadership a deceptively simple question whenever a significant request appears: “If we include this, what are we choosing not to do?” It’s remarkable how quickly conversations change when every new idea is viewed as a tradeoff instead of an addition. Organizations rarely struggle because they have too many good ideas. They struggle because they’ve convinced themselves every good idea belongs in the current release.
That isn’t ambition. It’s a planning problem.
When Technology Becomes the Scapegoat
There’s another pattern I’ve noticed over the years, and it usually appears several months into implementation.
The project begins feeling more difficult than anyone expected. Teams are working hard. Meetings become more frequent. Decisions take longer. Stakeholders are becoming anxious about timelines, and naturally the conversation begins turning toward the technology itself.
“Maybe this platform wasn’t the right choice.”
Sometimes that’s true. Most of the time, it isn’t.
Modern commerce platforms are remarkably capable. Whether an organization chooses Adobe Commerce, Shopify, Shopware, commercetools, or another enterprise solution, they’re working with software that has already proven itself across thousands of businesses. Every platform has strengths and limitations, but very few implementation challenges are caused by a platform being fundamentally incapable of solving the problem in front of it.
More often, the platform becomes the first place where organizational complexity is impossible to hide.
Take customer-specific pricing as an example. If pricing rules exist across multiple systems, have evolved over many years, and rely on manual intervention to remain accurate, a commerce platform isn’t creating complexity by exposing those inconsistencies. It’s simply forcing the organization to confront decisions that have quietly accumulated over time. The same is true for product information, inventory visibility, approval workflows, customer hierarchies, and countless other operational processes. These aren’t technical problems disguised as business problems. They’re business problems that become visible through technology.
That’s an important distinction because it changes the way organizations respond. Blaming the platform often leads to more customization, more workarounds, and more complexity. Understanding the underlying business process usually leads somewhere far more valuable. It creates an opportunity to simplify. Sometimes that means changing technology. More often, it means changing the way the business itself operates.
Technology has a way of making assumptions visible.
Good delivery teams know the real work begins once those assumptions come to light.
The Quiet Breakdown of Communication
If I had to choose one early warning sign that concerns me more than any missed milestone or delayed sprint, it wouldn’t appear on a project dashboard.
It would appear in the conversations.
At the beginning of an implementation, discussions tend to revolve around business outcomes. Teams talk about improving customer experience, increasing operational efficiency, reducing manual work, or creating a stronger foundation for future growth. Everyone understands why the project exists because those objectives are still fresh in everyone’s mind.
As delivery progresses, however, something subtle often begins to happen. The conversations become increasingly tactical.
Meetings focus on individual user stories, integration requirements, design revisions, edge cases, testing scenarios, deployment planning, and sprint velocity. Those discussions are necessary because they’re part of delivering any successful implementation, but over time they can unintentionally replace the bigger conversation rather than support it.
Weeks pass without anyone asking whether the project is still moving toward the business outcomes that justified the investment in the first place.
I’ve learned that successful delivery isn’t simply about managing tasks. It’s about protecting clarity. Every few weeks, someone has to pull the conversation back above the backlog and remind everyone why those tickets exist. Otherwise, organizations become incredibly efficient at building features while slowly drifting away from the business transformation they originally set out to achieve.
The best steering committee meetings I’ve participated in don’t spend most of their time reviewing project status. They spend their time validating decisions. They ask whether priorities still reflect business objectives, whether assumptions made during discovery still hold true, and whether new information changes the roadmap. Those conversations are rarely dramatic, but they often prevent months of unnecessary work because they create opportunities to correct course while changes are still relatively inexpensive.
Good communication isn’t about increasing the number of meetings. It’s about making sure the right conversations continue happening long after kickoff.
The Best Commerce Projects Feel Surprisingly Boring
People are often surprised when I describe my favorite implementations. They expect stories about difficult integrations, ambitious technical solutions, or major launch weekends where teams worked through the night solving unexpected problems.
Those experiences certainly exist, but they’re not the projects I remember most. The projects that stand out are usually the quiet ones.
Not because they lacked complexity, but because complexity was addressed before it reached development. Leadership made decisions early. Governance remained consistent. Teams trusted one another. Priorities didn’t change every week because everyone understood how decisions would be evaluated. Challenges still emerged—as they always do—but they rarely became crises because the organization already had a shared way of working through them.
From the outside, those projects can almost look uneventful.
From a delivery perspective, that’s exactly what success looks like.
Enterprise commerce should feel predictable. It should feel organized. It should create confidence instead of constant escalation. When projects become dramatic, it’s usually a sign that uncertainty has replaced clarity somewhere in the process.
Technology didn’t create that uncertainty. People did.
The encouraging part is that organizations can solve it long before development begins. The conversations that happen during discovery, executive planning, governance workshops, and roadmap sessions rarely receive much attention after launch, yet they often have more influence on project outcomes than any architectural decision made later.
That’s why I don’t think successful commerce projects are won during implementation.
They’re won by the quality of the decisions made before implementation ever begins.
Continue the Conversation
If your organization is preparing for a commerce modernization initiative, don’t start by comparing platforms or debating implementation timelines. Start by examining how decisions are made today. Is ownership clear? Does every stakeholder share the same definition of success? Is there an agreed-upon framework for evaluating new priorities when they inevitably arise?
Those conversations may not feel as exciting as selecting a new commerce platform, but they’re often the difference between an implementation that simply launches and one that fundamentally changes the way your business operates.
Our Commerce Modernization Assessment is designed to help leadership teams answer those questions before implementation begins. Together, we’ll identify operational friction, align on business objectives, and build a roadmap focused on long-term business outcomes—not just a successful go-live.
→ Schedule a Commerce Modernization Assessment
Three Questions to Ask Your Leadership Team This Week
Before your next steering committee meeting, ask:
- If every executive described success one year after launch, would the answers be consistent?
- What decisions still don’t have a clear owner?
- If a major new requirement appeared tomorrow, have we already agreed on how we’ll decide whether it belongs in this phase?
If those questions spark debate, you’ve identified one of the most valuable opportunities in your implementation; and you still have time to address it.
Continue Reading
Commerce Modernization Isn’t Broken. Our Thinking About It Is.
Explore why the most successful organizations treat modernization as a business strategy, not simply a technology initiative.
Why Some Commerce Projects Change a Business and Others Just Change the Website
See why lasting transformation comes from redesigning operations before replacing platforms.