TOP 10 mistakes to avoid if you want to run a successful eCommerce project

Markus Cansever is working as General Manager at Valtech Germany & Management Consultant for eCommerce since more than 15 years, including brands like adidas, Audi & BMW. He holds also various certifications in the area of international project management and agile deliveries.

This article is an excerpt from his personal experiences of the last 15 years in enterprise eCommerce projects. Feel free to contact him directly for more insights.

1. No pre-phase planned before the actual development of an ecommerce project starts

It is very important not to start right away with the development, getting the complete team running. You should think of a thorough pre-phase (there are so many names for the phase before a project starts), covering these topics at least, if you start an ecommerce-project:

• Business Goals
• Project Governance, esp. Roles & Rights & Meeting Structure
• Technical Deepdive
• UX & Design Deepdive
• Development & Deployment Approach
• Functional & Non-Functional Scope
• Rough estimation with fitting methods

2. No backward-planning in the beginning has been done, the complete scope has not been roughly estimated

Assuming that the project is about to start, it is very important, ideally after or during the discovery phase, to plan the project backwards, with the complete team. Everybody should know where the project is aiming at – and you need to be realistic. Therefore, it is a must to define the scope and communicate the scope, along with a rough estimation, done by the cross-functional team.

Don`t concentrate only on the scope & estimations, it is also important to plan these phases realistically:

• Technical Onboarding (and this phase is not over until the access & environments are ready for each and every team member)
• UX & Design Validation / User Tests / Interviews
• Content Translations
• Training (for Admins and for Content Manager)
• Cutover-Phase

3. No empowered Product Owner(s) or Decision Makers available. Decisions are not taken or are taking too long

Forget about thinking that everything will go fine, as expected, even if you did the best discovery phase, estimation and you have the most experienced team on your side. It will always happen that something is not clear enough, or changed during the project, or that the idea / requirement in the beginning makes no sense anymore.

Think about this: the team is super motivated, every 2 weeks code will be deployed, that the application is getting more and more tangible. Nothing is more frustrating for the team, if there are waiting-times and a lot of important topics are not clarified or decisions are missing.

The point is, that when starting an eCommerce project, you have a plan: the team starts with the most critical tasks, to have the easy requirements in the end of the project. So if a lot of decisions in the beginning are getting moved or put aside, the risk for failing within the project increases pretty fast.

4. Product Owner or Project Lead focusses either heavily on design or on technical aspects

Even if decisions are taken, the Product Owner (Decision Maker or Project Lead) should neither focus in the beginning on UX & Design requirements only, nor on the technical aspects of the project.

Why is that?

This is pretty easy: a successful implemented and delivered project relies on the holistic planning and overview. Project Managers are completely wrong, if they think we need to finalize every UX & Design concept before we could start with the functional implementation. This will result in disappointed team-members, when they realize that the shiny designs can`t be realized sometimes, cause there are natural technical constraints.

