9. Feb 2024

11 tips on how to drive an e-commerce project into the wall with a vengeance

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

In the creativity technique, there is a method called the “flip-flop technique”. This has nothing to do with flip-flops, but takes into account the fact that most people’s psychology is much more creative when dealing with negative thoughts than when dealing with positive ideas. In concrete terms, this means collecting all the points that could contribute to the failure of a project, then “flip-flopping” them into the opposite and very quickly coming up with new creative solutions – beyond the usual patterns of thought and action.

So, let’s get down to business: do you want your next e-commerce project to be better than any before? Perfect, then let’s assume the greatest possible opposite. And not quite starting with Adam and Eve, but shortly afterwards: With the initialization.

In order to achieve the best possible crash, you should first consider the basis on which the project is to be implemented and who you want to involve. The decision for a base/platform is pending. There are countless options here. It is essential to work your way from a long list to a short list. So how do you ensure that everything goes wrong right from the start?

Rule number 1:
Trust the marketing promises of software manufacturers.

In our funny little opposite world, we assume that marketing never lies and exaggerates. Accordingly, we confidently rely on the fact that all the sales arguments are right and that the software can do EVERYTHING (as promised). In the case of commerce software, this means: it increases conversion, reduces process costs, is easy to use, naturally modular, customizable, flexible in terms of conditions, future-oriented, etc. AI, cloud and SaaS are of course also at the start. Whether it is a store system, middleware, a PIM, a payment provider, a recommendation solution or something else is irrelevant. There is practically always everything in the soup that the experienced IT chef has in his kitchen as a bullshit bingo of spices.

Of course, in our logic of the opposite, we also allow ourselves to be shown cases that ideally have nothing to do with our own situation. If you can see that the software works elsewhere, it doesn’t matter whether the solution fits your own requirements. In the end, any software can be bent to suit your needs. Customizing for the Win.

The question now arises as to WHO should decide which solution is best … so that nothing fits in the end. That brings us to the next rule:

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

In order to provoke maximum failure, internal IT – often affectionately referred to as EDP – should select the software. Perhaps even in cooperation with a very conservative data protection officer. After all, who cares whether the users can work well with it afterwards? The main thing is to have the right ISO certification.

Second option: If there are in-house developers, they can also simply select the software. And on the basis of their own interests. Who wants to learn which programming language? Who has heard from a buddy? Fortunately, the cool new stuff has been tried and tested for a long time, there are no teething troubles, and the trends are sure to last – as we know … here in the opposite world. Anyone who has had initial experience with Kubernetes solutions for e-commerce or PaaS in recent years may have an idea of what we mean.

Which brings us directly to the next topic …

Rule number 3:

Assign project responsibility to a person who did NOT select the software.

Very common and just great when everything is supposed to fail: After the IT silverback has chosen the hottest shit that nobody but him understands, it’s a “killer move” to give responsibility for the entire implementation project to the marketing department, for example.

That will definitely go down a treat. Hurrah! IT doesn’t have time for “that”. They have to take care of the outdated ERP on a daily basis to keep the business running. The major course is set after 2 workshops. “And surely the marketing department can do the little bit of shopping,” thinks the self-confident Scheiterland. After all, the marketeers also have to maintain campaigns later on. Then this team can simply tell the agency directly how everything should turn out. IT stays out of it. Really very important if you want to end up in front of the wall: keep IT and marketing decisions as separate 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 what requirements should be placed on a system?

Rule number 4:
Create as accurate an RFP as possible over a long period of time and include as many stakeholders and departments that have heard the word eCommerce before.

It’s super helpful for failure to get as many stakeholders on board as possible and take their use cases into account. The level of experience of the various people could also be taken into account here. Because nothing is more dangerous than Unknown Unkowns.

It is important not to bring in professionals and simply write down what you already know. It is best not to question processes that have evolved over time, but to reproduce them in exactly the same way.

This is great for failure – because the more precisely everything is planned in advance, the greater the chaos later on when real life arrives on the scene. And this is where it fails twice over. Because first you spend an infinite amount of time on the specifications and then, if everything turns out differently, you invest at least as much time again. A double waste. Yipieeh!

Optional: Don’t do anything yourself. But ask around to see if anyone knows anyone who has done this before.

To maximize the confusion, we suggest this next:

Rule number 5:
Ignore neighboring systems.

There are 2 possibilities in the event of further failure:

  1. Only individual RFPs please, so that no one knows what the other is doing. This gives everyone the opportunity to get involved in different projects and the blame games can begin.
  2. Setting up a monster project by simply replacing all systems with modern solutions at the same time. Who needs step-by-step plans? It’s much better if the excessive demands affect all departments at the same time.

If tip 1 is taken to heart – i.e. other systems are ignored – then things usually go wrong very quickly because, for example, it was not at all clear during the exact planning at the beginning (see previous tip) that the interface from the modern store system to the old ERP would have to be completely rewritten. Because: The plugin recommended by the store manufacturer is not compatible with the ERP – oops! – and the order data has not been transferred correctly. You can simply make the implementation partner responsible for this and demand that they take care of the additional 80 man-days for interface development (which was not originally part of the project scope) on top, without recalculation and without impact on the schedule. This creates a toxic atmosphere in the project team at a very early stage, which is always conducive to failure.

If tip 2 is followed – i.e. as many systems as possible are exchanged in a monster project – then this causes the project participants to lose focus over time. It creates a planning situation like in math class when you had a formula with too many variables: You can no longer calculate it, but have to put in different numbers and see if something reasonable comes out. Trial and error. It’s hip in the world of work anyway – fail often and fail fast.

