You don’t have to fear risk on a project. In fact, you should embrace it! If a project doesn’t have risk, it’s probably not worth doing. A risk that transitions into an issue, on the other hand, should send any project team member into the night screaming (but not without a flashlight, tarp, phone etc.). See what we did there? Risk management allows you to take risks. Understand the risks to your project (or potential project). Have plans in place so you can respond when an issue occurs. This will allow you and your team to be empowered to make a measured decision about how to respond. Factor in any effects the issue may cause into the budget. Understanding the impacts to schedule and the scope of work will yield satisfying results. Having a plan in place increases trust between the project team and powerful stakeholders.
Risks are often perceived as negative, aka “threats”. But risks are anything that can positively or negatively impact a project. I find folks forget about managing positive risks, aka “opportunities”. Positive risks should be enhanced and shared. A classic example of a positive risk is when material goes on sale and you find a discount. Or, you can buy in bulk and share the cost with another project. It positively affects your budget. You can be an organizational hero! An example in software is when a team member is able to leverage some new technology. The team members expertise allows you to get done sooner or improve quality. Exploit the talents; share the knowledge.
If you’re not currently doing risk management on your projects, start with something easy. Create a top 10 risks list. Begin by creating a table with four columns:
- A column for the risk.
- A column for how you’ll recognize when the risk changes. From something that might happen to something that is happening.
- A column for what you will do as a response to the risk.
- A column for the risk owner
Then, get your team together and start brainstorming risks. Give them permission to put their black hats on for an hour and have fun with it!
For one project, the team came up with a top 13 (it didn’t turn out to be unlucky). I tried to get them to drop the bottom 3 to have a nice neat top 10 risks list. The team thought that was a stupid idea, so I made a smart managing decision, and listened to them. We made a top 13 risks list.
Disagreement may occur around which risks are bigger threats than others. In our example, the project team members decided all risks were big enough and none should be eliminated from the list. If your project is not as clear cut, use a basic Probability and Impact (P&I) rating scale. This can help you gain a clear ranking of which issues to address first.
This example includes an indication of severity for risks. Any risk that lands in the red or orange squares should be handled first, followed by yellow. Green risks should be put on a “watchlist” and reviewed periodically. Don’t spend much time on watchlist risks. Lower severity risks could become issues and should be monitored. They should not distract focus from the red, orange and yellow risks.
You may have seen similar charts or used one with a different scale. There is no standard or points for style. Work with what’s best for your project.
table {
font-family: arial, sans-serif;
border-collapse: collapse;
width: 100%;
}
td, th {
border: 1px solid #ffffff;
text-align: left;
padding: 8px;
}
| Risk | Indication | Response | Risk Owner | |
|---|---|---|---|---|
| 1 | Scope Creep | Requirements are incomplete or Project Stakeholder has ambiguous business needs | Avoid: Define business need and obtain stakeholder agreement. Stick to it! | Peter Planner, Project Manager |
| 2 | Losing a key developer | Project team member resigns. | Mitigate: Collaborate early and often between the team. Do not silo developers.
Accept: Develop relationship with HR or reputable Consulting firm to find a replacement who can perform quickly |
Charlie Technology, CTO |
| 3 | Unachievable schedule | Team feedback, missed milestones | Mitigate: Add appropriate team members. Reduce scope | Peter Planner, Project Manager |
| 4 | Unable to handle peak load | Pages load subjectively slower than requirements or current site | Mitigate:Get performance and load numbers for current site or reference site Have an environment for load testing Put focused load testing in place to verify acceptable performance on key pages |
Tricia Ops, Technical Operations Leader |
| 5 | Changing requirements | Requirements are incomplete | Mitigate: Hire a Sr. Business Analyst at the start of the project | Peter Planner, Project Manager |
| 6 | Team has several new team members; risk of Storming | Disagreements between members, low morale or motivation | Mitigate: Plan team norming exercises for beginning of project and incorporate into project plan. Team members should escalate conflicts quickly; problem solve |
Peter Planner, Project Manager All project members |
| 7 | IT infrastructure upgrades interrupting schedule, causing delays | IT announces new software upgrades | Mitigate: Contact IT and ask for infrastructure update schedule for the timeframe of the project Avoid: Work with IT Manager to upgrade the software of project team outside of normal working hours or after the project finishes |
Peter Planner, Project Manager |
| 8 | Building the wrong thing that does not solve customer problems | Unclear stories/requirements Early customer tests fail |
Mitigate: Usability testing & address issues. alpha/beta testing & address issues Business facing tests Avoid: Create high fidelity prototype |
Peter Planner, Project Manager All project members |
We reviewed our risk list every week or so during a team meeting. We closed risks as they disappeared. We added new risks as we became aware of them. We re-ranked the risks as they seemed more, or less, likely. You might expect that thinking about risks every week would be kind of a downer, but it wasn’t. The team felt good, responsible, and on top of things. They didn’t worry about the risks too much because they were on paper and being tracked. They could focus on getting things done, and they did. Other teams felt like we had our act together since they weren’t doing much with risk management.
Many of the risks stayed around until we got to final integration testing. Almost all risks closed when we shipped our product. A few remained that might show up and require patching the product.
Risk management can get complicated when formal methods are applied. These methods include tactics like risk discovery, impact analysis, contingency planning, mitigation, and monitoring risk transitions. Some projects need this, but risk management doesn’t always have to be complex. For this example project, actively managing risk took little effort. And it had a positive impact on both the health of the team and the project.
Successful projects take identifiable risks, make them visible, and plan around them. When an issue occurs, the project drives away from failure and speeds toward success.
If you’d like to learn more, Waltzing with Bears is a great short book on risk management, by Tom Demarco and Timothy Lister.
