Bids become comparable only when every bidder is reading the same description and understanding it the same way. If the description leaves room, four bids come back solving four different tasks, and the cheapest of them is usually solving the narrowest one.
Writing that description is a job of its own, and it is done before the tender is published. Our deliverable is the description and the assessment. That is also why our recommendation can be read without any suspicion of a side interest.
We keep one simple rule: if we prepared the tender, we do not bid on it.
01 · Feasibility study. Before anything can be described, you need to know what is possible at all and what it costs. The study reviews the existing systems and data, sets out the solution options, and compares them on the same basis: order of magnitude of cost, risk, dependencies, schedule, and impact on what already exists.
02 · Terms of reference package. The description a bidder can price from and that you can later accept against. It covers scope, requirements, data flows and interfaces, non-functional requirements, acceptance criteria and assumptions. It also covers what is deliberately left out of the first stage, because leaving that unsaid is exactly what makes bids incomparable.
03 · Bid evaluation support. Drawing up the evaluation criteria before the tender is published, and comparing the substance of the bids once they arrive. The questions to put to a bidder, and notes on the places where a bid promises less than it appears to at first glance.
04 · Independent oversight during delivery. Once the contract is signed, the same person who wrote the description watches that what is built matches what was agreed. Review of interim deliverables, checking against the acceptance criteria, and a written opinion before every payment decision.
In that fourth step the independence is structural. Our deliverable is the description and the assessment, the build contract goes to a bidder, and so we have no interest in that procurement other than the client's own.
On the classification side, the starting point is what is actually needed: in Estonia, business-analysis advisory services are usually procured under CPV code 72221000, and system-analysis and programming work in the 72240000 group. Which code to publish a tender under, and what the substantive difference between them is, is worked through in our article on system analysis and business analysis.
The solution options, a comparison on the same basis, and a recommendation with the reasoning.
Scope, requirements, interfaces, acceptance criteria, assumptions.
Criteria, weightings, and scoring guidance for the evaluator.
Requirement through to the bidder's answer, with the gaps and the clarification questions.
A written assessment of an interim deliverable, with the findings and a recommendation.
All deliverables are handed over in editable formats, because a tender document has to be extended and reused later.
Security and compliance requirements reach a tender when they are written into the description in a checkable form. Access logic, data sensitivity and retention periods, logging, backup and recovery, dependencies on third parties. If they appear only in a general clause of the contract, the price does not include them and acceptance does not check them.
The same goes for personal data. What the system processes, on what basis and for how long, is a question for the description before it can be a question for the data protection officer.
The founding analyst has 13+ years of practice with requirements, system descriptions and data models in banking, telecom, IT consulting and logistics. That includes work on both sides of the table: writing the description, and assessing bids and delivery against it.
MentiSec's first won public procurement was business-analysis work for a public-sector institution. Qualification: BCS Foundation Certificate in Business Analysis. Working languages Estonian and English.
We write in Estonian first. The pieces below have not been translated yet and open in Estonian.
Each of these is a starting point; we settle its scope in conversation and fix it in a written offer. The steps can be taken separately, or one after another in a logical sequence.
A fixed-scope written report, produced before the decision to start a tender. It answers the question of which routes to a solution exist and which of them actually fits.
What it includes:
The description that goes into the tender, together with everything that makes bids comparable. The deliverable is written so that it can be published whichever bidders you approach.
What it includes:
The criteria before publication, and the substantive comparison once the bids arrive. Suits you when the decision has to be defended after it has been made.
What it includes:
The author of the description watches whether delivery matches what was agreed. Suits you when the contract is long and payment decisions have to be made on the basis of interim deliverables.
What it includes:
Write down what you plan to procure and by which date the decision has to be made. We talk the scope through and send a written offer. We reply within one working day, and the first discussion is free.
