4 Risk Categories Are All You Need Worry About
Have you ever been involved in the software project from hell? Many of us have. The project begins with plenty of enthusiasm and optimism. Goals are defined. Staffing is assigned. Delivery dates and budgets are handed out. Everyone’s excited.
But somewhere along the road to done unexpected speed bumps impact the goals, dates and budgets. Some of the bumps are minor while others feel like a rough roller coaster ride. The project team regroups and moves on, yet the goals seem harder to achieve, the dates appear more and more unrealistic and the budget is all but exhausted.
How could this happen? What went wrong? The goals were reasonable. The schedule was adequate. The staffing was solid. What did the team miss?
The answer is risk.
Every project faces many risks during its lifetime. Risks are the opposite of opportunities. They are the bad things that can happen along the road to completion. Risks can be avoided using good planning. They can be mitigated with forethought. Or, they can be accepted because the benefits outweigh the drawbacks.
While risks can be sliced and diced into dozens of categories, let’s examine a simple risk management approach using just four categories:
Glitch: Minor Impact / Low Likelihood
“Glitches” are unlikely and easy to handle. They crop up from time to time on just about every project. You simply deal with them as they happen and move on. As long as some extra time is built into the schedule to manage glitches, they are not likely to cause trouble.
One example of a glitch from my own experience is a software application under development that was performing poorly. Because the production hardware would be much faster than the development hardware, we simply purchased the production system ahead of schedule and used it for development.
Obstacle: Minor Impact / High Likelihood
“Obstacles” are often unavoidable but easy to handle. You know that some number of them will happen so planning is essential. You need to identify the obstacles and either a) define a plan for dealing with them when the time comes, or b) plot a course around them.
Examples of obstacles are the defects/deficiencies present in an off-the-shelf software package purchased for a project. Assuming reasonable care went into the selection of the software, problems encountered with its use are unlikely to derail the project.
Surprise: Major Impact / Low Likelihood
“Surprises” are unwelcome and potentially painful. They aren’t likely so you don’t spend much time thinking about them but if they strike, your project is in trouble. As always, forewarned is forearmed. Lay out these potential surprises at the start of the project and decide what you can do up front to mitigate them. Then prepare an alternate plan to deal with the surprise should it actually occur.
For example, most of us have seen projects get into serious trouble when a key contributor leaves the team. However unlikely it may be that your “chief whatever” will leave before the project ends, it can happen and contingency plans are needed.
Disaster: Major Impact / High Likelihood
“Disasters” are often man-made and devastating. Any project facing risks in this category is in serious trouble at the outset. The management team better have lots of time and money available.
An all-too-frequent example is the geographically distributed project team that has little in common technically, culturally or linguistically, and a management team that expects them to march in unison. If you find yourself on such a project, drive away and don’t look back.