
Ideally, you have the full range of options available to design a lean, innovative, and efficient software tender. If you don't have this flexibility and have to resort to a traditional tendering process, you might find our tips from our everyday experience inspiring.
Have you ever noticed that technical aspects often take center stage in tenders? Have you ever wondered who the actual users are and what the specific benefits are? Before you begin preparing your tender documents, thoroughly examine the design of your overall concept! Define the level at which you want to define your requirements, carefully consider the benefits to be achieved, analyze the complexity of the environment, and consider the future users. And very importantly: Be sure to separate the problem from the solution!

No process, no tender! The current process is our foundation, and you must know it inside and out to create effective and understandable tender documents. Any method is acceptable for visualizing the process, from BPMN and process maps to use case models or your own custom designs. The specific method you use is irrelevant; what matters is that you have documented and understood the current process and that you are familiar with the complexity of each individual process step.

Based on the current process, you can now derive the desired target state and identify current problem areas. Even if the current tender is only a first step (MVP) in the desired direction, be sure to show where the journey will lead!

No tender without requirements! Now that you understand the process, you can derive requirements. Our recommendation: Stay at the epic level; otherwise, your tender documents will quickly become too extensive. Furthermore, try to formulate your requirements in a solution-neutral way and support them with examples. Ensure that all epic requirements are at roughly the same level of technical complexity . For example, assigning a unique case number is far less complex than a user review that includes automated calculations in the background. Always assess the technical complexity, not the implementation effort.

Even if you try to maintain a consistent level of expertise across all your requirements, there will always be some that are more complex or time-consuming, and others that are less so. Therefore, we recommend that you further detail individual requirements, which brings us to our fifth and final tip for today.
In an ideal world, you could now produce a list of use cases, including brief descriptions, for each requirement. However, at the time of a tender, often only some of the use cases are known, and their complexity and maturity level are insufficiently documented. To still be able to give potential providers a comprehensive picture of the complexity and scope of your project, we recommend defining a technical complexity scale for your use cases.

Select three use cases that you know meet your defined business complexity scale. For example,
Describe each of these use cases in such detail that a developer can estimate its implementation effort without significant uncertainty. We use classic use cases and acceptance criteria for this and visualize them using BPMN or UML. The specific method you use is irrelevant – what matters is that you convey a complete picture of the selected requirements, including business rules and processes.

For each requirement, you now define how many use cases of each complexity level it contains. The greater your uncertainty regarding the number and the lower the maturity level of your requirement, the larger the safety margin you should include in your estimate.

In our next blog post on this topic, we will reveal a helpful tool and a tip on how you can obtain an accurate quote estimate from the suppliers with minimal effort.
Would you like to utilize our expertise and implement technological innovations?


Do you have a question or are you looking for more information? Provide your contact information and we will call you back.