Back in 2005, while working in the Project Management Center of Excellence group, I published a white paper on the integrated risk management process through Boston University which was shared at their Project Management in Practice Sympodium. Seventeen years later, this process still holds its weight in gold, because many of the misconceptions of what risk really means are still out there. Here are some of the top misconceptions I have seen during my career.
Misconceptions #1 “Risk is a bad thing”: Many of us associate risk with a negative impact to our projects but that is not always the case. Risk is defined as an unplanned event that can have either a positive or a negative influence on the project’s success. For example, if your customer wants to change their product design while your engineering group is still in the design phase, then the risk is positive. There is time for change, the impact is small on the overall schedule, and the customer gets what they want. In fact, if it is a request that alters the contract, you can charge the customer for the change. Thus, the risk becomes an opportunity for the project. But if the customer requests a change to the design once it is completed, and you have started manufacturing the product, then your schedule will be impacted, there will be rework costs in your engineering and manufacturing departments, and the customer will need to be managed along with the change. In this example, the risk has a negative impact or is considered a threat to the project. Therefore, it’s important for the project manager and team to stay on top of the risks and have constant communication with the customer on the status of the project.
Misconception #2 “The project manager is the owner of all project risks”: The project manager should not be carrying the burden of any threat or opportunity alone because they cannot identify all possible risks alone. As their role title states, they are managing the project, not owning it. It always depends on the risk identified whom from the project team takes the lead to mitigate it. The key is to have diverse specialties forming the project team that will support the project manager. Therefore, the project manager may be responsible for the risk log but not for mitigating the risks on the log alone, it’s a team effort.
Misconception #3 “Risks are identified only at the start of a project”: Anyone who has been on a project will tell you that it always looks good on paper on day one. Once the project is in full swing, many factors come into play and there is a 99% chance the project’s execution is completely different than what was planned. A project is described as iterate for this reason. Therefore, the risk log prepared during the planning stage will not remain exactly the same either. Risks should be identified on the log as soon as someone from the project team is aware of them. They can have a proposed mitigation plan as well but only when the timing for this risk to manifest itself is reached can you use your proposed mitigation plan and hopefully avoid any negative impacts to the project. Sometimes mitigation isn’t even needed because the risk did not manifest itself. Other times the proposed mitigation plan was off, and you needed to correct it to avoid catastrophe. One of my pet peeves is when project managers use the risk log as a template they need to fill out, then they put it away and manage their project without it. These are the project managers that are reactive and firefighting daily. Many of these projects end up with cost overruns and/or late deliveries. Yet no one from the project can figure out why. Filling out a risk log template just to do so is a waste of everyone’s time and does not help your project. The risk log should be reviewed with the project team at least weekly so to ensure that any new risks not on the list are placed, existing risks which no longer will materialize can be closed out, and the on-going risks are reviewed to ensure the mitigation put in place is still effective based on the project’s progression. It’s a fact that 80% of the issues that occur in a project could have been avoided if a risk log were in place and continuously updated appropriately.
Misconception #4 “Risks are specific to a project, so sharing lessons learned is impractical”: The integrated risk management paper showed how a company compiled all their projects’ risks into one table that then was scrubbed, categorized, and placed into the risk log template for future projects so that the project teams would not need to start with a blank template. Based on the project the new team worked on, they would be able to benefit from going through past risks to see if the risk could occur in their current project. If so, they would incorporate it in their log and monitor the risk. With the past projects’ information, they would also have possible mitigation plans at their disposal to help them. This turned the risk management for a project proactive instead of reactive and they were able to make money on all their projects. As a bonus, the lessons learned from the past risk logs were used to train project teams on what to watch out for and how to be prepared. The crazy thing is that they did this all on Excel spreadsheets. No elaborate risk management tool that cost a mint and would be complicated. They used the power of Excel in 2003. Can you imagine with Windows365 how they have evolved? And yet, many people prefer talking about the same issue that keeps occurring, costing the company money, and doing nothing about it.
Misconception #5 “We need to absorb any risk costs because the customer won’t pay”: Sure, even me as a customer, I prefer getting a deal and not paying for more value. But if I have no choice, I will pay for what I want. Many customers think the same way. It really comes down to what type of contract you have with your customer. There are two types of contracts - cost reimbursement (also known as time & materials) or firm-fixed price (also known as sum price). Cost reimbursement is easier to manage changes and risks because everything is identified, costed, justified, and approved for payment. The total project cost is estimated at the beginning of a project, but true costs are only known at the end of the project once everything is completed, and the money spent is tallied. Firm-fixed price is the problem child for this misconception. It is vital that the contract has a detailed scope leaving little grey or ambiguous verbiage that can be interpreted in different ways. For example, if the contract calls for “bolts” so, you decide to supply stainless steel, but the customer comes back to you stating they had wanted galvanized, then you are going to have a tough time convincing them that your bolts are what the contract calls out for. To avoid this example from happening, you need to have regular meetings with your customer to detail out what wasn’t in the contract, get agreement, then proceed to buy or manufacture what was decided on. This way, you do not spend more money and time in the backend. Therefore, for fixed-price contracts, there should be a robust change management process that integrates with the risk management process that is agreed with the customer at the start of the project to avoid disaster. This will have you dotting your “I’s” and crossing your “T’s”, so you stay close to your fixed price.
I hope this sheds some light on risk management for you. If there are other misconceptions you have seen, please feel free to share with us. For those with fixed-price contracts that are looking for help to put together a robust change and risk management process in place, reach out to us. We are in the process of creating an IRM Training on Udemy. If you are interested, please subscribe to our website so we can inform you once it is launched.