11 tips on how to drive an e-commerce project full force into the wall

In creativity techniques there is a method called the "flip-flop technique". It has nothing to do with beach sandals; instead it takes account of the fact that the psychology of most people is considerably more creative when dealing with negative thoughts than with positive ideas. In concrete terms: you collect all the points that could contribute to a project failing, then "flip-flop" them into the opposite and this way quickly arrive at new creative approaches, beyond the usual patterns of thinking and acting.

So let us get down to business: you want your next e-commerce project to turn out better than any before it? Perfect, then let us assume the greatest possible opposite. And we will not start quite at Adam and Eve, but shortly after: with the initialization.

To pull off the best possible crash, during initialization you should first consider what basis the project will be built on and whom you want to involve. A decision on a basis or platform is due. There are countless options here. Inevitably, you have to work your way from a long list to a short list. So how do you proceed so that everything goes wrong from the start?

In our funny little opposite world, we assume that marketing never lies and never exaggerates. Accordingly, we happily rely on all the sales arguments being true and a piece of software (as promised) being able to do EVERYTHING. In the case of commerce software, that means: it boosts conversion, reduces process costs, is easy to use, of course modular, individually customizable, flexible on terms, future-oriented and so on. AI, cloud and SaaS are on board too, naturally. Whether it is a shop system, middleware, a PIM, a payment provider, a recommendation solution or something else does not matter at all for now. Practically everything is in the soup that the experienced IT chef keeps as buzzword-bingo seasoning in their kitchen.

Of course, in our opposite logic we also have them show us some cases that ideally have nothing to do with our own situation. If you see that the software works elsewhere, who cares whether the solution fits your own requirements? In the end, any software can be bent into whatever shape you need. Customizing for the win.

Now the question arises WHO should best decide which solution fits, so that in the end nothing fits at all. Which brings us to the next rule:

To provoke maximum failure, the internal IT department, often still affectionately called "data processing", should pick the software. Perhaps even in cooperation with a very conservative data protection officer. Because who cares whether the users can work well with it later? The main thing is that the right ISO certification is in place.

Second option: if there are in-house developers, they can simply pick the software too. And on the basis of their own interests, at that. Who fancies which programming language? Who heard something from a buddy? The cool new stuff has fortunately long been battle-tested, there are no teething problems, and the trends will surely last a long time too, we all know that, here in the opposite world. Anyone who has gained their first experience with Kubernetes solutions for e-commerce or PaaS in recent years may have an inkling of what we mean.

Which brings us straight to the next topic.

Very common and simply wonderful if everything is meant to fail: after the IT silverback has picked the hottest stuff that nobody but him understands, it is a "killer move" to hand responsibility for the entire implementation project to, say, the marketing department.

That is bound to blow up. Hurray! The IT department has no time whatsoever for "that sort of thing". They have to look after the outdated ERP day in, day out so the shop keeps running. The big decisions are made after 2 workshops. "And surely marketing can handle that little bit of shop," thinks the self-assured resident of failure-land. After all, the marketers will have to maintain promotions and run campaigns later anyway. Then this team can simply tell the agency directly how it should all turn out. The IT department stays out of it. Really important if you want to end up against the wall: keep the decisions of IT and marketing as far apart as possible.

So now we have already explained how we get a short list of systems and who should choose here. But how do you actually know which requirements to place on a system?

It is super helpful for failing to get everyone involved on board as far as possible and to take their use cases into account. You could also consider the level of experience of the various people here. Because nothing is more dangerous than unknown unknowns.

The important thing is to bring in no professionals and simply write down what you already know. Ideally, do not even question processes that have grown historically, but just reproduce them exactly the same way.

That is great for failure, because the more precisely everything is planned in advance, the greater the chaos later when real life shows up on the doorstep. And here you get to fail twice over. First you burn endless time on the requirements spec, and then, when everything turns out differently, you invest at least as much time again. Double the waste, therefore. Yippee!

Optional: do nothing yourself. Instead, ask around whether anyone knows someone who has done something like this before.

To maximize the confusion, we suggest the following next:

Here there are 2 options for further failure:

Please request only individual RFPs, so that nobody knows what the others are doing. That way everyone gets the chance to nicely barge into different projects, and the blame games can begin.

Set up a monster project by simply replacing all systems with modern solutions at the same time. Who needs step-by-step plans? It is much better if the overload hits every department at once.

If tip 1 is followed, meaning other systems are ignored, then it usually blows up very quickly, because with the exact planning at the start (see previous tip) it was, for example, not clear at all that the interface from the modern shop system to the old ERP has to be rewritten completely. Because: the plugin recommended by the shop vendor is not compatible with the ERP at all, oops, and the order data was not handed over cleanly. You can conveniently blame the implementation partner for that and demand that they deliver the additional 80 person-days for interface development (which was not originally part of the project scope) on top, at no extra charge and with no impact on the schedule. That way you have a poisoned mood in the project team very early on, and that is helpful for failure in any case.

If tip 2 is followed, meaning as many systems as possible are swapped out in one monster project, then it achieves the effect that, over time, the people involved in the project lose focus. A planning situation arises like back in maths class when you had a formula with too many variables: you can no longer calculate it, but have to plug in different numbers and see whether something sensible comes out. Trial and error, basically. That is trendy in the working world right now anyway, fail often and fail fast.

