When designing systems or preparing presenations its important to understand your documents.
Vague documents occur when trying to put too much information into a single document that does not directly aid the purpose of the document. That information may confuse the reader as the document drifts from one topic to another. Such information should be put in a different document. When presenting some point of view and producing some presentation, its important to back your results with strong sources.
Its better to build up many sets of correct and consise documents that are easy to update when information changes or becomes available. Furthermore, different types of documents may depend on (and source) information from numerous documents without confusing the scope and purpose of the document.
Consider what happens when putting together an technical integration manual. The manual should source information from various internal technical notes and apis. Any new information should be updated and corrected in the technical notes, not the technical manual. It is typical to have technical writer compose the manual from specifications and notes. The techical writer is not typically the authority to create the source material. When the manual contains original material, the documentation style is either (a) the manual is the specification, or (b) the manual is dependant on source material, source material should be updated or source material is unique to the manual, or (c) there is no source material.
A problem with many source documents is being able to find the documents and having someone review changes to the document. Google Desktop Search is an example of an effective way to find what you're looking for while MS Sharepoint Portal Server provides both reasonable search functionallity and document process control (i forget the correct terminology). Unfortunately MS SPS is cost prohibitive for smaller businesses.
Either way, documentation is costly to create so its important to be effective in its creation and use.
Reliable + Cheap = Lots of preparation and documentation (not fast)
Cheap + Fast = Little preparation and documentation (lets go live)
Fast + Reliable = Someone else did the documentation and are charging for it.
The scope of this is again possibly too large and vague in itself. Am i trying to jot down my thoughts... or am I trying to put together a javaworld.com article.