With projects of a certain size it is very important to consider the risks that could derail the project. A project may fail miserably by the mere fact of an unexpected event taking place, which can unbearably lengthen its execution, make it too expensive or destroy morale of the team working on it.
Note: As the topic is broad, in this first article I will tell you where project risks are hidden and how you can identify them. Next week I’ll tell you how to analyze them and plan the best possible response.
What a project risk means
Although the “risk” word has clear negative connotations, in Project Management it refers to any uncertain event that, if it happens, positively or negatively influences an important aspect of the project: time, cost, scope or quality. It is also convenient to be aware of positive risks because they can create opportunities to help you complete the project with a better outcome than expected.
Although you are not concerned about the risk event itself—something that does not have to happen—, there are two aspects of the risk that you should care about:
- Its impact, i.e. the result that would occur in the project—scope, planning, budget or stakeholder satisfaction—if it happened, and
- The probability of it eventually happening.
Since projects are unique by nature, they are very susceptible to risks. To mitigate them in the best possible way you must identify them, analyze them and develop a response to each one.
How to identify risks
Risks can occur at any level of the project. Since there is a team of people who will carry out the project (although the team could be just you), they are often the biggest source of risk. Does your team have the appropriate technical skills to carry out the project? Do team members have the social skills needed to work in a team? Will they have the necessary availability?
If it is a technology-based project, the technology to be used is another important risk factor. When you combine different types of technology from different vendors, you must test thoroughly that they can be integrated into one system and work properly. Do you know all the technology involved in the project? Have you included all testing tasks in the project schedule?
Most projects fail because requirements are not properly identified—either they are ambiguous or incomplete. Is everything clear?
A major schedule risk occurs when estimates are overly optimistic. Did you leave some contingency slack in the estimate of each task ?
The same applies to budget. Is it a predefined, poor or very optimistic budget? A poor budget usually entails unrealistic time estimates.
Will the project be performed within an organization where there may be conflicts over resources to use? Is it common for the organization to change priorities frequently?
In addition, there can be external factors beyond your control that can jeopardize your project: new laws or regulations, changes in commodity prices, political changes, strikes, weather, etc.
Is there any task that depends heavily on an external predecessor task, over which you have no control? This could produce a series of reactionary delays that wreck your schedule and the anticipated completion date.
Where to look
The first place you should look to find potential risks is the project documentation. Review the project requirements. Any assumption is a risk itself, because it is something you consider true for planning, although it is not one hundred percent sure. For example, if you have someone that has committed to devote 10 hours a week to the project but also has other commitments, you should treat this assumption as a risk. Likewise, any restriction is also a risk. A very tight time or cost restriction may cause the project to fail at the slightest change.
Examine who is involved in the project, their technical ability, people skills and availability. Ensure that there are no inconsistencies with the schedule and the assigned tasks.
Review the schedule, the time estimate for each task and task dependencies. A multiple successor task can be a risk, as does a task with multiple predecessors.
Interview your team members and ask them what risks they are able to see in their work. Usually the people who know the most about project risks are the people who are working on the project.
Finally, brainstorming with the different parts of the project—team, organizers, suppliers, customers, etc.—is a very useful way to identify risks.
No comments