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

Governance

• 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.