Sunday, July 31, 2011

Policy, doctrine, and protocols

From time to time, we really do need to write a few things down in a plan, writing actual sentences of all things. One such plan that comes to mind is a risk management plan.

Now, I'm no fan of boilerplate, that generic stuff that planning authors seem determined to impose on the reader (although most of us just skip by), so I propose that most plans can get away with four content categories:
  1. Policy--actionable direction.  What is to be done; who (or what) is affected; why are they affected, and who has the responsibility and authority for policy implementation?
  2. Doctrine--the principles and beliefs that inform the policy and
  3. Protocols--the rules (and could also be the tools) for policy implementation
  4. Governance--authorization and escalation rules; decision rules

Let's try one on to see how it might work. How about "risk identification"; what's the plan for that one?

Risk Identification Policy:

It's the policy of Project X that every manager (project, cost account, and work package) will proactively seek risk identification on a continuous basis in order to forestall surprise and enable more predictable forecast of outcomes

Affected managers have a responsibility to ensure identified risks are submitted to the project's risk management process.

Risk Identification Doctrine:
  • Anyone can identify a risk
  • Everyone has a responsibility to seek risk identification
  • Messengers are not at risk for bearing the message
  • Every identified risk deserves consideration in the risk management process

Risk Identification Protocol:
  • Continuously assess the circumstances of identified risks to ascertain if revisions, modifications, and additions are required
  • Maintain a 360-surveillance of the external threat environment; bring new threats to the RM process
  • Maintain a current forecast by analysis, simulation, or model to reveal new risks to project completion
  • Elicit expert opinion to formulate risk descriptions 
  • Formulate a Risk Breakdown Structure to categorize risks as affecting the baseline, or not ('on or off' the baseline project plan). In other words, be a Bayseian.
  • Relate identified risks to the Risk Breakdown Structure by affected WBS, schedule, budget, performance, quality, or other risk register attributes
  • Impact decisions follow the project's funding and expenditure authority
  • Timeliness is of the essence; urgent assessments will be handled within a business day
  • Risk assignments in the Risk Breakdown Structure follow the projects WBS assignment protocols

There now! That wasn't so bad. A Risk Identification plan in less than a page. What a concept!

 Bookmark this on Delicious  
Are you on LinkedIn?    Share this article with your network by clicking on the link.