The fastest way to buy the wrong enterprise system is to describe the one you already have. It happens almost every time. A requirements document gets built by asking “what does our current system do?” — and the answer becomes the specification. You go to market, six software companies respond, and you sign for a platform that reproduces the constraints you were trying to escape, at a premium.
Starting at zero is the opposite move. It means setting the incumbent system aside entirely and deriving requirements from the work: what your finance team actually has to accomplish, what a resident actually needs from a permit portal, what a grant actually requires you to report. The current software is evidence of one way those needs were once met. It is not the definition of the need.
This is the idea underneath everything Avèro does, and it is why the book that documents our methodology is called Start at Zero.
Why requirements drift toward the incumbent
Nobody sets out to specify the old system. It happens because the old system is the most available reference in the room. The people who know the requirements best are the people who run the current process, and they describe that process in the vocabulary of the software they use every day. Fields, screens, reports, workflows — the requirements come out shaped like the incumbent because that is the shape everyone can see.
The cost of that drift is enormous and invisible. You never find out what you could have bought, because you never asked the question in terms a different architecture could answer. Zero-based requirements force the question into the open: not “which system replicates our chart of accounts,” but “what does our chart of accounts need to do, and why is it structured the way it is?”
Often the honest answer is that a constraint everyone treated as a requirement was really just a limitation of the last system, carried forward out of habit.
What starting at zero actually involves
It is not a blank sheet of paper and good intentions. Zero-based ERP planning is a discipline with a sequence:
- Document the work, not the software. Map what each function has to
accomplish and what it is accountable for. The current system appears only as evidence of how a need is met today, never as the requirement.
- Separate genuine requirements from inherited habits. For every “the
system must” statement, ask whether it describes a real obligation or a workaround that calcified into a rule.
- Write requirements a different architecture could satisfy. If a
requirement can only be met by the product you already own, it is not a requirement — it is a description.
- Test the market against that, not against your incumbent. Now the
responses you get are answers to your actual needs, and they are comparable to each other on the same basis.
Done this way, the requirements document becomes reusable. It survives whichever decision you make, because it describes the organization rather than a product.
The conflict of interest that makes zero hard
There is a reason most agencies never start at zero, and it is not incompetence. It is that almost everyone offering to help has a financial interest in the answer.
An advisor who also implements systems earns more when you replace. A reseller earns the license. A systems integrator earns the integration. Even the honest ones cannot fully remove the thumb on the scale, because their revenue and your decision are structurally linked. Avèro was built to break that link: no resale, no implementation revenue, no software to sell you. That is the only arrangement under which “you should keep what you have and tune it” is an answer we can afford to give.
Zero-based thinking and structural independence are the same idea from two angles. You cannot get an unbiased requirement from someone who profits from a particular answer, and you cannot start at zero if the incumbent’s replacement is already someone’s payday.
Where to go from here
Start at Zero is the long version — the playbook our engagements are built on, written for the public-sector leaders who have to make these decisions and defend them afterward. Around it we publish the Untangled newsletter for government technology leaders and the Start at Zero with AV YouTube channel, where the same ideas get worked out in the open.
If you are about to write requirements for a new system, the most valuable thing you can do first is forget the one you have. Schedule a briefing and we will help you start at zero.