3

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?

3

Documentation is a Communication Aid

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:

  • Deviations that result in schedule risk probably belong on the Project Risk Log.
  • Deviations that impact budget probably belong in an information radiator such as a bi-weekly budget report.
  • Deviations that affect scope or quality should be communicated with stakeholders in whatever report or communications format project status is usually used to share with that group.
  • Deviations that impact the project team, or (perhaps more importantly) downstream project teams or matrixed resources, should be shared through updates to start/stop or lead-time estimates, as these deviations may have a direct impact on their schedules, budgets, and estimates.
  • Deviations that can be mitigated should be communicated through updates to the project plan.
  • Deviations that can't be mitigated should be communicated to upper management for strategic decision-making.

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.

  • Appreciate the bullet point instructions. That's the info I was looking for. – jpco Feb 2 '15 at 15:38
4

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.

0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.