Prototyping instead of specifications

The evaluation of business software is one of the major challenges facing SMEs. The person responsible is not familiar with the software market, does not know the strengths and weaknesses of the products and solutions offered and is not a software specialist.

In fact, the objectives of a selection process would be clear: The new software product should meet the requirements (solve the problem), and the costs of implementation and timeframe should be clear (quality, cost, time). But how can an SME manager ensure that he is selecting the right vendor and the right product from these points of view?

The pitfalls of the specifications

Most companies create specifications with all known requirements and send them to the vendors for comment. The requirements in the specifications are usually grouped into categories (“technology,” “usability,” “evaluations,” etc.) and almost always have an importance attribute such as “killer,” “must” or “nice to have”. The vendors fill out the requirements catalogue, provide pricing information and send it back to the potential customer. They decide on a product based on the “objective” information of the providers.

So much for the theory. In practice, it looks less rosy: The suppliers, represented by their salespeople, naturally want to sell their product, and interpret any ambiguities and omissions in the wording in their favour. In the best case scenario, the ambiguous requirements are written “unclear, needs to be discussed.” So the customer gets a more colourful answer to his specifications. But the customer feels on the better side, because he can incorporate the specifications’ answers into the contract. In this way, potential problems are not discussed, since both parties actually agree that after signing the contract everything will be better anyway (Customer: The provider has agreed to the scope of functions, Provider: Once signed, we tackle the problems if they occur).

As a result, potential problems are not addressed, because neither party has an interest in seeing the difficulties as they arise as soon as possible. As a result, many problems emerge late in the project. The more resources it consumes to solve such problems, the longer the project has been in the wrong direction.

The fact that one can argue well about entries in a specification (which means: “The most important evaluations can be accessed quickly”?) can finally lead to ugly legal disputes that do not help any of the parties involved.

Stomach and head

Selection procedures with specifications have a number of other disadvantages. For example, solutions are often described instead of the requirements (“chart of accounts should be editable in tree view”). This leaves little room for the provider to present his solution to a problem. The subdivision of the criteria into “must,” “can” and “want” is also often problematic, since the “want” criteria are the most important in the stomach of the customer.

Also bad are evaluation procedures with specifications, in which the customer has actually already decided on a solution in the gut, but still wants to “scientifically” back up his decision. The specifications are then formulated in such a way that it fits exactly with a solution – the evaluation becomes a time-consuming, expensive idle.

Rapid prototyping with standard software

In recent years, we have developed a method for implementation of business solutions in Sme that seeks to remedy this obvious anomaly. The method is based on the engineering method of 'rapid prototyping’, which is why we named it that way.

Without having to produce a lot of paper or talk abstractly about the exact requirements, the vendor creates a prototype of the future solution with the help of the software product to be used. The product must of course allow this, so it must be sufficiently flexible and parameterizable so that different requirements can be mapped without further continuous improvement of the software.

First, an attempt is made to find a solution for the critical or unclear requirements. This is done by direct configuration of the software at the customer’s premises. The project leader of the provider works out a possible solution in the course of project meetings on location, together with the future users. This procedure ensures that the communication channels are very short and that the customer can react immediately to solution proposals. Of course, it is a great advantage for the creation of the prototype if the customer knows his problem (or his requirements) exactly, but it does not have to be all in a detailed written form.

At the project meetings, other professionally involved people on the customer’s side should be present. This allows them to comment directly on the consultant’s solution proposals and are also better prepared for testing the prototype. The prototype is iteratively refined in project meetings at short intervals (one week). Between two project meetings, the customer’s employees check the prototype thoroughly and submit their suggestions at the next project meeting.

After a few iterations, the prototype is mature enough that the customer can decide whether the product meets his needs. If he chooses the product, much of the customization work has already been done, or at least planned. If he chooses not to implementation the product, the efforts have never been wasted, because firstly, the customer now knows his needs much better, and secondly, he has been able to avoid a misinvestment in buying the wrong product.

“Feeling” instead of forms

The great advantage of “rapid prototyping” over detailed specifications is that the customer can “feel” his solution at an early stage and get to know the supplier’s employees (consultants, project leaders) right from the start. Since the prototype analyses the most important and critical requirements in depth, misunderstandings in the project quickly come to light. a prototype can also help with requirements management, especially in formulating use cases, because the prototype allows the customer to get early feedback and check if the original requirements were correctly formulated.

Many software projects become disproportionately expensive because new requirements arise in the course of the project. Again, a prototype can help because the customer can see and “feel” the product live, and so will think about additional requirements already at the offer stage

Especially for SME managers with little expertise in software and technologies, prototyping offers the opportunity to get a taste of the future solution. Since the prototype is created together with the supplier of the product, the customer also gets to know the configuration possibilities of the product in depth, so that separate training of key personnel at the customer’s site is usually unnecessary.

Prerequisites for rapid prototyping

The approach with prototypes developed by the customer is not suitable for all projects. The most important prerequisites are:

• The contact person or project leader at the customer is familiar with the problem and can decide whether a solution meets the requirements
• The project leaders on both sides have sufficient skills to make difficult decisions during the project
• The customer must have a clear idea of what is needed
• The vendor-side salesperson must have a deep technical understanding and know the customer industry well. It is best for the same person to oversee the product implementation later on.
• The product must be simple and configurable in many ways, so prototyping is possible at all. The vendor’s project leader must have a very good knowledge of the product and be able to make the most important changes to the prototype within minutes.

A detailed description of the implementation process can be found on the vertec standard implementation project page.