PROJECT RISK MANAGEMENT
This article is a practical guide with templates to stimulate thought and improve the practice around incorporating risk management (RM) into a project. A simple method of RM will reduce the concern of administrative overhead in its use, removing a barrier to applying an RM perspective to project management.
A primary contributing factor of project troubles is a non-explicit risk management approach. By naming and clarifying the risks, the project team will increase their focus on them, which will help the team steer clear of the dangers ahead. The approach outlined below is meant to be low overhead, to encourage usage, and to bring out the value in tracking risk.
Risk has two components:
Þ the probability of failing to achieve a particular outcome
Þ the consequences of failing to achieve that outcome.
Risk management is a methodological approach to controlling risk.
Goal: Discover early, track closely
There are four processes in a Risk Management plan:
I Identification A . Discovery B . Definition II Quantification A . Likelihood B . Impact III Response A . Analysis B . Evaluation C . Action
1) Mitigation
2) Contingency
3) Acceptance
IV Controlling A . Tracking
I Identification
Risks either:
· correspond to tasks on the WBS or,
· are implied by WBS tasks, or
· are environmental
Correspond to tasks on the WBS:
ð Critical Path tasks need to be considered first, since their delay will delay the entire project.
· Interview the assigned resources to validate the estimates.
· Also, probe vendors; ask for contacts at other sites to help clarify questions or concerns.
ð Other tasks need to be tracked based on the project team's "level of comfort": if the team can't articulate well what the task really comprises; if the task is new to them; or if they just don't "feel good" about it, then it needs to be tracked closely.
· Consult with subject matter experts as appropriate.
· If it looks “scary”:
ü communicate to stakeholders early
ü do more research, and
ü work hard on the mitigation/contingency plans
ð Long tasks (e.g., greater than three weeks in a 9 month project), particularly those that feed into the Critical Path, need to be followed closely or broken down.
Implied by tasks on the WBS:
ð Are you using new technology with which we don’t have strong internal expertise?
ð What kind of infrastructure impact will there be: network throughput, PC availability, construction delays for remodeling, or building in sensitive clinical areas?
ð How much control do you have over matrixed staff: commitments to other projects can take away promised resources, or a new, higher priority project can pop up that will pull your resources away. Will the LAN team still be there when you need them?
ð Do you depend on deliverables from other teams to achieve your goals? How much visibility do you have into their status?
ð EVERY software implementation should include "possible undiscovered fatal SW bug" in the matrix risk:
· Put mitigation and contingency into place from the start.
ü This should begin with a contractual obligation to make a hot fix ASAP.
ü Strongest possible financial penalties if doesn't perform as promised.
Environmental are issues that arise outside control of the project manager and the project. They can include
ð Internal politics - we all know what can happen in an organization and what the ripple effects may be. The best guard against this is to communicate personally, and often with your executive sponsor.
ð Layoffs will always come at the worst time.
ð HIPPA and other mandated compliance factors may come into play.
Some Typical Risk Areas & Events:
¨ Scope creep
¨ Poor task duration estimates
¨ Subcontractor delay/default (e.g., construction, etc.)
¨ Vendor delay/default (e.g., unstable code; contractual/legal)
¨ Resource limitations or conflicts
¨ Technical:
ü Interfaces
ü Technical failures
ü New technology
ü Demanding performance requirements (99.99% uptime)
¨ Coordination difficulties
¨ Lack of authority (in certain areas)
¨ New tasks (unquantified skills, etc.)
¨ Complex tasks
¨ Funding
¨ Internal politics
¨ Information bottlenecks
Key Questions to keep on asking:
What are we uncomfortable with?
What are we uncertain about?
Prepare your stakeholders:
For a large project, two things that you can guarantee them with absolute surety are:
There will be a significant disaster in the course of the project.
A key resource will leave the project.
The catch is, at the outset, we just don't know what will go wrong, or who will leave. Make sure that the budget has time and management reserves built in to absorb these hits.
Þ Report on risks regularly to all stakeholders: Even a regular email of the tracking matrix below will help keep concerns visible.
Þ Bring the document to all status and team meetings. Spend a few minutes at the outset reviewing the risks.
Plan for risk planning:
Early risk planning should be explicit in all project management documents:
¨ Include purpose and objective of risk tracking as background when needed
¨ Assign responsibilities for specific areas
¨ Identify additional technical expertise needed
¨ Highlight areas to consider
¨ State procedures for consideration of risk-handling options
¨ Describe the risk reporting
¨ Identify documentation needs