How Much Documentation Do You Really Need?
When too much or too little becomes your Achilles heel
Documentation is often bundled into a statement of work (SoW) and becomes a necessary document that sits in with a contract. They are often produced by analysts, who consult with stakeholders and then often define with meticulous detail what the requirements, exact tasks, needs, and everything else in between are.
At first, it seems logical to have such a document, mostly for verification and legal purposes. However, on a software development level, this methodology of documenting everything in such granular detail embeds the monolithic method of implementing a waterfall workflow.
This creates a rigid approach to software development that doesn’t give much room to respond to change or to enable developers to rapidly prototype a solution.
Requirements are often also one-sided and unvalidated, leaving the business more vulnerable to bigger failures — not because the developers haven’t delivered, but rather because the intended audience didn’t respond as expected to the software.
The Diminishing Returns of Over-Documentation
The more documentation you begin with, the more diminishing returns you are receiving in actual value…
