“Risk” is the (future) potential of negative (unfavorable) impact upon something of value. In project management terms, it’s the likelihood that Some Bad Event will befall the project. It might be the loss of a key team member, a sudden shift in management direction, or bad weather than hampers the ability of team members to get their assignments completed.
Managing risk is all about “what if”. So, if your lead developer is pregnant or has a pregnant spouse, it’s likely s/he will request family leave, which the project manager will offer as soon as the Delicate Condition is announced (well, a good PjM will offer it). You manage that risk of not knowing how long the team will be short a member by cross-training and mentoring understudies for key team members. It’s smart for the project and smart for people management.
Risk can be classified into two categories. ”Special cause” variation is human error, unplanned events, or an unexpected combination of steps making up the process. It’s a change in output caused by a specific factor such as environmental conditions or process input parameters. Bottom line: it’s preventable.
“Common cause” variation is chance fluctuations, not assignable to a specific cause, and a normal part of the system. It’s natural pattern behavior that’s in ”statistical control”, meaning that the variations occur randomly. In all parts of the country, you can, over the course of a year, plan on having one or two unproductive days as a result of severe weather. So, plan on a lost day every three months; weather is a common cause. Bottom line: expect it and plan for it, or change the system to eliminate it.
Risk identification and control is a key responsibility of the PjM. But you can start managing risk by avoiding it in the first place. Here are a few ideas for avoiding risk:
-
Identify the minimum acceptable deliverable and make that your target.
-
Negotiate and clearly document all interface deliverables expected from other projects.
-
Avoid untried, unfamiliar, or ‘‘bleeding edge’’ technology.
-
Plan to design using standard, modular, or better-understood methods: look for ways to achieve project specifications using older, well-established technologies.
-
Buy instead of build.
-
Avoid ‘‘not invented here’’ thinking; leverage work done by others.
-
Reduce the number of critical paths.
-
Modify the work to have fewer activity dependencies.
-
Schedule the highest uncertainty activities as early as possible.
-
Avoid having the same staff members work on two successive or concurrent critical (or near-critical) activities.
-
Decompose long or complicated tasks.
-
Reschedule work to provide greater flexibility.
-
Obtain personnel names for all required project roles.
-
Get explicit availability commitments from all project staff (and from their managers).
-
Work to limit commitments by project staff to other projects, maintenance and support work, and other time conflicts (one project at a time).
-
Explicitly document all team (external) commitments that remain on team members.
-
Modify plans to reduce the load on fully loaded or overcommitted resources.
-
Use the best people available for the most critical activities.
-
Educate team members to use more efficient or faster methods, and do it early in the project.
-
Use mentoring to build teamwork and establish redundancy for critical skills.
-
At the start of the project, upgrade or replace older equipment.
-
Locate and gain access to experts to cover all skill areas not available on the project team.
-
Minimize dependence on a single individual or other resource for project work.
-
When you use outside services, use the same suppliers that you (or others that you trust) have used successfully in the past.
-
Establish contract terms with all suppliers that are consistent with project objectives.
Avoidance tactics are not limited to these ideas. Anything that you can realistically do to eliminate the root cause of a risk has potential for risk avoidance. Don’t build your datacenter on the cheap land straddling the San Andreas fault or offering a close-up view of Mt. Rainier.
But risk exists-you can’t avoid it completely. Stepping out of the shower is risky but we do it anyway. In project management, we figure out ways to mitigate (reduce the impact of) a single risk item and combinations of risk items.
What can you do to mitigate risk?
-
Maintain good communication with all stakeholders
-
Have strong sponsorship
-
Have continuing user involvement
-
Clear decision priorities
For scope and technical risks, consider these approaches:
-
Rely on change control to protect the original scope. Change control is the PjM’s friend: use it!
-
Explicitly specify project scope and all intermediate deliverables in measurable, unambiguous terms, including what is not in the deliverable.
-
Eliminate ‘‘less-essential’’ items early—make them part of “essential” scope or defer them.
-
Gain acceptance for, and use, a clear and consistent specification change management process.
-
Build models and prototypes to validate ideas and designs.
-
Test early and often with users.
-
Deal with scope risks promptly.
-
Obtain funding for any required outside services.
-
Minimize external dependency risks.
-
Consider the impact of external and environmental problems.
-
Keep all plans and documents current.
-
If another group’s output is your input, confirm they’ll deliver the right results on time: “inspect what you expect”.
Software projects wouldn’t be challenging if we didn’t face the risk of delivering horribly late. But here are a few things that may help manage schedule risk::
-
Use ‘‘expected’’ estimates when worst cases are significant.
-
Schedule highest-priority work early.
-
Schedule proactive notifications.
-
Explore how you could use older, known methods instead of new and unproven technology.
-
Be conservative in cost estimates for training and new hardware.
-
Break projects with large staffs into parallel efforts.
-
Break long and/or complex projects into a series of smaller projects.
-
Schedule phase-ending project reviews and rebaseline the project if necessary.
-
Track progress with rigor and discipline.
Projects are about people. The PjM is an equal on the team with a unique set of activities, including protecting the team members from inappropriate influences and distractions. How can you protect your human resources?
-
Use the project kickoff meeting to define a “project culture” (a set of behaviors) that respects and protects all team members.
-
Avoid planned overtime.
-
Build teamwork and trust on the project team.
-
Use ‘‘expected’’ cost estimates where worst-case activity costs are high.
-
Obtain firm commitment for funding and staff.
-
Keep customers involved.
-
Anticipate staffing gaps.
-
Minimize safety and health issues (make sure everybody gets enough sleep, etc.).
-
Encourage team members to plan for their own risks.
-
Assign risky work to successful problem solvers.
-
Rigorously manage outsourcing.
-
Detect and address flaws in the project objective promptly.
-
Rigorously track project resource use.
As you’re working through the tasks making up a project (the “work breakdown structure”), don’t forget to categorize the risk, estimate its probability, estimate its effect on the project should it materialize, and suggest a strategy for managing it.
Review your risk log at least once a month. The project environment changes over time and you want to make sure your risk assessment looks at current risks, not the risks identified (months ago) when the project charter and plan were developed. You’ll want to examine your top five risks in each of two categories: probability and financial impact. If you have 10% turnover in the department and you have a 10-person team, it’s reasonable to plan for the loss of a team member (see how that cross-training and mentoring is useful?). If failure to deliver on time will result in the loss of a major customer, you have the potential of a big financial impact, so plan and act accordingly.
When you’re preparing a project proposal, don’t ignore risk. It’s much better to identify the risk and your solution for managing it than to ignore risk in the hope that it will go away…because it won’t. If you’re a big-brain programmer, you’ll understand why I think risk management is conceptually similar to using assertions.
Risk management is one of the stimulating and creative components of project management. The great thing about dealing with risk in the project management context is that projects (like motorcycles, helicopters, and girl friends) are inherently unstable and require constant management. Get risk under control and you’ll find your projects are much easier to handle…than a motorcycle, helicopter, or girl friend.