The other way round is also wrong: don`t think of doing first all technical aspects for example, and then start with the UX & Design. And also here, if this happens, the technical circumstances could drive the UX & Design concept, what you should also avoid. The customer should be in the center, no one else. A balanced planning of the important topics is key, together with a cross-functional development approach, where the user stories (agile expression for requirements) are treated holistically, with technical & UX stakes.

5. Project Milestones are not set & tracked

Often milestones are missing in agile delivery setups, because there is a common misunderstanding, that in an agile setup, milestones are not existing, that no discipline is needed or that everything is flexible. This would be a huge mistake.

In the last decade while running eCommerce project, the following milestones have been really paying off, you should track them very closely:

• Environments are ready
• Core Integrations to Backend-Systems done
• UX & Design Master-Concept finalized, including also Sitemap, Template Approach and Component-Plan
• International Projects need a multimarket-strategy, this needs to be finalized before crucial parts can be developed
• Payment Service Provider integration finalized
• Testing Concept
• Content & Content Management Concept
• Training Concept & Training phase
• Cutover & Release Concept

6. Important technical deep-dives (Spikes) have been missed out

We just learned that you should not focus e.g. either on UX & Design only, nor on technical stuff. But is also crystal clear, that you can`t miss the most important technical clarifications or “Mini Implementations / Checks” (in agile projects they are called “Spikes”). This is even more crucial if documentation is missing from a legacy system. Don`t get scared, there are repeating technical topics in eCommerce projects that need to be tackled in a thorough manner, from the very beginning of a project.

Here some examples:

• Data Model / Product Data Import
• Stock / Inventory Mechanism / Reconciliation
• Catalogue Structure
• Navigation Structure
• Search Index
• Order Creation / Export / Status
• Customer Creation / Export / Import
• Price Calculation
• Payment / Authorization
• Shipping Information / Consignments
• Cancellation / Returns

These topics are getting even more important, if we are talking about an international / global shop or true omni-channel / multi-channel setups.

7. No clear Golive scope defined, or constantly changing scope

Nothing is more frustrating for a Project Lead, Project Manager or actually for the complete project team, if the business goals or the Golive Scope is not clear from the very beginning of the project or constantly new requirements are disturbing the project.

Absolutely fine, if there are some things not clear, but you have to apply at least some rules / guidelines in regards to the Go live scope, otherwise the team will be demotivated and the project will fail, in terms of timing and costs:

• Nothing against setting a dedicated go live date, but do it realistically
• Use common methods, like the MoSCoW prioritization: give advice what must be ready before the Go live can happen, what should be realized and what can be realized
• Even better: give percentages for the above mentioned categories, saying: we need to reach 100% from the Must-Requirements and 75% of the Should-Requirements, to be able to Go live
• Also very helpful: introduce “Trading Options”: if a new requirement is introduced, and there is an agreement this could be done, trade this new requirement against a differ requirements in the backlog for the Go live. With this mechanism you prevent the demotivation of the team and the fact that this causes stress in the very end of a project, because things have been pushed to the end.
• Simple: if you allow that new requirements coming into the sprints, there is no way not to move the Go live date or increase the team. Everything else would end in chaos. But be careful: even if you increase the team, please be aware that there are so-called overhead-effects while increasing an already running team, for onboarding, knowledge transfer, project setup, etc.

8. Platform standards / out of the box features are not considered properly / matched against requirements, to save time & efforts

This topic actually has nothing to do with project management or governance itself, but I saw a lot of projects with enterprise platforms fail, because the platform selection process was not detailed enough or during the project the platform standards have not been considered properly, to gain leverage in terms of speed and less efforts.

To put it in a nutshell: discuss with the product owners from the very beginning (ideally in the pre-phase) the requirements with the following scheme:

• Can this requirement be realized completely with an out of the box function of the platform?
• Can this requirement be realized with a configuration of an existing function of the platform?
• Can this requirement be realized with a customization of an existing function of the platform?
• Can this requirement be realized only with development-efforts, because there is no function provided by the platform?

Important during these discussions: focus on the business aspect / the customer centric approach. Don`t let the scope of a platform drive the scope of the project, but also not vague ideas / perfectionism.

Ask yourself: do these requirements ease the life of the online shopper? Is this needed to drive conversion / orders?

And of course: if you find out that the ratio of the out of the box functions or configurations are pretty less, it might be the wrong platform…

9. Delivery team is not mature enough or not stable or not complete

The best project manager or product owner is helpless, if the team is too late complete or if the team is not stable in regards to the team members.

This is pretty straight forward: if you miss key-roles or if they are constantly helping out in other projects or if the estimated number of people is not reached, you won`t have a chance to keep the timeline and quality aspects of the project.

The dangerous thing: you will not notice this in the beginning of the project, everything speeds up, you see first results, etc. But after some weeks you start realizing the effect, when first bugfixes are consuming time of the team or when technical aspects need to be touched again, during spikes. So please track the completeness and roles of the team carefully, and raise this as a major risk in the very beginning of the project. Also, if planned people are not taking part in important meetings. This is also a sign for parallel-projects. The same counts for the maturity or skills of the team. If the bug ratio increases or sprint goals have not been met consecutively, this is often a clear sign that the experience is missing within the team.

The same stands for the following aspects: if estimations are not met frequently without reasoning or if requirements are bugfixed three or four times.

10. Too many other projects in parallel are happening

Often there are more projects ongoing when an enterprise eCommerce project starts, like a CRM initiative or a PIM (Product Data Management), this is not unusual and per se a bad thing.

But you need to take some hints into consideration, to be on the safe side:

• If possible, exclude requirements that are dependent on other parallel projects. Sure, this won`t work in many cases, but you should try at least
• Try to work as close as possible with the other project teams together, that handovers are working smoothly without delays. Setup a dedicated meeting only to align on the parallel projects, where the groups are presenting their progress
• Try to come-up with mitigation-strategies: what would happen if the project a is delayed, what impact would this have on my project? Clear, you need to know exactly what the parallel project is delivering for your project and what you can cover e.g. with modifications or standards within the platform. Only then you can discuss these mitigation-options. As an example: the new PIM-Project is delayed, you won`t get the product data in time for your eCommerce project. If you know this early enough, you can think of manual imports and maintain the product data only within the eCommerce platform for the Go live. This secures e.g. revenue or the marketing announcements. Sure, you need to balance out such mitigations decisions: are you destroying business processes, is the architecture of the system jeopardized or is the mitigation not scaling?