Over the course of my career, I have witnessed many projects. I run sales for one of my company’s divisions. If our sales group wins an application, it gets moved to program management/engineering group for execution. The sales team is aware of the project, gets status, details, etc., but is not a true team member of the project. Our sales group has a stake in the success of the project, because our customer won’t be willing to speak with me again if the project is a disaster.
So, all these projects have occurred, and I have had my fair share of disasters. One very important piece of the program management pie is RISK. Yes, risk identification and mitigation; what some may call the most boring part of a project. The exclusion of this boring process has also led to me having very difficult conversations with customers. So boring or not, stop what you are doing and make sure you go through risk identification/mitigation on your next project. I don’t want to be yelled at anymore. Help me, help you.
Here are some things that will help.
Know Thy Project – I have often seen projects go through risk identification and mitigation, only to get burned up on schedule and cost by an adjacent risk that nobody ever thought about. This is due to rushing through project planning to start development. BIG MISTAKE. SIPOC is a great acronym to utilize at project onset. It stands for Suppliers/Inputs/Process/Outputs/Customers. It also helps with risk identification. By utilizing SIPOC, the risk of not identifying risks is mitigated! You’re welcome. The following link explains SIPOC and how to utilize it: http://www.discover6sigma.org/post/2007/06/sipoc/.
Alright, great, we are now confident that risks have been fully identified because we looked at Risk through the SIPOC lens. Now, it is important to have a Risk Register developed before beginning project execution. Jumping the gun and moving to project tasks always seems to be the Achilles Heel of a project. Risk Register’s avoid disaster. There are many ways to develop risk register’s. I found this link to have a good explanation and guide: http://hse.ie/eng/About/Who/OQR010_20090422_v_11Developing_and_populating_a_Risk_Register_BPG.pdf
The guide was based on health service industry, but the risk development process is solid; which would be expected considering the industry. On page 5 and 6 of the above link, there is a really good visual for creating your project’s risk register. The pages that follow provide guidelines for gathering risk and is similar to SIPOC.
Lastly, once a risk register is developed, and developed based on truly understanding risk, the most important thing to do is utilize the documentation. I find it odd that project teams go through the risk process and then forget about it. Bright hub had a nice article on managing risk throughout the project: http://www.brighthubpm.com/risk-management/45164-tips-on-managing-project-risk/
This article reminds PMs that risk registers should be reviewed with the team weekly. This keeps the information that was so painstakingly developed right in front of the team.
Have you been involved in a project that utilizes these types of risk strategies? Do you find that these strategies are effective, or, do you have alternate risk strategies that you feel are better? Risk identification and reduction are often implemented, but overlooked later. Why does this happen when risk processes are commonly employed at the beginning of a project?