PMBOK: Project Risk Management


Picking up on the series regarding the PMI PMBOK areas (started with “What is the PMBOK all about”), I want to explore the area of Risk Management. I wrote a short post last May (Is Project Management a risky business) but wanted to cover what the PMBOK has to say in more depth.

Racing enthusiasts and fighter plane jocks find taking risks exciting. Businesses and project managers do not!  I think that a project manager has two roles in dealing with risks. One is to identify, analyze and plan to deal with risks to their project’s success in terms of cost, time, scope and quality. The other is to help senior managers and business intelligence analysts identify broader risks to the organization.

Dealing with Project Risks
Chapter 11 of PMBOK is devoted to risk management and offers reasonable process and procedure recommendations for project managers. The risk management tasks listed in PMBOK include:

  • Defining the risk management process – The Plan
  • Identifying risks (see post on “Why identifying software project schedule risks is essential” for some ideas on schedule-based risk analysis)
  • Performing qualitative risk analysis
  • Performing quantitative risk analysis
  • Planning risk responses
  • Monitoring and controlling risks

Because it is not possible to identify or deal with every conceivable risk to project success, I want to focus a bit more on the risk analysis process. The analysis of probable occurrence and the assessment of potential impact provide the deciding factors to select which risks to planned for and which risks to accept.

Qualitative Risk Assessment relies on judgment and experience. New project managers should seek out lessons learned from the organization’s knowledge management system (hint, hint) or ask for input from experienced PMs. You can guide thinking about potential risks by posing theoretical questions to yourself or to a brain storming team working the project such as:

  • What would happen if Sam left or got sick – assuming Sam is a key contributor with unique skills?
  • Have all important decisions on platform, language and process approach been made?
  • Do all stakeholders understand and agree on the project objectives?
  • What if subcontractor X fails?
  • Does the cost and schedule accommodate a learning curve for new hires or new technologies?
  • Do schedule dependencies – see “How to create and use predictive project scheduling” – show any tasks that could bring down the entire effort if unsuccessful?

Quantitative Risk Analysis uses percentages, probabilities and numbers to assess the effect of risks on project success. For some senior management types, quantitative risk analysis is more powerful than qualitative. For example, telling  your boss’s boss that failure to train personnel in the use of project tools might delay the project in meeting milestones is not nearly as persuasive as telling her that the potential schedule delay ranges from six to ten weeks with a cost overrun of $58K at a level of 85% certainty.

Quantitative risk analysis, according to PMBOK, also includes a sensitivity analysis – which risks have the greatest impact – and expected monetary value analysis. Some organizations provide meaningful quantitative risk analysis using simulations and modeling tools to show possible consequences to cost and schedule. 

Organizational Risks
As a project manager, your technical background can help business intelligence professionals and senior managers understand the potential impact of emerging and disruptive technologies. In your interactions with other PM professionals or through tracking events and announcements in trade publications, provide alerts when you see or hear news that affects your organization’s core businesses.

Best Practice
You should approach each project with a checklist of common risks to look for before the project begins.  I have a list I keep handy of the top risk areas that I find need to be addressed on all types of projects.  Then, I get the project team to uncover and identify others as an exercise prior to the kickoff.  If you will capture your risks at the beginning of the project and then continue to identify and update your register, you will find that you have a valuable list of risks to look out for on the next project.  Additionally, you will begin to have good mitigation strategies even before your next project begins.

In the near future, I will dig deeper on this subject and talk about monitoring and controlling risks and creating a risk mitigation plan. Your comments on risk identification and analysis will help other project managers meet their challenge.

Laughter and Humor in the Workplace

A software developer, a CEO and a duck went into a bar …. Just kidding J. I am not suggesting that project managers should be standup comedians. However, I believe that there is a significant role for humor to play in effective management. Humor makes the workplace more enjoyable and can bond a team.  Many healthcare professionals and psychologists advocate laughter as good medicine for us. It has been stated that, “Laughter and humor help you stay emotionally healthy.” Humor can make an unpleasant message easier to take – shared misery is often easier to accept than the misery that flows only one way. Seeing the funny side makes situations tolerable and improves people’s outlook on the project!

