A new ERP solution, a cloud migration, a network expansion: as soon as a public institution or an affiliated organization sets out to procure an IT project, success is rarely decided by the question "which software fits us?" — it's decided much earlier, by the question "do we actually understand our own system landscape well enough to put it out to tender properly?". Anyone who skips this homework ends up with offers that look great on paper and don't fit in practice.
The as-is assessment determines the quality of the offers
Every evaluation is only as good as the requirements it's based on. That sounds obvious, but it's routinely underestimated in practice: Which systems are currently in use? What interfaces exist to upstream and downstream applications? Where does the data live? What dependencies exist to legacy systems? What load profiles and scalability requirements does a new solution need to cover? If this technical as-is situation is captured incompletely, vendors build their offers on assumptions — and those assumptions are exactly why projects later go off the rails.
Requirements you can actually verify
A technical requirements specification is only useful if every requirement can later be checked. Instead of "the system must be performant," you need concrete, measurable criteria:
Only if requirements are formulated this concretely can offers later be compared objectively.
Where proof of concepts and vendor assessments make the difference
A purely paper-based evaluation rarely shows whether a solution actually delivers on its promises. That's why it pays to build technical testing actively into the evaluation process:
These elements deliver hard evidence where a pure criteria checklist only delivers claims.
Clarify architecture and operations questions early
Many problems in IT projects arise because central technical questions are only raised after the award: What does the data migration concept look like? Who operates the solution — cloud, on-premise, or hybrid? What security architecture underlies it? How is the transition from the legacy system handled? If these questions are already addressed during the evaluation, vendors can be judged right away on how well thought-out their technical concept really is — instead of facing unpleasant surprises later in operation.
The difference between a clean and a good award decision
A clean award decision is one that's formally correct. A good award decision is one that also finds the technically best solution for your own system landscape. That's the real challenge: building an evaluation that enables well-founded, technically robust decisions — not one that just ticks off a criteria list.
Planning an IT project that needs to go out to public tender, or would you like to talk it through?
We're happy to help you map your system landscape properly, formulate technically robust requirements, and find the right solution for your project. Get in touch anytime. Fast. Agile. Reliable.
