Approval routes are described as 'per the organization's accepted procedure'
What it leads to. The contractor has no document showing who signs off on a document and in what order, what happens if an approver declines, or whether the scheme should be sequential or parallel. The system gets configured by guesswork, and at acceptance it turns out the real approval process is more complex — with conditional branches, delegation during leave, and different routes for different document types.
How to write it right. Attach the organization's document workflow regulations to the spec, or at least route diagrams for the main document types — orders, contracts, letters. Specify what happens when an approver is unavailable: automatic delegation, escalation, or parallel approval with a quorum.
No mention of what to do with years of accumulated paper archives
What it leads to. If the spec says nothing about the existing paper archive, the contractor only scopes work for new documents. A few months after launch it turns out staff still keep pulling physical files, because the only way to find them is in a cabinet, not in the system — and the EDMS ends up only partially used.
How to write it right. Specify the volume and composition of the archive to be digitized: scanning, indexing, linking to document records. If a full archive conversion isn't required, state explicitly that the scope covers only current document flow from a given date onward.
Digital signature requirements are missing or limited to the phrase 'digital signature support'
What it leads to. Digitally signing documents isn't an optional feature — it's a separate integration module tied to a certification authority, with its own logic for storing certificates, verifying authenticity, and establishing the legal validity of a signed document. If the spec doesn't state which certification authority to integrate with and which document types require a signature, this module either gets skipped entirely or built at the last minute without testing.
How to write it right. Dedicate a separate section to: which document types require a digital signature, which certification authority the system must integrate with, how certificates are stored and verified, and what happens when a signature's validity period expires.
Roles and access rights are described in generic terms like 'administrator,' 'user,' 'manager'
What it leads to. In an organization with multiple departments and documents of varying confidentiality levels, generic roles aren't enough. In practice it turns out an employee from one department can see another department's documents, or a manager can't delegate signing authority while away — and this surfaces not during testing but in live operation.
How to write it right. Build a role-and-rights matrix: who creates documents, who approves, who signs, who can view restricted documents, and how access is configured by department and confidentiality level. Attach the matrix to the spec as an appendix.
Staff training and the transition period aren't built into the project timeline
What it leads to. The project's completion date in the spec often coincides with the date the system becomes technically ready. But moving hundreds of employees from paper to a new system takes training, a period of running the old and new processes in parallel, and technical support in the first weeks. If this isn't built into the schedule, the system is handed over formally on time but adoption starts late and meets staff resistance.
How to write it right. Set aside a separate rollout phase in the project schedule: training for key users and administrators, a period of parallel operation with the paper workflow, and technical support for that period with a defined end date.
Deadline tracking for assignments is described as a feature, without concrete escalation scenarios
What it leads to. The phrase 'the system must track assignment deadlines' says nothing about what happens as a deadline approaches, what happens on overdue items, or who gets notified — the assignee, their manager, or the person who issued the assignment. Without these scenarios, deadline tracking in practice amounts to a status field in a record that nobody checks.
How to write it right. Describe the notification scenarios: how many days before the deadline to warn the assignee, what happens on overdue items, and who gets the escalation and in what form — email, in-system notification, or a report to the manager.