Humor lets you acknowledge a problem or difficult situation without appearing defensive.

  • ”There a few things in life harder to find and more important to keep than love. Well, love and a birth certificate.’’ —President Barack Obama, at the 2010 White House Correspondents’ Dinner
  • In 1984, Reagan wanted to confront concerns that he was too old for a second term as president. His, “I am not going to exploit, for political purposes, my opponent’s youth and inexperience” was often quoted and remembered, while the issue of his age went to a back burner.

Humor can make a point and teach correct behavior, while bringing a smile to those being chastened.  Every profession or role has those industry jokes and humor.  I especially like these example quotes from Tech Support, which I selected from over 60 comments at Computer Jokes – a Few Words from Tech Support.

  • When you call the help desk, state what you want, not what’s keeping you from getting it. We don’t need to know that you can’t get into your mail because your computer won’t power on at all.
  • Don’t put your phone extension in your emails to the help desk. We need to keep an eye on the address book performance.
  • Send urgent email all in uppercase. The mail server picks it up and flags it as a rush delivery.
  • When a tech tells you that computer monitors don’t have cartridges in them, argue. We love a good argument.
  • When the printer won’t print, re-send the job at least 20 times. Print jobs frequently get sucked into black holes. When the printer still won’t print after 20 tries, send the job to all 68 printers in the building. One of them is bound to work.

How about the list of PM jokes that Gary put together at his CVR site or Roger Darlington’s, “How to have a good meeting”? Many project managers keep a list of good jokes and funny stories handy so that when they need to diffuse a situation, speak to a set of stakeholders, or just motivate the team, they can use one of the many jokes that are on the internet (like Duncan Haughey’s Top 10 lists)

What humor is not

Humor is not making fun of someone in an effort to change behavior or diminish him or her in the eyes of their peers. Do not make humor personal to a named person or even with the intent that it focuses on one person (Unlike our late night comedians) because it is ultimately hurtful and not funny.  Humor should not be sarcasm disguised with a smile – “just kidding.” Humor is not hurtful, malicious or disrespectful. Humor in the workplace should not include jokes or comments about a person’s appearance, sexuality or religion – can you spell lawsuit?

How to use humor

For humor to be effective there has to be some truth in it – something that listeners can relate to. Like many cube rats, I relate to Scott Adam’s Dilbert. He shows how bureaucracy and greedy people take away individuality and productivity in the work place. Scott Adams, once remarked that when you verbalize what everyone else is thinking, you in effect “take the hit” for them, allowing them the privilege of laughing. Some organizations have a Dilbertization committee to point out procedures or messages that could make it into a Dilbert cartoon if not corrected. It is okay to acknowledge situations that make everyone’s job a bit harder than necessary. Be willing to make fun of yourself and your flaws or failures.

Humor does not have to be verbal. Putting a slinky on your desk or posting a cartoon can put a smile on team members faces. Encourage team members to post their favorite cartoons in a common area. Laugh and enjoy friendly, funny interactions.  As those who work with me know, I love and use the humor of Scott Adam’s with his Dilbert character – since he worked in a highly project oriented telecom company he had some unique insights into the world that we face every day.

Here’s one more appropriate Dilbert

How do you use humor in your project management job? Do you have examples of good and bad uses of humor? Please share.

The Lazy Project Manager's Blog

The Home of Productive Laziness Thoughts

Thoughts, experience, tips and tricks on issues affecting managers and project management

A Girl's Guide to Project Management

Project Management musings for one and all

LeadingAnswers: Leadership and Agile Project Management Blog

Thoughts, experience, tips and tricks on issues affecting managers and project management

Project Management Hut

Thoughts, experience, tips and tricks on issues affecting managers and project management

Herding Cats

Thoughts, experience, tips and tricks on issues affecting managers and project management


Pushing the Edges Out ...


Just another site