Oh my dear tender

Calls for tenders in times of digitisation – or: What successfully hinders good offers

Are you currently involved in a tender? Perhaps as an author providing content for it? As the person responsible for the implementation? As a supplier who offers something?

If you work in the automotive industry, then you are lucky. Here, it is highly probable that the request for quotation is structured, the requirements are identifiable and individually tangible, the transmission is completely digital, and in such a way that the recipient of the request simply has to import it and can respond to each one. The processing of a request for proposal can then focus entirely on the content.

Some other industries are in a completely different position.

Daily life with tenders

Invitations to tender are created in Word, exported as PDF (sometimes only in change mode!) and sent to the supplier.

The supplier has to make something out of this PDF that he can work with again. If it is a “real” PDF, then this is still possible to a certain extent, if it is a PDF that has been created from a scan and contains images, an OCR must first be performed. Additionally required tools and a lot of manual work are the result.

The contents are often legally influenced, deeply nested (even enumerations with 10 nesting levels occur), the requirements are not individually identifiable, misleading, unclear in context, incompletely described.

If the experts at the supplier, who have to take care of the import of the requirements, want to exchange information with the corresponding experts at the customer, for example to be able to get the requirements in a different format, this is often impossible. Communication between the two sides is exclusively via the project management, and they often have completely different problems than those of dealing with other document formats.

All this is not something that is just an empty phrase, but something that happens every day in many companies in this country (and there are plenty of other examples). The only digital aspect is that the documents are sent digitally, for example via a tender portal. The entire process – the creation of the tender, the transmission, the processing, the return, the evaluation – is highly analogue.

The pure inefficiency of tenders

Have you ever thought about the problems caused by these procedures that are common today?

• How should an offer address the actual problem of the customer, if it is not described so explicitly anywhere?
• How should an offer be prepared efficiently – i.e. in the highest possible quality, at the lowest possible cost, with the highest possible level of competence – if the requirements of the tender can only be converted into a digitally processable form with great difficulty?
• How should these requirements be processed by the individual departments if it is not clear where a requirement actually begins and where it ends?
• How should adequate solutions be offered when things are specified in extreme detail but the reason for this is not even remotely apparent?
• How is the best solution for the customer’s problem to be found if the solution must be based exclusively on what the customer can imagine so far?
• How should a request for quotation be processed appropriately, if a large part of the already scarce time spent on processing the request for quotation is wasted on the preparation of the request for quotation and the budget of the suppliers is already significantly strained by this alone?
• How are errors to be avoided when the entire process is highly susceptible to disruption and errors?
• So how is the result, i.e. the product or service offered, supposed to have the necessary quality if already during the offer phase almost all hurdles are set up which can be overcome?

The product to be delivered at the end of the process cannot really meet the true requirements and needs of the customer if serious risks are created at this early stage – risks that have a direct negative impact on quality, costs and performance.

The problems of the tenderers

But it is not only the suppliers who are affected by all these problems – even worse: these problems ultimately affect the tendering party.

• How is the tenderer supposed to compare the incoming offers reasonably if the requirements are not identified individually?
• How is it possible to obtain a complete picture of a service or a feature if the content of individual requirements that actually belong together is located in many widely separated places in the requests for proposals?
• How sure can you be that you really understand what was offered – if it was not previously ensured that the requirements were written clearly and unambiguously?
• How can the processing of the offers be efficient if the suppliers (have to) return the offers in the same way as they received the request for quotation – as a document, as Word, as PDF?
• The problems that are created at the time of the request for quotation influence all subsequent phases – rarely positively, and even less often cost-neutral!

Perhaps this makes it clear to some extent the importance of effective requirements management (RM) in times of digitisation already at the time of the tender.

Better design the work with tenders

The automotive industry developed a solution here many years ago that could be adopted immediately in other industries, and it is described in one word: ReqIF.

ReqIF stands for “Requirements Interchange Format” and describes an OMG standardised format for the exchange of requirements. Virtually every professional requirements management tool on the market – whether it is a low-cost, single-user-based solution or a large, enterprise-wide solution such as DOORS or Polarion – is capable of exporting and importing requirements as ReqIF files.

If you use such a tool to create the request for proposal, you immediately have all the advantages at hand:

• The requirements are clearly identified.
• Each requirement stands on its own and can be specified in a self-contained manner.
• Requirements can be provided with attributes, for example, to map the responsibility for a requirement and thus better organize the work.
• All requirements are only and exclusively available at a single location – there are no more questions like “where can I find the current version of…?
• Requirements or sets of requirements can be versioned. So if you define a version 1.0, it is exactly clear and traceable which requirements belong to it.
• The suppliers get an export, which they can easily import into their own RM system. Better still, you can also easily set up updates and easily detect changes from the previous version.
• You can specify exactly which content should be sent to your suppliers, which of it should be read-only, and which information should be added by your suppliers.
• Suppliers can easily write their responses to the tender in designated attributes, which in turn can be imported into your own system on the way back.
• This way you can see immediately how each supplier has responded to each individual request for quotation without any additional effort on your part.

And that’s certainly not all the advantages for both sides. Needless to say that the costs and risks for the tender process, but also for the product in question, are significantly reduced.

Requirements management as part of the DNA

That doesn’t mean, “We’ll get one of those RM tools and everything will be better.” An RM tool is not much use if it is only seen as a replacement for an Office package. In fact, it means: Requirements management must be embedded in the DNA of your company.

Anyone who writes requirements in your company must master this craft. Whoever is involved in a tender must understand the importance of formulating requirements. What criteria there are for the quality of requirements. How requirements are handled sensibly and how the necessary processes are set up and developed step by step.

Each participant must have an understanding of the principles of requirements management – requirements as a “single source of truth”.

RM experts on both sides must be able to communicate directly with each other when there are questions about data exchange – this avoids the otherwise usual “silent post”. The data exchange can then take place as quickly and optimally as possible, and the requirements and offers are available to the specialist departments without significant delay and without loss of quality.

In short: your company must understand requirements management as the backbone of its value creation. Once this is achieved, an RM tool and the handling of requirements will be as natural as the handling of an office package is today.

So the only question that remains is: When will you begin to conduct your tenders digitally rather than in analog or pseudo-digital form?

Notes:

Gerhard Schneider has published another post in the t2informatik Blog:

What does t2informatik actually do? One click and you'll know.