If you are trying to figure out how to write ERP requirements for a city, county or utility, my short answer is this: start from the outcomes your agency needs and the pain your staff lives with today, write your own rules and exceptions into the requirements in plain language, treat any requirements library as a starting point that you cut down to fit, and make sure every requirement you keep can be traced to a test, a demo step and a contract deliverable. Everything else in this post is me explaining why I hold that view and what it looks like in practice.
The copied template problem
Most requirements documents I see in the public sector were not written so much as inherited. Someone found a spreadsheet from another agency’s procurement, or a consultant brought one from their last project, and the team spent a few weeks marking each line as required or desired. The result looks thorough, and it is long, but it describes somebody else’s government. It asks whether the system can do things every modern ERP can do, it skips the things that make your agency different, and it gives evaluators very little to separate one proposer from another, because everyone answers yes.
The deeper problem is that a copied template quietly replaces a decision with a document. The real work of requirements is deciding what your agency needs the new system to change, and a long list of features lets everyone skip that conversation while feeling like they did it. In my view that is the single most common reason ERP projects go sideways long before go live.
Start from outcomes and pain, not features
The requirements that actually help you buy well come out of discovery. That means sitting with the people who close the month, run payroll, process a purchase order and answer a resident’s question, and writing down what slows them down, where they work around the current system and what they wish they could see. When I write requirements with a team, I try to phrase them as outcomes the system has to produce rather than features it has to have. Instead of asking whether the system supports encumbrances, I would rather say what our finance staff need to know about committed funds at the moment they approve a requisition, and let the proposer show me how their product gets us there.
Outcome based requirements do something a feature checklist cannot. They give proposers room to show you a better way, and they give your evaluators something real to judge. A vendor can say yes to a feature in one word. Showing how they will deliver an outcome for your staff takes evidence, and that evidence is what you want in front of your selection committee.
Put your local rules into the requirements
Every government has rules that no generic template knows about. Your charter, your state’s statutes, your collective bargaining agreements, your grant reporting obligations, your fund structure and the approval chain your council expects all shape how the system has to behave. If those rules are not written into the requirements, the vendor will discover them during implementation, and that is where change orders, delays and frustrated staff come from.
I encourage teams to write these down in plain language, with real examples. If your pay rules include a shift differential that only applies to certain units, say so and describe how it works. If a purchase over a certain threshold needs a different approval path, describe the path. This is also where bespoke software or configuration needs show up early, while you can still price them and compare them, rather than months into the project when your leverage is gone.
Use a library as a starting point and cut it to fit
I am not against requirements libraries. A good library saves time, reminds you of areas you might forget and gives your team a common vocabulary. The mistake is treating the library as the answer. When I use one, I use it as a prompt for the discovery conversations and then cut hard. If a requirement is something every credible product does, it rarely earns a place in your scoring. If nobody on your team can explain why a requirement matters to your agency, it probably does not belong. A shorter list of requirements that reflect your outcomes and your rules will serve you far better than a long list that reflects everyone’s.
Make every requirement traceable
This is the part I care about most, because it is where requirements either protect you or quietly stop mattering. Every requirement you keep should connect to a scripted demo step where the proposer shows it working, to a test your team will run before you accept the system and to a deliverable in the contract. If a requirement cannot be demonstrated, tested or written into the contract, you should ask whether it is really a requirement or just a hope.
Traceability changes the whole procurement. Your demo scripts write themselves, because they come straight from the requirements. Your evaluators score what they actually saw rather than what was promised in a response. Your contract carries the requirements forward, so the vendor’s commitments during the sale become obligations during implementation. And when someone asks a year from now why the system works the way it does, you can point to the line that asked for it.
What this looks like when it works
When we worked with Tarrant County before it went to market for a new ERP, the work started with discovery across Budget, Human Resources, Payroll, Purchasing and the Auditor’s Office rather than a survey of IT alone. Gathering requirements across the offices that actually touch the money is what surfaced the integration points and data rules that a single department would have missed, and the requirements were organized in a traceability matrix so each one could be scored against vendor responses and followed through evaluation. That is the pattern I want for every agency. Staff recognize their own work in the requirements, proposers have to show rather than tell, and the selection committee can explain its choice in terms of outcomes rather than check marks, which matters when the decision goes in front of elected officials. Across more than a hundred engagements, my view has only gotten stronger that requirements are where a good ERP decision is either set up or lost.
If you want to go deeper, I have written about the non negotiables to include in your requirements definition, about why we built Caliber instead of another spreadsheet and about why going to market is a decision, not a diagnostic.
If your agency is about to write ERP requirements, or you are looking at a requirements document that came from somewhere else and wondering whether it really describes your government, I would be glad to talk it through with you. Write to us and we will set up a conversation about where your requirements stand and what it would take to make them traceable before you go to market.
Read Chapter 1 of Start at Zero free
Planning your next move? Write to us.