The tender is published. The budget is approved. The first bidder questions arrive.
At this point, the project should be on solid ground.
Yet in reality, many IT projects are set on a problematic course months before the tender is even published\u2014not because the providers are unsuitable or the technology fails, but because essential preparatory work was never carried out.
In our consulting practice, we repeatedly observe the same patterns. Most problems arise long before a single line of the requirements specification is written.<\/p>\n\n\n\n
<\/p>\n\n\n\n
Often, only symptoms or assumed solutions are discussed, such as: \u201cWe need a modern solution\u201d, \u201cUsers are dissatisfied\u201d<\/em> or \u201cWe should use AI.\u201d<\/em> These statements rarely describe the actual problem to be solved.<\/p>\n\n\n\n An analysis often reveals that the real problems are organizational in nature or can be resolved through adjustments to existing systems.<\/p>\n\n\n\n <\/p>\n\n\n\n Many tenders detail what a system should be able to do and which functions are desired. Rarely, however, do they explain why<\/em> the system is being procured in the first place\u2014and this is precisely the critical question.<\/p>\n\n\n\n A clear distinction between performance objectives and usage objectives is essential. While performance objectives describe the functions and characteristics a solution should have, usage objectives define the actual benefits for the organization, such as shorter processing times, lower costs, or improved data quality. <\/p>\n\n\n\n Many organizations hold workshops to gather requirements, resulting in long wish lists.<\/p>\n\n\n\n Requirements engineering is not about collecting requirements\u2014it\u2019s about identifying, understanding, questioning, elaborating, and prioritizing the right<\/em> requirements. Investing this time ensures not just a tender process, but the procurement of a sustainable, maintainable, and beneficial system.<\/p>\n\n\n\n <\/p>\n\n\n\n The business department describes its wishes and needs. IT outlines technical constraints. A gap often forms between them. The consequences include contradictory requirements, unrealistic expectations, and misunderstandings among providers. <\/p>\n\n\n\n A new system often merely digitizes existing weaknesses. <\/p>\n\n\n\n Many tenders include hundreds of functional requirements. Yet a system that meets all desired functions but is slow, insecure, or unmaintainable is often perceived as a failure by users.<\/p>\n\n\n\n These aspects can determine the success or failure of a project, particularly in critical infrastructures and public institutions.<\/p>\n\n\n\n <\/p>\n\n\n\n The existing system landscape is often only inadequately examined.<\/strong> should already be addressed during the tender process. Many tenders focus exclusively on implementation. A good tender considers the entire lifecycle of a solution.<\/p>\n\n\n\n <\/p>\n\n\n\n Those who evaluate solely based on price often do not receive the most cost-effective solution. <\/p>\n\n\n\n Tenders are not just procurement projects\u2014they are transformation projects. Many organizations conduct IT tenders only once every few years, meaning they often lack experience with current methods, technologies, market developments, and the evaluation of complex solution concepts.Before discussing new systems, the following must first be understood:<\/h5>\n\n\n\n
\n
Mistake 2: The desired benefits were not defined<\/strong><\/h2>\n\n\n\n
What goals should be achieved?<\/h5>\n\n\n\n
\n
A tender with 500 requirements is of little use if no one can articulate the concrete benefits the solution is expected to deliver.<\/p>\n\n\n\nMistake 3: Requirements are collected instead of analyzed<\/strong>
<\/h2>\n\n\n\nYet often, the following questions are not asked:<\/h5>\n\n\n\n
\n
Mistake 4: Business departments and IT work in isolation<\/strong>
<\/h2>\n\n\n\n
Successful tenders emerge from the collaborative work of business units, IT, data protection, information security, and other stakeholders.<\/p>\n\n\n\nMistake 5: Processes are not considered<\/strong>
<\/h2>\n\n\n\n
If inefficient processes are transferred unchanged into a new system, no real added value is created.<\/p>\n\n\n\nBefore issuing a tender, the following should always be examined:<\/h5>\n\n\n\n
\n
Mistake 6: Non-functional requirements are missing<\/strong><\/h2>\n\n\n\n
Key quality attributes to consider include:<\/h5>\n\n\n\n
\n
Mistake 7: The existing system landscape and future viability are insufficiently considered<\/strong>
The existing system landscape is often only inadequately examined.<\/strong><\/h2>\n\n\n\n
New solutions rarely operate in isolation. They must integrate with existing application landscapes.
Those who fail to understand existing systems, interfaces, and data flows significantly underestimate effort, risks, and costs.<\/p>\n\n\n\n
Future viability is not considered.<\/strong>
Another aspect is the rapid evolution of technology. Topics such as:<\/p>\n\n\n\n\n
<\/p>\n\n\n\nMistake 8: Operations are forgotten<\/strong><\/h2>\n\n\n\n
Yet the real costs often arise afterward:<\/p>\n\n\n\n\n
<\/p>\n\n\n\nMistake 9: Evaluation criteria do not align with the project<\/strong>
<\/h2>\n\n\n\n
Evaluation criteria should always support project goals and consider professional, technical, and organizational aspects.
The situation becomes particularly critical when criteria are defined but have little actual impact on scoring.<\/p>\n\n\n\nMistake 10: Independent support is lacking<\/strong>
<\/h2>\n\n\n\n
Independent support helps to:<\/p>\n\n\n\n