Nico Kotsapanajotou
11. Februar 2022
5 min
A structured evaluation of software is fundamental to the success of any e-commerce project. Even today, numerous mistakes are made that are completely unnecessary. The following tips guide you through the evaluation of e-commerce projects.
The form and quality of the known requirements decisively define the process of software evaluation. Ignoring important insights can have far-reaching consequences right into the implementation of the project and sometimes even lead to the failure of a project. Therefore, it is important that as many of the requirements as possible are provided in advance in a detailed but clear format. Never use user stories in the evaluation phase, they should be used later (if at all) in the implementation. Clear means: preferably in tabular form in an Excel file. A vague requirements document in an undefined format leads, among other things, to the fact that the feedback of the solution providers or agencies is not comparable. Therefore, it is essential to specify the form for the feedback so that comparability is guaranteed!
E-commerce systems communicate data between different databases via interfaces. The central medium of software is always data. In addition to features and the general conditions, a successful evaluation also includes the creation of data models. This usually includes at least product data, customer data and order data. These data models should be fundamentally examined and challenges in implementation discussed with service providers. Last but not least, they serve as a basis for the creation of interface descriptions.
If you let yourself be taken in by the first provider (preferably by cold calling), it's your own fault. Highly complex enterprise software is not a prefabricated product that I can configure with a few clicks and then buy exactly like a car, for example. Software has to be customised in many places so that it fits your processes. Therefore, it is important to contact different providers (agencies or software providers) and confront them with the relevant questions. It is best to obtain feedback from several providers on the basis of the requirements catalogue and compare them conscientiously.
Many sales staff (especially in the e-commerce environment) today have extensive technical understanding. Nevertheless, it is essential to evaluate software projects on a technical level as well. This also includes fundamental questions around hosting, interfaces and microservices. Therefore, it is indispensable to bring your own IT team (if available, otherwise your own service provider) as well as techies on the provider side to the table. Above all, the technical competence on the other side should be checked. In the case of agencies, it is also advisable to get to know the responsible software architects/developers and to shed light on their background and competences. Many software projects go awry because the teams on the agency side are overstretched (qualitatively or quantitatively).
It is important to meet with the departments involved before the start of a project. Not only in the sense of successful change management, but also in order to shed light on central issues with the respective expertise. For example, when selecting a new e-commerce system, it is extremely relevant to know the various requirements from marketing, logistics, IT and other involved departments and to discuss proposed solutions internally. This is the only way to prevent major blocking hurdles in the execution of the project.
As in implementation, deadlines, especially fictitious ones, are often the driver for wrong decisions. Many C-level managers take a bird's eye view of essential projects and do not understand that making a decision only because of a deadline can have far-reaching consequences. It is better to fight hard for an extended deadline than to start a project with a queasy feeling!
Budgets are also often allocated without any justification. Anyone who still presses a software project into a rigid budget corset in 2022 has misunderstood something. Rather, budgets are called up over a period of time anyway, which is usually longer than expected. Therefore, it is better to evaluate a solution that fits the rough budget framework, but if this is justifiably increased, it is essential to compare costs and benefits and, if necessary, increase the budget before building an aircraft without seats.
It always makes sense to deal with the desired design at an early stage. Thus, one should work on a design guideline or a digital CI guide as soon as possible. Nevertheless, one should take into account that the solution and especially the solution path often have implications for the designs. For example, if I choose a frontend framework (such as Vue Storefront) and express the desire to stay close to the standard in order to keep costs from exploding. Then I first need to know the standard to ensure this. Often, the designs include features that do not exist or that need to be customised. Therefore, in the early phase, the design theme should be more concerned with colours, fonts, button styles and basic things, and then be enriched with detailed layouts after the decision for a system has been made.
It is essential that as many requirements as possible are known during the evaluation and that the future direction is clear. BUT: It usually makes sense for the first implementation phase to use only a part of the requirements within the framework of a well-structured MVP. This ensures that the project size remains manageable and you can go to market quickly. Also, if there are problems with the service provider, you can change the implementation partner again. Nevertheless, requirements for further iterations must of course be checked for feasibility. In the case of a migration from a legacy system, the first iteration should have at least the same functionality as well as some improvements that are not too costly. All further extensive requirements are then directly implemented in the new productive system. This way, you are on the market early and use the potential of the new software as quickly as possible.
Every ambitious project needs a capable project team on both sides (client and agency). It is essential that enough time is scheduled and that contact persons are not too involved in other issues (such as day-to-day business) in order to concentrate on the project. Prompt and well thought-out feedback on open questions is extremely relevant for the success of the project. If product owners have to consult too much with hesitant superiors who then only make vague statements, the chance of success drops drastically. It is essential that the responsible persons are able to make decisions themselves and provide the other side with all relevant information.
If the NDA (non-disclosure agreement) for the first talks goes back and forth ten times and two weeks of time are lost, then something is going wrong. It is essential to clarify basic issues, especially for large corporations, but if legal issues for the 100th edge case block the exchange and progress in the project, then you have to think about whether this is not too much of a good thing on the company side. Especially when working with smaller service providers, you have to be aware that if you declare compliance topics to be the central issues, you will only make slow progress.
