This question is based on David Espina's answer: https://pm.stackexchange.com/a/14017
Specifically, the following portion:
On the other hand, deviation from a planned approach is sometimes required. When you are consciously deviating from the plan, you should document that such that you can explain your decision when that time comes.
Where is information such as deviations to be documented?
Where is information such as deviations to be documented?
There isn't a single answer for this, as it depends on what you're trying to document and the purpose of the communication. Deviations from a plan might even be documented in multiple places, and sometimes in different ways, depending on what you're trying to communicate and to whom. For example:
The general theme of most of these items is effective communication. If there's a problem, be transparent about the nature and (if possible) the root cause of the problem so that the organization can take the appropriate steps to fix things, or at the very least not be surprised by sub-optimal outcomes if they are unavoidable. Burying the critical input needed for strategic decision-making is a sure path to project failure, so don't do that!
Note that some deviations are also simply an expected outcome of normal variance. If that's the case, these routine but acceptable deviations should be reported as such through the project's normal communication channels. A good project manager never covers up deviations from plan, but also doesn't cry wolf when such deviations are within acceptable tolerances and when the project plan has been properly built with sufficient slack to absorb expected variation.
Funny to read my name in the question. The documentation of this type of purposeful deviation could happen anywhere you normally document. For example, if an issue was identified and documented in the issue log, the recovery plan--a purposeful deviation from method or process--might be documented in the same log. It could be documented in a weekly report if you have such a report. It could be documented in a variance analysis as part of a plan or even an explanation of the variance. It could be a simple e-mail to your project boss or customer or another stakeholder explaining what you chose to do and why.
I think where the documentation needs to occur becomes evident simply how the issue was developed and how the decision to deviate came about. But however this occurs, I don't think it needs to be over analyzed. The objective is to have a formal description of the events that will survive in your project artifacts.
In the project plan and requirement document with a date and description of the changes, moreover in the delivery document (or change log) just to make sure that the receiving party is also informed about the changes.
