Risk…What can go wrong?

Perhaps you have heard the parable of the blind men and the elephant. The story starts with blind people, that have never seen or touched an elephant. They travel to touch an elephant, but each person can only touch one part of the animalⁱ. After each touch on the animal, they take what they have learned and describe the great beast. For example, the person touching the trunk, says the animal is like a great snake. Everybody has a perspective of what the animal is, though their limited experience results in no agreed or cohesive description, and rather, the discussion descends into chaos.  It is not until the group describe what they have learned from their experience together, that the true nature of the animal is revealed.

It is similar for many project management endeavors (probably any collaborative or team effort), from scope discussions to schedule generation. Today we are going to explore risk management. Risk management should start early in the project, right after the project charter is developed and the identification of the stakeholder¹. Stakeholders are those who have interest in the effort and results of the project. At this point, we know the objectives, and we know the key participants, and we are well armed to take on the question, “what can go wrong.”

This question should start every project Stakeholder Risk Interview (SRI) or Risk Review (RR) meeting. The SRI is a one on one conversation. The RR meeting includes multiple stakeholders in one room. This is effective to drive out risks. Because every stakeholder has a different interest for the project and a different perspective based on their experience, one stakeholder’s risk usually leads to another stakeholder’s risk.

Several years ago, I participated in a Risk Review meeting led by the project control person with over 25 stakeholders representing Accounting to Line Operators to Plant Management. The session lasted over 4 hours and generated close to 100 risks. The project control person recorded all of the risks and published the list to all attendees.

Neither the Risk Review meeting nor the Stakeholder Risk Interview (SRI) should look for solutions. Just capture the risks and if possible the reasoning behind a particular risk. The reasoning may drive out why this is a viable or unviable risk for the current project.

Guidelines:

1. Don’t try to lead a stakeholder by saying, “what about this or that?”  The stakeholder may focus on that subject, rather than free think from experience.
2. Don’t look for solution and don’t let the Stakeholder propose solutions. There will be time for that in the Risk Assessment process.
3. If conducting individual risk interviews, be careful sharing other stakeholder’s risks. Occasionally, stakeholder holds will challenge the validated of a risk. Keep track of how many times a particular risk comes up.
4. At the end of the interview always let the stakeholder know, if they think of any other risks to let you know. This is part of the continuous monitoring for new potential risk events.

We can glean some risk by reviewing documentation, assuming there are project archives for review, as well as a check of previous projects for closing, lessons learned and other risk documents.

Risks extend beyond the project documents to the team. Some team members may assume all will go well. These members have been a part of teams that faced few issues on a project. Or, have not been on a project team and don’t know what to expect.

One good way to start a risk development meeting with the project team: What can prevent us from delivering this project? Or, what can happen that causes the delay of delivery? Remember: There are no stupid answers and don’t judge or look for solutions.  In this regard risk exploration should follow the same rules as brainstorming:

1. Defer judgement calls on the idea
2. The more ideas the better
3. Build on other’s ideas
4. Many brains and eyes

Some of the Risks listed below may be considered ‘a no-brainer’ and assumed will be okay or not to occur. There is a risk of being blindsided as the project proceeds. So, be careful assuming. Some of the risks often overlooked are:

1. What if the project sponsor is unengaged?
2. What if the estimates are off – lack of understanding of scope or missed scope?
3. What if the team loses a member, including the PM – due to illness, assigned to another project, or leaves the company?
4. What if the project loses the project sponsor?
5. What if the schedule is too tight, too lose?
6. What if the project spans two or more fiscal years – funding continuance?
7. What if the project plan is not approved first go around, including budget & schedule – delaying start?
8. Risk is often described as a negative - wrong and/or a positive - opportunity. In this article we will not discussing opportunities, as opportunities are few & far between and may be a solution for a logged risk. We think of the concept of positive risk from this perspective:  I am at risk of winning the lottery. What sort of risk is winning the lottery?!  We like the risk of living large, eating T-Bone and Porterhouse steaks and perhaps drinking expensive alcohol.