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—not 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.

Mistake 1: The current situation was never truly analyzed

Often, only symptoms or assumed solutions are discussed, such as: “We need a modern solution”, “Users are dissatisfied” or “We should use AI.” These statements rarely describe the actual problem to be solved.

Before discussing new systems, the following must first be understood:

Which processes are affected?
Which stakeholders are involved?
Where are time losses occurring today?
What media discontinuities exist?
What data issues persist?

An analysis often reveals that the real problems are organizational in nature or can be resolved through adjustments to existing systems.

Mistake 2: The desired benefits were not defined

Many tenders detail what a system should be able to do and which functions are desired. Rarely, however, do they explain why the system is being procured in the first place—and this is precisely the critical question.

What goals should be achieved?

Faster processing times?
Fewer manual tasks?
Higher data quality?
Improved customer satisfaction?
Compliance with regulatory requirements?
Greater information security?

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.
A tender with 500 requirements is of little use if no one can articulate the concrete benefits the solution is expected to deliver.

Mistake 3: Requirements are collected instead of analyzed

Many organizations hold workshops to gather requirements, resulting in long wish lists.

Yet often, the following questions are not asked:

Why is this function needed?
What problem does this function solve?
What added value does it create?

Requirements engineering is not about collecting requirements—it’s about identifying, understanding, questioning, elaborating, and prioritizing the right requirements. Investing this time ensures not just a tender process, but the procurement of a sustainable, maintainable, and beneficial system.

Mistake 4: Business departments and IT work in isolation

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.
Successful tenders emerge from the collaborative work of business units, IT, data protection, information security, and other stakeholders.

Mistake 5: Processes are not considered

A new system often merely digitizes existing weaknesses.
If inefficient processes are transferred unchanged into a new system, no real added value is created.

Before issuing a tender, the following should always be examined:

Which processes should be supported?
Which process steps can be eliminated?
Where do automation potentials exist?

Mistake 6: Non-functional requirements are missing

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.

Key quality attributes to consider include:

Performance
Availability
Scalability
IT security
Data protection
Reliability
Maintainability

These aspects can determine the success or failure of a project, particularly in critical infrastructures and public institutions.

Mistake 7: The existing system landscape and future viability are insufficiently considered
The existing system landscape is often only inadequately examined.

The existing system landscape is often only inadequately examined.

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.

Future viability is not considered.
Another aspect is the rapid evolution of technology. Topics such as:

Artificial intelligence
Automation
Cloud strategies
API capabilities
Data integration
Future enterprise architecture

should already be addressed during the tender process.

Mistake 8: Operations are forgotten

Many tenders focus exclusively on implementation.
Yet the real costs often arise afterward:

Maintenance
Support
Operations
Further development
Training

A good tender considers the entire lifecycle of a solution.

Mistake 9: Evaluation criteria do not align with the project

Those who evaluate solely based on price often do not receive the most cost-effective solution.
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.

Mistake 10: Independent support is lacking

Tenders are not just procurement projects—they 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.
Independent support helps to:

Structure requirements,
Identify risks early,
Engage stakeholders,
Assess bidder concepts and potential solutions for feasibility, and
Prepare sound decisions.

Conclusion

Most failed IT projects do not fail due to technology. They fail because of unclear goals, insufficient analysis, and inadequate requirements.
Investing time in analysis before issuing a tender saves many times the cost, delays, and project risks later on.
The best tender is not the one with the most requirements, but the one with the clearest understanding of the actual problem and the intended benefits.
Successful tenders do not begin with a requirements specification, but with an understanding of the initial situation, goals, and expected benefits.