Documentation and Over-Documentation

In exploring project documentation techniques online, I found an excerpt from a software quality management book that illustrates the need for a balance between sufficient documentation and “over-documentation.” Some of the information was redundant to what we have learned in class; of course, certain documents are mandatory (project charter), and project scope largely dictates the extent of documentation required—wide-scoped projects need more and narrow-scoped projects need less. At the least, the author describes, documentation must perform the core functions of explaining “what to do (concept and requirements), how to do it (plan and design), how to show that it was done (test), and how to use the system (user).”  However, too much documentation creates issues. The author warns that along with inducing an immediate “I’m not going to read all that!” response, over-documentation can result in inconsistencies that create confusion and damage progress.

The process for developing our ideas into interactive prototypes over the course of this semester is not as structured as it was in MIS3535. In that class, specific documents were due each week, and revisions of key documents were also expected regularly. In MIS4596, we are given more general instructions; many of the project tasks we perform—such as deciding the extent of documentation—are self-directed. Given that we have control of our projects’ direction, I expect teams’ documentation to range from minimal to very thorough.

With the hazards of over-documentation in mind, how will your team ensure that your project documentation is both manageable and thorough? How will you check for inconsistencies between documents? Lastly, which documents used in our business analysis and project management classes will you employ this semester, and which will you disregard?