12 mistakes buying organisations make before selecting an IT system supplier

This article is for boards and for the people who sign off on a system purchase: the secretary and treasurer in a local government office, the CEO of a municipal company, the CFO, the business owner. It's also for the IT manager preparing a tender or a request for quotation who wants to know what the board should look out for before approving the documents.

Why this problem arises

Most problems with suppliers originate on the buying organisation's side, long before the contract is signed. Not out of ill will: preparing a procurement is work for which the organisation rarely has the time or the competence, and suppliers are happy to make it easier. They bring ready-made descriptions, demonstrations and quotations. As a result, the buying organisation ends up purchasing what the supplier knows how to sell, not what it actually needs. Another part of the problem is that purchasing decisions very often remain in the hands of the business units concerned, while IT acts merely as a security gatekeeper. The absence of standards and a long-term IT strategy means the organisation makes purchases that do not always fit within the framework whose job is to mitigate risk.

I see the same mistakes in public offices and in companies. What differs is the procurement procedure, not the underlying mechanism.

Twelve mistakes

1. Requirements drafted on the basis of one supplier's offer or presentation. This limits competition and locks in dependency before you've even chosen a contractor. I cover this in more detail in the piece on vendor lock-in in the tender specification (SWZ).
2. No business owner. The project formally has a manager, but nobody with a mandate from the board decides how the processes should work.
3. No acceptance criteria or test scenarios agreed before signing. Acceptance becomes a dispute over interpretation rather than a check of whether the project's output meets the success criteria for the implementation.
4. Not knowing what you already have. You buy a new system without knowing which existing contracts, licences and functions overlap with it.
5. Overlooked integrations. What should the new system exchange data with, in which directions, which systems hold the authoritative data, what data, via which formats, and does the supplier know this and guarantee it will deliver the necessary mechanisms and take responsibility for keeping them running?
6. Data migration described in a single sentence. With no agreement on which data, from which period, who cleans it and who checks the result.
7. Requirements written as a list of features instead of a description of processes. Every supplier will answer "yes" to a question about a feature. Ask how they would handle your specific case, and the answers start to differ.
8. Comparing the starting price instead of the total cost. A licence is just the beginning. Maintenance, changes and integrations are paid for over years. I describe this mechanism in the piece on total cost of ownership (TCO) and boiling the frog.
9. No rules for changing scope. Nobody knows who raises a change, who prices it and who approves it.
10. A contract with no exit terms. No provisions on data export, documentation or handing maintenance over to another provider. No risk-mitigation tools.
11. A maintenance agreement accepted from the supplier's template. Service levels, response times and the cost of changes are then set by one side only.
12. The decision left until the last moment before a deadline. Once a statutory deadline or the end of support for the old system is close, there's no room left to compare offers or negotiate.

Mistakes one to three are root causes. Remove them, and most of the others become visible at the preparation stage rather than during delivery.

An example from practice

One of our clients was told by their ERP supplier that exchanging counterparty data with the correspondence management system being implemented (EZD/e-Doręczenia - Poland's electronic document and case management system and e-Delivery platform) would be no problem at all. A correspondence management system typically stores data on all counterparties, not just those who eventually become involved in economic transactions - that is, who become customers or suppliers. The life cycle of a new counterparty's data simply tends to start well before any economic transaction takes place.

During implementation, it turned out that adapting the API on the ERP supplier's side for two-way exchange of counterparty data would cost 80% of the entire value of the project to implement a cost-document workflow integrated with KSeF (Poland's National e-Invoicing System), OCR, VIES, GUS and, finally, export to the finance and accounting system. This single integration, not discussed in detail with the supplier at the outset, effectively doubled the cost of the project.

When you need an independent adviser

If you have an experienced team that has already prepared several similar procurements, this list will serve as a check. An independent perspective makes sense when the procurement is large relative to the organisation's scale, when the requirements were shaped in contact with a single supplier, when the decision will need to be defended before an audit, a council or head office, or when nobody on the buying side knows these systems from the inside.

I can review the documents before a tender is published or an enquiry sent out, prepare requirements and test scenarios, or assess offers that have already been submitted. In public offices the starting point looks a little different; I describe it on the page for local government units (JST).