Why Projects Succeed: Risk Identification

April 4, 2012 | Author: PM Hut | Filed under: Risk Identification, Risk Management

Why Projects Succeed: Risk Identification
By Roger Kastner

Why Projects Succeed is a blog series in which Slalom Business Architect Roger Kastner sheds light on key factors behind the art and science of successful project management and invites readers to discuss how they apply across different environments.

In the previous article of this series, I wrote that the value of Proactive Risk Management is in the ability to identify and plan for all the issues that may knock the project sideways. The purpose of this is specifically so you have the bandwidth to deal with those unforeseen elements that are going knock you sideways no matter what you do to prepare.

This time I want to focus on the inputs of Risk Management, the Risk Identification process, and a specific way to identify risks early in the process that also measures how the project team feels about the feasibility of the project.

Why would a Project Manager want to know how the team is feeling about the likelihood of success? Shouldn’t the team members just put their heads down and get work done? Well, no. Perception is reality, and likely if your team members feel headed for failure, those feelings will manifest themselves into the quality of work and result in a lack of calories burned.

If the team does not feel like the project goals are attainable, then that might be the biggest risk to success the project may face. Regardless if their perceptions are unfounded, the successful Project Manager will want to focus immediately on those feasibility concerns.

Foresight in Sight

In order to improve foresight into risks, uncertainty, and perceptions of feasibility, the successful Project Manager will need more eyes. Not only will the successful Project Manager use their own experience and intuition, a Project Manager should utilize his or her team and primary stakeholders to help identify the areas that can knock a project sideways. This is also a great way to obtain buy-in and consensus, not only in the risk management process, but also in the feasibility of the project itself.

One of best ways I’ve seen this done is by conducting what is called the “Why won’t this work?” meeting. The purpose of the “Why won’t this work?” meeting is to facilitate a conversation with all the team leads and project members to identify all the reasons why the project may fail. Like with any brainstorming session, there is no such thing as a bad idea, the goal is to list as many possible reasons as possible.

Once all the reasons have been written on the whiteboard, then the Project Manager will triage which ideas should be analyzed first by asking, “Which of these potential issues have either a high, medium, or low likelihood of occurring and which ones have a major or minor impact to the project if they do occur?” This is a good way to prioritize the items and to eliminate the random “volcano eruption” or “Mariners make the playoffs” prognostications (and yes, I have witnessed both identified as risks on projects).

Now, the successful Project Manager will address the items in priority order and ask “What can we do to prevent these from happening or mitigate the impact of each one if they do happen?” This will demonstrate to team members in the room which of the risks require response planning and which require monitoring.

But more importantly, by asking both questions, “why won’t this work?” and “what can we do?” the team will accomplish several things in addition to risk identification, including:

  • Empowerment. The Project Manager is setting the tone early in the project that they want to hear from everyone on any concern that they may have. Again, the goal is to identify all the “known unknowns” so you have the bandwidth to detect and deal with the “unknown unknowns” that appear in mid-flight and knock the project sideways. If the project is knocked sideways by something that was actually known by a project team member but not announced, the Project Manager may have not empowered the team member to announce the foreseeable problem.

  • Consensus. Are the project goals achievable? This meeting will result in the team agreeing either yes or no, and the successful Project Manager will want to know this before getting too far into the project.

Of all the reasons to hold this meeting, the most important in my opinion is Consensus. The result of the meeting should point to whether most team members think the project is achievable or not. Hopefully through this dialogue, even though the team has identified a significant list of potential risks, the team members feel like those items can be addressed appropriately and the project can be successful

Conversely, if the team arrives at the consensus that the project is not doable, then the successful Project Manager should focus all efforts immediately on addressing this concern. A lack of belief in success will result in poor quality, missed deadlines, and bad morale. The Project Manager should recruit the sponsor(s) and primary stakeholders to get involved with addressing the reasons why the team is pessimistic for success. If the opinion of the team is still negative, then the Project Manager should engage the sponsors in potential changes to scope or direction and to become closely involved in the potential morale issues that may impact project performance.

Real World Experience

The most valuable time I did this it was not at the beginning of a project, as I prescribed above, but when I was assigned to a project already in mid-flight. The reason I did this was because after the first several discussions I had with project team members, each conversation would end with, “…oh yeah, and this project is doomed.”

“What?” I responded as intelligently as possible, followed up that bit of genius with a “Why?”

Each reason I heard was followed by another. I would ask if any of these issues had been discussed by the team, and the common response was “no one asked.” The next meeting I scheduled was entitled “Why this won’t work?”

At the “Why this won’t work?” meeting, I handed out sticky notes and asked each person to write down their reasons why the project will most likely fail. I went around and collected the sticky notes as they were written, and then stuck each one on the white board. When the group was done writing, I then would read each one and ask for a description of the reason, if there was any evidence of the reason actually occurring or the probability of the reason actually occurring, and then the total impact of the reason. I was prioritizing by asking for probability and severity.

Then I asked something contrarian to the normal brainstorming rules. I asked the group to argue why the reason was not a valid one. Some of the dire risks were actually “resolved” right there, and it was because the person who identified the risk was missing some critical information another person in the room had.

There were a couple reasons that the team agreed were true risks to the project, and we discussed and identified ways to mitigate the impact of the risks if they came to be realized. Then I asked one more question: “Knowing what you now know, who here thinks the project will be successful?”

Talk about risky. What if only half the room raised their hand? What if no one raised their hand? Technically speaking, that would have been “a bummer.”

Fortunately, everyone raised their hand, some more quickly than others, but everyone did. The lesson was that if we collaborate, share information, and work together, we can achieve the goals of the project. That was powerful, the team did a 180° degree turn on their prognosis of the project, and four months later we had a successful launch.

Summary

Identifying risks is one of the first steps in the Risk Management process, and the “Why this won’t work” meeting is not only a great way to identify risks, it’s a great collaboration process to gain consensus through teamwork and make a statement about the feasibility of a project. In facilitating this conversation, the successful Project Manager will start the Risk Management process by identifying most of the known risks, should uncover any significant morale issues, and should enable the Project Manager to be perceived by the team as a true leader. Not bad outcomes for just one meeting.

What do you think?

What tools or processes have you used to identify risks or deal with the challenge of perceptions of project failure? Please join the conversation, post a comment, and share your experience.

Reprinted with permission from Slalom Consulting - © 2012 Slalom Consulting

Roger Kastner is a Business Architect with Slalom Consulting who is passionate about raising the caliber of project leadership within organizations to maximize the value of projects. You can read more articles from the series on “Why Projects Succeed” here.

Share this article:
  • Facebook
  • LinkedIn
  • TwitThis

2 people have left comments

Excellent article. Facilitation skills are so important to a PM for all the reasons you have mentioned. I had been considering doing a team workshop on risk identification on my next project, this article will save me a lot of time in planning it.

Thanks

Thomas wrote on April 5, 2012 - 4:57 pm | Visit Link

One thing we should realized here is the phrases used to elicit information or changing perception.
Why won’t this work? giving the same tune as per existing mood in team and getting all risks. Next one is turning thoughts to “can we make it work?”. Yes leadership is all about directions and getting right thing done…

It is nicely explained to get risks from team only when the team already half way through the project. If we do this at the start of project, we get suggestions based on past experience and most of the time we see blank faces. I believe that’s why we try to recruit/use similar line experience folks to foresee the issues.

gannabattula wrote on April 10, 2012 - 3:59 am | Visit Link

feel free to leave a comment

Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

All fields marked with " * " are required.

Project Management Categories