While we’re on the subject of requirements:

Rule number 6:
Always mention that you want to do everything in the standard and that everything must be state of the art.

But please don’t define exactly what that means beforehand. We all know that if you ask different people to paint a house with a tree and sun, it will all end up looking exactly the same. Or not? So what is this common understanding and talk of equality all about?

It’s better to go into the dispute … as if everything was meant differently. And that it is clear what state of the art means. It also creates a totally pleasant atmosphere when working together. But never mind. At some point, the project will be finished and then you can finally argue about outstanding invoices and blame each other for delays and extra work. Peace, joy, mud-slinging in the land of failure!

Rule number 7:
Never clarify responsibilities in advance.

As a rule, an IT project, such as a store implementation, is not an isolated project within the company, but interacts with other IT systems and is therefore integrated into a larger context. A store project is often a sub-project – usually a very large one – of the overall “IT architecture expansion” project.

A first step towards failure would be to ignore these different dimensions and not clarify responsibilities. Also very helpful for failure: assign these different responsibilities to one and the same person. At some point, it will almost certainly lose focus and get lost in the various requirements. So please don’t split anything between two people with a clear focus. Otherwise the project could work … but we don’t want that.

Incidentally, failure is really certain if, for example, the project management of the store agency is expected – practically unspoken – to take responsibility for the entire IT project without explicit clarification. Including coordination of all internal and external parties involved. She can’t do that at all and that’s why it definitely goes wrong. Wonderful!

It is also important that different service providers and parties are never brought together to talk to each other. Ideally, everyone should tinker with it themselves first. Look, what can I do and what do I have?

If you prepare this well, you can simply blame the project managers of the sub-projects at random later on in the event of difficulties. This is how you really achieve chaos on a very special scale.

Watch out! So now – after half an eternity – we are finally starting our project. But what’s the best way to start?

Rule number 8:
A sophisticated design down to the last detail is much more important than good processes.

We all know how important it is for an online store to be “beautiful”. To be on the safe side, you should therefore not wait for feedback from the market, but commission an expensive design first. So start accordingly when implementing and discuss every pixel for as long as possible.

If there are time-related problems with testing the processes later on, that’s just the way it is. Who cares whether the order arrives cleanly in all systems? The important thing is that the banner looks great in every conceivable size. And let’s be honest – we know that otherwise the customer won’t order in the first place.

It is also much better if the error analysis runs during live operation. Especially if something doesn’t work in the checkout. It’s much better when everyone is sweating under explosive pressure to find the mistake. Perhaps there is also the possibility of deploying on Friday afternoons. If something falls over, everyone still benefits at the weekend. And there may even be extra costs for SLA times.

And the implementation continues. We still have a lot of potential for failure here:

Rule number 9:
More workarounds are always better.

From the outset, you should try to bend the selected software so that it adapts to the desired processes. We did talk about standards at the very beginning – but it was clear that we meant it differently. Under no circumstances should you be tempted to do grassroots work internally.

It’s hard to imagine what would happen if the product data were first prepared and refined so that personalization, filtering and search could function optimally – and in different channels.

No, no, nobody has that time. Besides, it’s already worked somehow before, so we’d rather not touch it. This also gives you the opportunity to continue to complain about the incompetent agency, the useless technology, etc.

It also ensures that new projects can only be implemented semi well because the basis is not right. Workarounds also create more work, so it’s clear that you’re not doing any (revenue-generating) efficient work and are still stuck in the same old rut. How else can you complain about the fact that you always have so much to do and nobody gets to your actual work?

Anyone who thinks that we have covered everything in terms of implementation is mistaken.

Rule number 10:
Make sure you implement technical debt right from the start.

It is always desirable to skip best technical practices such as code quality, testing and maintainability to save time. You can take care of it later. And the saying “Nothing lasts longer than a temporary solution” is a lie anyway. Perhaps “the product matures with the customer anyway”.

The nice thing is that if the team ensures that topics are not properly developed during the project, there are minor to major challenges right from the first updates and adjustments. Everyone is annoyed because nobody knows why things are the way they are. Nobody likes working with the system. Perfect!

And if the responsibilities change, others will also benefit. Super.

Where are we right now? The software has been selected by the right people, nobody is in charge, design is being worked on, technical debt is being implemented … all that’s missing is the go-live, right?

Rule number 11:
Only goes live when everything is really finished.

What is all this newfangled talk of MVPs worth? If you really want to make sure that every budget and timeline becomes obsolete, then only ever go live when every feature that has ever been thought about is live and every pixel is in the right place.

Everyone knows that a platform like this is finished at some point and no longer needs to be developed further. What is this strange market feedback supposed to be?

And software and technology are not evolving anyway, right?

Objective: Simply let the project get completely out of hand in terms of budget, only go live next year, or even better: take the failure to the extreme and do everything in your power to ensure that the project is completely scrapped.

Inhale. Exhale. Let it sink in. Have we “flopped” enough? Correct. That’s why we flip back again at the end. Welcome home, to the world of success. Put an end to the big, colorful failure fantasies. We are certain that anyone who has ever dealt with the logic of failure will immediately come up with a number of ideas that will help them to do better. And if there’s still a problem in one place or another … there’s always us. We store makers have already saved so many projects from near-crash that we have a solution for every problem. We promise.

What we can also do

Shopmacher Resources

We build your own development team

Shopmacher Consulting

Our experts help with their know-how

Shopmacher Operations

Know-how, capacity and development power on time.

Cookie Consent Banner by Real Cookie Banner