Every government ERP evaluation produces a spreadsheet. Requirements down the side, vendors across the top, scores in the middle. It works well enough during the project and then it dies — buried in a shared drive, its formulas undocumented, its reasoning locked in the head of whoever built it. Two years later, when someone asks why the county chose the platform it did, the answer is a file nobody can fully reconstruct.
That is the problem Caliber exists to solve. It is the platform we built to run government ERP decisions with discipline that outlives the engagement — discovery, vendor evaluation, scorecards, and implementation health, connected end to end and traceable back to a requirement.
The spreadsheet is not the problem. What happens to it is.
A scoring spreadsheet is a fine instrument for a single decision. The trouble is that a government ERP decision is not a single decision. It is discovery, then requirements, then evaluation, then selection, then an implementation that runs for two or three years and has to be held accountable to the promises made during selection.
On a spreadsheet, those phases are disconnected artifacts. The requirement that justified a scoring criterion lives in one document. The vendor’s demo that was supposed to prove it lives in someone’s memory. The implementation milestone that should deliver it lives in a project plan nobody cross-references back to the original requirement. The thread that connects “we needed this” to “we scored this” to “we are getting this” is exactly the thread that a public agency most needs to defend — and it is the first thing a pile of spreadsheets loses.
What Caliber holds together
Caliber keeps the whole decision on one connected spine:
- Discovery captures what the organization actually needs, in structured form
rather than meeting notes, so requirements are derived from the work rather than from the incumbent system.
- Vendor evaluation and scorecards tie every score to the requirement it
answers, so a number on a scorecard can always be traced back to why it mattered and what evidence produced it.
- Implementation health carries the same requirements forward into delivery,
so the promises made during selection remain visible while the system is being built, not just while it was being sold.
Because those stages share one model, the reasoning is durable. When a board or an auditor asks why a decision went the way it did, the answer is not a reconstruction from memory. It is a record.
Why an advisory firm builds software
We are not a software company, and Caliber is not for sale as a seat-license product to run your own procurement without us. It is the system our own advisors use to run engagements, which is exactly why it is honest about the parts vendors would rather stayed fuzzy.
Building it ourselves also let us encode a point of view most evaluation tools avoid: that scoring should be traceable, that requirements should come from needs and not from the system being replaced, and that the case for a decision should survive long after the consultant has gone home. A generic scoring tool is neutral about all of that. Caliber is not, because our engagements are not.
It is AI-native where that earns its place — structuring discovery notes, surfacing gaps between requirements and vendor responses — and deliberately conventional where trust matters, which means every automated step remains traceable to the human decision behind it.
See it
Caliber is in beta, running live government ERP engagements now. If you are facing a selection or trying to hold an in-flight implementation accountable to what was promised, take a look at Caliber or schedule a briefing and we will show you how the decision stays defensible from discovery through go-live.