Why departmental software fails, and what the specification never says
Systems are rarely abandoned because the code was wrong. They are abandoned because the workflow in the specification was not the workflow in the office.
Walk into a department that has quietly stopped using a system it paid for, and you will usually find the same story. The software does what the specification said. The specification described how the process was supposed to work. Nobody wrote down how it actually works.
The workarounds are the requirements
Every long-running manual process accumulates exceptions: the register that is filled in at the end of the week rather than at each event, the approval that is taken verbally and recorded afterwards, the form that has a box everyone leaves blank because the information arrives later. These are not sloppiness. They are the process adapting to reality.
A system built strictly to the documented process makes every one of those adaptations impossible, and the staff who depended on them go back to the register. This is why we spend time in the office before writing a schema. The question that matters is not 'what is the procedure' but 'what do you do when the procedure cannot be followed'.
Who signs off is a design constraint
Approval authority in a public sector department is rarely a straight line, and it changes with the value of the transaction, the absence of the approver, and the delegation in force that month. If the system encodes a single fixed approval chain, the first leave application by an approving officer will stall the whole department.
Data migration is where the schedule dies
- Historical records are inconsistent, and the inconsistency is not random — it changes at the points where the process or the staff changed.
- Reconciliation must be line by line and signed off by someone who knows the data, not a row count comparison.
- Budget for the cleaning as its own workstream. It is normally larger than the module that consumes the data.
- Agree in advance what happens to records that cannot be cleaned. There will be some.
Design for the person doing it forty times a day
Most departmental software is designed for the reviewer who opens it monthly, because that is who attends the requirements meetings. The clerk performing the same entry forty times a day is the user whose experience determines whether the system is adopted. Count their keystrokes. Removing three fields they never use is worth more than any feature on the roadmap.
What we insist on
A working prototype on your data shape before the full build, so that scope disagreements happen against something visible. Milestone acceptance with dated gates. Weekly written status rather than verbal reassurance. And user acceptance testing performed by the actual staff on real cases, because the fastest way to discover a wrong assumption is to watch someone try to use it.
Sources and further reading
External links, provided for verification. CyberEdge is not responsible for third-party content.