[I don't know the source of this useful information, my Apologies] 

Documentation should be written from the point of view of the reader, not the writer. Documentation should be organized for ease of reference, not just ease of reading.

Avoid repetition. Each kind of information should be recorded in exactly one place. This makes documentation easier to use and much easier to change as it evolves. It also avoids confusion, because information that is repeated is often repeated in a slightly different form, and now the reader must wonder: Was the difference intentional? If so, what is the meaning of the difference? What information was the author trying to convey to me that I am not picking up?

Avoid unintentional ambiguity – One of the greatest sources of ambiguity in architecture documentation are those ubiquitous box-and-line diagrams that people often draw on whiteboards or backs of napkins. While not a bad starting point, these diagrams are certainly not architectures. For one thing, the behavior of the components is not defined, and this (as we shall see) is a crucial part of the architecture. But beyond that, most of these diagrams suffer from ambiguity with respect to the component and connector types. Are the boxes supposed to be modules, objects, classes, processes, functions, procedures, processors, or something else? Do the arrows mean submodule, inheritance, synchronization, exclusion, calls, uses, data flow, processor migration, or something else?

Use a standard organization. Each document should conform to a standard, planned organization scheme, and this scheme should be made known to the reader. A standard organization offers many benefits. It helps the reader navigate the document and find specific information quickly (and so this is also related to the write-for-the-reader rule). But it also helps the writer of the document. It helps plan and organize the contents,

Record rationale. If you are documenting the results of decisions, record the decisions you eschewed and say why. Next year (or next month) when those decisions come under scrutiny or pressure to change, you will find yourself revisiting the same arguments and wondering why you didn’t take some other path. Recording rationale will save you enormous time in the long run, although it requires discipline to record in the heat of the moment.

Keep it current. Documentation that is incomplete, out of date, does not reflect truth, and does not obey its own rules for form and internal consistency will not be used. Documentation that is kept current and accurate will be used. The reason is that, backed up by high-quality documentation, questions about the software can be most easily and most efficiently answered by referring the questioner to the appropriate document.

Review documentation for fitness of purpose. 

During the planning stage we plan for resources, we schedule, we allocate time for defect management, we expect certain rework & account for that. We plan the scope, we stagger the development activities and plan for deployment. Planning for quality is mostly relegated to allocating time & Resources for product testing or verification & validation activities.

I would say, we need to ask ourselves during planning, as to “what proactive steps can we take to Improve Quality, Productivity, reduce defects and rework?” The answer to this question can come from previous executed projects,experience or any other sources

The term Execution excellence is intrinsically dependent on planning excellence.
With most failures attributed to deficiencies in planning, Continual proactive strengthening of the Planning activity will result in improved execution with Quality outcomes.

With regards to Risk Management, i recently encountered a query on what are mitigation plans and what is Contingency plan ?

Mitigation actions are taken before the Event occurs, to either reduce the impact or decrease the possibility of occurrence. Contingency is to help support what is required to be done in case the event occurs. Usually the Recommended actions from an FMEA are Mitigation actions. They help reduce the RPN number.

As a practical example, Consider driving a Car, having a speed governor, speed indicator, warning beep, following traffic rules, help Mitigate the possibility of an Accident, these set of actions help detect early, reduce the probability of Occurrence or lower the impact severity. They are mitigation actions.   Insuring the Vehicle & taking a personal Accident Insurance will not prevent Accident, they provide contingency funds to support recovery post the Accident event. (Note: Insurance is considered as Risk Transfer)
In any given scenario, both of them are important and required.

In project execution also, we take actions to mitigate identified risks, & at the same time have contingency buffers to absorb cost & schedule over runs.