Introduction
“Risk management is the identification, evaluation, and prioritization of risks (defined in ISO 31000 as the effect of uncertainty on objectives) followed by coordinated and economical application of resources to minimize, monitor, and control the probability or impact of unfortunate events or to maximize the realization of opportunities.”
Or at least, that's how Wikipedia defines it. But I find that to be a rather complex and general definition. At the moment, we're more interested in what risk management means practically for software development.
So let's try to simplify things.
Any project and its implementation are fraught with a wide variety of risks, and we can't even predict all of them until we're knee-deep in the project. In a perfect world, we'd be able to foresee and preemptively eliminate each of these risks. Unfortunately, that's simply not possible, so the risk management includes evaluating and managing these obstacles as they arise. In software development as in business, probable threats can and should be managed.
Of course, that doesn't mean we shouldn't try to predict and preempt risk. Each investor or product partner who cares about the success of his business or software project should investigate the possible adverse factors affecting the successful completion of the project and take appropriate measures to prevent or minimize them. Risk management is aimed precisely at such activities.
Who Is in Charge of Risk Management?
The development team's project manager's primary task on the project is to manage the project and all the risks associated with it.
The PM's main goal is to ensure that the team can deliver results in a reasonable amount of time with a reasonable level of quality. As part of that, he or she takes on the following responsibilities:
- Risk management
- Progress and status tracking
- Communication management — with the team and the customer
- Conflict resolution
- Project documentation
Risk Management Processes
There is no one-size-fits-all template project managers can use to analyze all probable dangers. Each manager chooses the decision-making scheme that is convenient for him, suitable for a particular company and given conditions.
That said, there are general guidelines a project manager can use as a foundation for risk management initiatives. Namely, every risk management effort — and every decision — has to begin with information. And the project manager will use that information to consider options and potential outcomes before formulating a plan.
In broad strokes, the Project Management Institute's PMBOK Guide recommends approaching risk management in four stages:
- Identification. Identify risks that may interfere with project objectives.
- Analysis. Determine which of the identified risks are the most dangerous.
- Planning. Plan to minimize the most dangerous risks.
- Monitoring and control. Keep the project plan and risk list up to date.
It's important to consider the specifics of the project when making any decisions about it, but these four steps serve as a starting point.
Identification
Determine what risks your project has, and describe them. Visualize this information in any form — the table from the beginning of the article or some other method — that makes sense for the project.
Remember that the nature of the specific project will determine exactly which risks need to be managed and how. For example, custom software for a bank and a web studio will vary widely.
Analysis
For every risk you've identified, calculate its importance, likelihood, and consequences.
Let's say you do not have time to complete the work on time due to force majeure. If you miss your deadlines, you'll have to pay a penalty. One way to mitigate this problem would be to skip the testing phase and save time. But that decision comes with a high risk that, the quality of the product will suffer and it will cost more in time and money to fix the bugs post-release than it would have during testing.
An experienced project manager can determine the likelihood and consequences of a given risk by eye, for example, on a scale of one to ten and then multiply the indicators to determine its importance. See how that plays out with our list of risks from before.
Planning
In broad terms, there are four risk management methods to start with.
Completely eliminate the threat of consequences: This is ideal, but it's almost a fantasy. There is no guarantee that your actions will preempt the problem, though they may significantly reduce the level of consequences.
Soften the blow: You can reduce the likelihood of risk and the level of consequences by preparing for several situations. For example, give a window of time rather than an exact delivery date or develop several scenarios.
Share or transfer responsibility: Inform the customer in advance of the risk and possible consequences. For example, prescribe in the contract that each change of requirements during the course of the project will affect the timing and budget.
Wait and see: In general, do nothing with the risks, and then deal with the consequences, if any.
To choose the right risk management process, you need to understand what you lose in each risk scenario and choose the process that best mitigates that loss.
Monitoring and Control
No matter how much you plan ahead of time, there will always be unexpected obstacles and risks. Be sure to keep the risk analysis up to date and continue using the same detailed processes to solve every problem that arises.
Whatever the risks, it is best to reduce their likelihood at the planning stage. Even if you have a small project and almost nothing to lose, it is important to analyze the state of risks during the project in order to control the situation. By paying attention to risks and their reduction from the start, you ensure they won't snowball into insurmountable obstacles.
