This article is for boards and for those who sign off on a system purchase: the secretary and treasurer in a public authority, the CEO of a municipal company, the CFO, the business owner. It is also for the IT manager preparing a tender or request for quotation who wants to know what the board should pay attention to before approving the documents.
Why this problem arises
Most problems with vendors originate on the buyer's side, long before the contract is signed. This is not down to ill will: preparing a procurement is work for which organisations rarely have the time or the competence, and vendors are only too happy to make it easier. They bring ready-made specifications, demonstrations and quotes. As a result, the buyer ends up purchasing what the vendor is good at selling, rather than what it actually needs. Another part of the problem is that purchasing decisions very often stay in the hands of the business departments, with IT acting 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 authorities and in companies. What differs is the procurement procedure, not the underlying mechanism.
Twelve mistakes
- Requirements copied from one vendor's offer or presentation. This limits competition and locks you into dependency before you have even chosen a contractor. I covered this in more detail in the article on vendor lock-in in the tender specification (SWZ).
- No business owner. The project formally has a manager, but no one with a mandate from the board decides how the processes should work.
- No acceptance criteria or test scenarios before signing. Acceptance testing turns into a dispute over interpretation, rather than a check on whether the project's deliverable meets the success criteria for the implementation.
- Not knowing what you already have. You buy a new system without knowing which existing contracts, licences and functions overlap with it.
- Overlooked integrations. What data the new system needs to exchange, with which other systems, in which direction, which system is the master, what data and in which formats, and whether the vendor is aware of this and guarantees it will deliver the necessary mechanisms and take responsibility for their ongoing operation.
- Data migration described in a single sentence. Without settling which data, from what period, who cleans it and who checks the result.
- Requirements written as a list of features instead of a description of processes. Every vendor will answer "yes" when asked about a feature. Ask how it handles your specific case, and the answers start to diverge.
- Comparing the starting price instead of the total cost. The licence is just the beginning. Maintenance, changes and integrations are paid for over years. I write about this mechanism in the article on total cost of ownership (TCO) and boiling the frog.
- No rules for changing scope. It is unclear who raises a change, who prices it and who approves it.
- A contract with no exit terms. No provisions on data export, documentation or handing maintenance over to another provider. No tools for mitigating risk.
- A maintenance agreement adopted from the vendor's template. Service levels, response times and the cost of changes are then set by one side alone.
- Decisions left until the last moment before a deadline. When a statutory deadline or the end of support for the old system is close, there is no longer room for comparing offers or negotiating.
Mistakes one to three are root causes. If you eliminate them, most of the others become visible at the preparation stage, rather than during delivery.
For a council, supervisory board or head office, what matters most is whether the decision to choose a vendor has documented justification. The twelve points above also serve as a list of questions worth asking before the board approves the procurement documents.
A practical example
One of our clients was told by their ERP vendor that exchanging counterparty data with the correspondence management system being implemented (EZD/e-Delivery) would be no problem at all. A correspondence management system usually stores data on all counterparties, not just those for whom economic events occur - that is, those who become customers or suppliers. The data lifecycle of a new counterparty typically starts much earlier than any economic event.
During implementation it turned out that the cost of adapting the ERP vendor's API for two-way counterparty data exchange amounted to 80% of the entire value of the project to implement cost-document workflow integrated with the KSeF, OCR, VIES, GUS (Polish Central Statistical Office) and, finally, export of data to the finance and accounting system. This single integration, not discussed thoroughly with the vendor from the outset, practically doubled the cost of the project.
When you need an independent advisor
If you have an experienced team that has already prepared several similar procurements, this list will serve as a check. An independent view makes sense when the procurement is large relative to the organisation's scale, when the requirements were drawn up in contact with a single vendor, when the decision will need to be defended before an audit, a council or head office, or when no one on the buyer's side knows these systems from the inside.
I can review the documents before the tender is published or the request for quotation is sent, prepare the requirements and test scenarios, or assess bids that have already been submitted. In public authorities the starting point looks a little different; I describe it on the page for local government units (JST).