5 Pillars of Risk Management in Complex Projects

Like it or not but for many project managers Risk is a four letter word. It is root cause for all their problems and stress throughout the project execution. But whether you like it or not you have to prepare and manage these inevitable risks in your projects. And there will be plenty of those if your project is even reasonably complex. Although every PM pays lip service to risk management it is more mismanaged than managed. The result is inevitable. Standish report published that only 34% of technology projects succeed. Rest fail. That is colossal waste of talent and resources and the reason is improper appreciation and handling of risks.

All complex projects need robust risk management framework established and practiced throughout the project execution. I have listed 5 important elements of the risk management that need to be established and practiced in any organization that execute complex projects. The below steps are really circular in nature. The last step should feed back into the first one.

Framework for Risk Management

1. Prepare project managers for handling risks
   1. Establishing and evangelize organizational risk management policies. This involves clearly written policy, framework, thresholds for risk triggers, supporting artifacts like checklists, templates, case studies, risk repositories etc that can be tapped by PMs.
   2. Identify common categories and sources of risks that PM need to keep in mind. Organizational learning plays important role here.
   3. Training the project managers and teams on risk identification techniques, risk assessment methods and risk response measures.
   4. Regular monitoring and control mechanism. E.g Risk audits, project reviews, escalation mechanism.
2. Now Identify & Analyze each risk in your specific project
1. Review statement of work and contract documents to unearth hidden risksConsult organization risk repository
2. Look at similar projects to identify the risks. Look at historical data. Look into various sources and categories that have tendency to throw the risks
3. Consult subject matter experts. Where possible consult the customers to learn from their experiences. This is especially true to understand installation and field conditions.
4. Look at your supply chain. The components and suppliers are major sources of risks.
5. Then analyze each risk qualitatively.
6. Then analyze the same risk quantitatively and rank them on priority.
3. Device Risk Response plan
1. For every risk identified come up with the risk response strategy. Risk can have negative or positive impact.
2. For every negative risk one of the below response is selected after careful analysis:
1. Avoid- This is risk you want to avoid at all costs. Example can be, to go with third party library rather than developing your own. Or decide not to take up the project.
2. Mitigate- Risk is feasible but you want to take proactive steps to reduce the probability of its occurring or its impact if it ever occurs. Example can be, proactive training or SME hiring to reduce the possibility of risk due to unfamiliar technology/domain. Build quick POC to check the feasibility of certain technology platform.
3. Accept- Depending on cost benefit analysis of risk response options you may just decide to accept the risk and do nothing, especially for low ranking risks. You typically accept the external environmental risks as force majeure. Common risk like unplanned leave by team members are also accepted as it is.
4. Transfer- You transfer the risk to either your customer or partners. For example, The project team may refuse to take any responsibility for manufacturing or IP/patent violations issues…and associated risks.
3. For every positive risk one of the options is chosen
1. Exploit
2. Share
4. For every identified risk define the minimum below in your risk register:
1. Risk id
2. Risk description
3. Probability
4. Possible impact
5. Risk threshold & Risk trigger
6. Risk response. For mitigation give mitigation strategy and plans.
7. Risk owner. Who is responsible for keeping an eye on this risk and track it till it is no more relevant for the project.
8. Stakeholders who should be aware of and who should be kept in the loop while tracking the risk.
9. Fallback option or contingency if risk really happens despite all mitigation plans.
5. Make necessary changes to the project plan based on the risks identified and their response. For example, certain risk mitigation plans may call for budgeting additional efforts, time or investments.
4. Monitor & track these risks like a hawk. The following are the typical control & monitor mechanisms that companies use:
1. Project reviews- Every periodic project review should include risk review and status update. The discussion should involve risks that are not imminent but can occur over a longer period. The general tendency is to discuss the risks that are near term or already impacting. Risk triggers should be analyzed to check if risk response mechanism needs to be triggered.
2. Structured Risk audits- Ideally organization level quality audits should include thorough risk audits. Such audit should check if risks are defined, updated, tracked and communicated with stakeholders and should cover at least large, complex or fixed priced projects in the purview.
3. Reporting- What gets reported is usually gets done. Every important report should have placeholder for critical risks and their status. I am talking of both customer as well as internal reports here.
4. Identify new risks in daily stand up meetings or other team/customer/vendor meetings. Update the risk register immediately.
5. Every change request (CR) should mandatory trigger risk analysis for new risks or impact on existing risks. This is especially true when it comes to contract related risks. If new CR would impact any contractual obligations then that is big risk while taking on those CRs.
5. Learn from experience. You all have heard this before- Those who do not learn from history are condemned to repeat it. So avoid repeating the history as far as possible
1. The project learning should get reflected in improved common understanding and organizational capability to handle similar risks in future.
2. Update organizational checklists, templates and risk repository based on your project learning.
3. Share your experiences in community, among team members and with your customer.

Perhaps the most important value addition that a full time project manager can make is effective risk management. The risk management can make or breaks the projects depending on how well it is done. If project manager does this function well then he has earned his place.

Is risk management purely science or contain aspects of art also?

What in your opinion plays more important role in identifying all the risks in the project-  documented risk repository in the organization OR your own (or team’s) past experience?