11 Tips on How to Crash an E-Commerce Project at Full Speed

Or: How a change of perspective helps to discover the better solution.

In creativity techniques, there’s a method called the “flip-flop technique.” This has nothing to do with sandals but rather acknowledges that people tend to be more creative when dealing with negative thoughts than positive ones. In practical terms: you list all the points that could contribute to a project’s failure, then “flip” them into their opposite, which quickly leads to new creative solutions – beyond usual thinking patterns.

Rule #1: Trust the marketing promises of software vendors.

In our upside-down world, we assume marketing never lies or exaggerates. So, we trust that all sales arguments are true and that software can do EVERYTHING as promised. In the case of commerce software, this means it boosts conversion, reduces process costs, is easy to use, modular, customizable, flexible, future-oriented, etc. AI, cloud, and SaaS are, of course, included. Whether it’s a shop system, middleware, PIM, payment provider, recommendation solution, or whatever – it doesn’t matter. The soup always contains everything that makes experienced IT cooks roll their eyes.

Naturally, in our world of opposites, we also look at case studies that have nothing to do with our situation. Who cares if the software fits our own requirements? After all, any software can be bent to fit. Customizing for the win.

This leads to the question: WHO should decide which solution fits best… to ensure nothing fits?

Rule #2: Let IT decide which software to use.

For maximum failure, the internal IT department – or lovingly referred to as “EDV” (Electronic Data Processing) – should choose the software. Perhaps they can even collaborate with a conservative data protection officer. After all, who cares if users can work well with the software? As long as it has the right ISO certification.

Another option: if you have in-house developers, let them choose the software based on their personal preferences. Who likes which programming language? Who heard something cool from a buddy? The latest trends are surely tried and tested, right? Wrong, but here in our opposite world, we love outdated assumptions.

Rule #3: Assign project responsibility to someone who didn’t choose the software.

Very common and perfect for ensuring failure: after IT has chosen the hottest tech that no one else understands, give full responsibility for implementation to, say, the marketing department.

That’ll guarantee failure. Hurrah! IT doesn’t have time for “such things.” They’re busy with the outdated ERP system, keeping the company running. Major decisions are made after two workshops. “And the little shop part? Surely marketing can handle that,” they think in the land of failure. IT stays out of it. A crucial rule for crashing: separate IT and marketing decisions as much as possible.

Rule #4: Take your time creating a detailed RFP and involve as many stakeholders as possible.

It’s super helpful for failure if you involve everyone and consider all their use cases. Make sure to bring in even those with little experience. Unknown unknowns are especially dangerous.

Avoid bringing in professionals and simply document what’s already known. Never question historical processes; just replicate them.

This is fantastic for failure – the more exact everything is planned in advance, the more chaos ensues when reality hits. You waste time on a requirements document and waste even more time when it all goes wrong. Double waste, double the fun!

Rule #5: Ignore related systems.

Here, you have two ways to fail:

1. Create separate RFPs for each system so that no one knows what the others are doing. This way, people can sabotage each other’s projects, and the blame games can begin.
2. Set up a monster project by replacing all systems simultaneously. Who needs step-by-step plans? It’s better when everyone is overwhelmed.

Rule #6: Keep saying you want everything done in the standard way and that it must be state-of-the-art.

But don’t define what that actually means. After all, we all know that when you ask different people to draw a house with a tree and sun, it looks exactly the same, right? Wrong! But here, we love miscommunication and arguments about what “state-of-the-art” means.

Rule #7: Never clarify responsibilities upfront.

Most IT projects, like shop implementation, aren’t isolated but are part of a larger IT architecture expansion. A surefire way to fail is to ignore these dimensions and not clarify responsibilities.

Make sure one person is responsible for everything. They’ll lose focus, get overwhelmed, and the project will fail spectacularly.

Rule #8: A detailed design is far more important than good processes.

We all know how important it is that an online shop looks “nice.” So, instead of waiting for market feedback, commission an expensive design first. Focus on every pixel, no matter how long it takes. Who cares if orders flow through the system? The banner must look perfect.

Rule #9: More workarounds are always better.

From the beginning, try to bend the software to fit your processes. Forget about standards. Avoid doing internal groundwork, like properly preparing product data. Who has time for that?

Rule #10: Ensure you accumulate technical debt from the start.

It’s always best to skip over code quality, tests, and maintainability to save time. You can deal with that later (or never). The saying “nothing lasts longer than a temporary solution” is a lie, right?

Rule #11: Only go live when EVERYTHING is finished.

Who cares about MVPs? If you want to ensure budgets and timelines are irrelevant, only go live when every feature is completed and every pixel is perfect. Everyone knows: a platform is done once it goes live and never needs further development.

Breathe in. Breathe out. Let it sink in. Had enough “flop”? Right. Now flip back to the real world of success. By focusing on failure, you’ll likely come up with many ideas to avoid it. And if you still hit a snag… there’s always us. We at Shopmacher have rescued countless projects from near-failure and have a solution for every problem. Promise.

What we can also do