Since we are already gathering requirements:

But please do not define beforehand exactly what that means. We all know that if you ask different people to draw a house with a tree and a sun, they all end up looking exactly the same. Or don't they? So what is the point of this shared understanding and speaking the same language?

It is better to get into a dispute, along the lines of it all having been meant quite differently. And that it is surely clear what state of the art means. On top of that, it creates a thoroughly pleasant atmosphere in the collaboration. But never mind. At some point the project will be over, and then you can finally argue about open invoices and blame each other for delays and extra work. Peace, joy and mudslinging in failure land!

As a rule, an IT project such as a shop implementation is not an isolated project within the company, but interacts with other IT systems and is therefore embedded in a larger context. A shop project is often a sub-project, usually a very large one, of the overall project "expansion of the IT architecture".

A first step toward failure would be to disregard these different dimensions and not clarify responsibilities. Also very helpful for failing: assign these different responsibilities to one and the same person. That person will then pretty surely lose focus at some point and get lost in the various requirements. So please do not split it across two people with a clear focus. Otherwise the project might work out, and we do not want that.

Failure becomes really certain, by the way, when, without explicit clarification, you expect the project management of the shop agency, practically unspoken, to also take responsibility for the entire IT project on the side. Including coordination of everyone involved internally and externally. They simply cannot do that, and so it is bound to go wrong. Wonderful!

It is also important never to bring the different service providers and parties together at one table to talk to each other. Ideally, everyone first tinkers away on their own. See what can I do and what do I have?

If you prepare this well, you can later, when difficulties arise, simply blame the project leads of the sub-projects at random. That way you really achieve chaos of a very special magnitude.

Watch out! We are now finally, after half an eternity, starting our project. But how do you best get going here?

We all know how important it is for an online shop to be "pretty". So, to be safe, do not wait for feedback from the market at all, but first commission an expensive design. During implementation, start with that accordingly and discuss every pixel for as long as possible.

If timing problems then arise later on when testing the processes, well, that is just how it is. Who cares whether the order arrives cleanly in all systems? What matters is that the banner looks great in every conceivable size. And let us be honest, we all know that otherwise the customer will not order in the first place.

Besides, it is much better if error analysis runs during live operation. Especially if something in the checkout does not work. It is much better if everyone hunts for the bug with sweat on their brow under explosive pressure. Maybe there is also the option to deploy on a Friday afternoon. Then, if something falls over, everyone still gets something out of it over the weekend. And maybe extra costs for SLA hours even arise.

And on we go with the implementation. Here we still have quite a bit of potential for failure:

From the outset you should try to bend the chosen software so that it adapts to your desired processes. We did talk about standards right at the beginning, but it was surely clear that we meant that differently. Whatever you do, do not let yourself be tempted to do foundational work internally.

It is hard to imagine what would happen if the product data were first cleaned up and enriched properly, so that personalization, filtering and search can work optimally, and across different channels at that.

No, no, nobody has time for that. Besides, it somehow worked before, so we would rather not touch it. That way you also get the chance to keep getting worked up about the incompetent agency, the useless technology and so on.

On top of that, you ensure that new projects can only be implemented semi-well too, because the foundation is not right. Workarounds also create more work, so it is already clear that you are not doing (revenue-generating) efficient work and stay stuck in the old rut. How else could you get worked up about always having so much to do and nobody getting around to their actual work?

Anyone who thinks we have covered everything in the implementation is mistaken.

It is always desirable to skip proven technical practices like code quality, tests and maintainability in order to save time. You can always deal with it later. And the saying "nothing lasts longer than a temporary solution" is a pack of lies anyway. Maybe this holds instead: "the product matures at the customer's, after all".

The nice thing about it: if the team already ensures during the project that topics are not worked out cleanly, there will be minor to major challenges as early as the first updates and adjustments. Everyone gets annoyed because nobody knows anymore why anything is the way it is. Nobody likes working with the system. Perfect!

And when responsibilities change, others get something out of it too. Great.

Where are we right now? The software has been picked by the right people, nobody carries responsibility, design is being worked on, technical debt is being implemented, all that is missing is the go-live, right?

What is this newfangled talk of MVPs worth anyway? If you really want to make sure that every budget and every timeline is blown, then only ever go live when truly every feature anyone ever thought about is live and every pixel sits in the right place.

Everyone knows, after all: a platform like that is finished at some point and does not need to be developed further. And what is this odd market feedback supposed to be anyway?

And software and technology do not keep evolving anyway, right?

Objective: simply let the project's budget spiral completely out of control, go live only next year or, even better, take the failure to the extreme and do everything to get the project scrapped entirely.

Breathe in. Breathe out. Let it sink in. Have we "flopped" enough by now? Right. So to finish, let us flip back once more. Welcome home, to the world of success. Enough with the big, colourful failure fantasies. We are sure: anyone who has engaged once with the logic of failure will immediately come up with a wealth of ideas that help do it better. And should things still go wrong here or there, well, there is also us. We at Shopmacher have rescued so many projects from a near-crash that we have a solution for every problem. Promised.