Risk Management

December 2nd, 2011

An often neglected, yet essential, element of project and program management is project risk management.

Project Risk Management is concerned with the identification and planning for potential risks that may impact the project (both positive and negative impacts).

Risks can be positive (Opportunities) or negative (Risks or Threats).

* Positive Risks:

  • Per-GB cost of storage may decrease during the course of the project
  • Scope of data conversion work may turn out to be less than we anticipated

* Negative Risks:

  • Commercial software product may not perform as expected
  • Degree of software modification may turn out to be greater than we anticipated

Note: Risks and Opportunities are not mirror images of each other. For one thing, a risk that has a less negative impact than expected can be considered a positive risk, though it may not necessarily offer an opportunity. In addition, definitions of opportunities are usually less precise than definitions of risks.

Risk has two primary components for a given event:

  • A probability of occurrence of that event
  • Impact (or consequence) of the event occurring (amount at stake)

Issues vs. Risks

There is some confusion between issues and risks. While both issues and risks have consequences (impact), the probability (and, to some extent, the time) dimension is different.

A risk is an event or situation that may possibly, but not necessarily occur, in the future. The probability can range from 0% to 100%. An example: possible loss of key staff members. When risks are identified ahead of time, we can determine mitigations and responses to prevent the risk from becoming an issue.

An issue is a situation that either is currently occurring or will occur in the future. It’s usually unexpected or has a low enough impact and/or probability that developing a mitigation or response was a low priority and, therefore, not part of the risk register (see below). The probability is 100%. An issue that has occurred or is currently happening is referred to as a problem. An example: upcoming termination of vendor support for an older release of a software product. When we know that the end-of-support date is approaching, it becomes an issue. When the date is actually upon us, it becomes a problem. When we know that an issue is coming up, we can try to take steps to deal with the issue before it becomes a problem. Too often, however, issues arise unexpectedly and immediately and must be addressed immediately.

Steps in the Project Risk Management Process

Project risk management proceeds as follows:

  1. Early in the planning, the project lead defines how risk management will be conducted for the project. The output of this activity is the risk management plan which becomes part of the overall project plan.
  2. The project lead then works with project team to identify the project risks and conducts qualitative and quantitative analyses of the risks to determine the probabilities and impacts of the risks.
  3. After scoring the risks based on the probabilities and impact, the top risks are identified and a risk mitigation / risk response plan is developed defining the actions to be taken in the event of those risks.
  4. Throughout the duration of the project, as part of monitoring & controlling, the risk responses are carried out (when needed), new risks are identified, and previously identified risks are re-evaluated for any changes in their impact or probability. As a result of these activities, the schedule and/or cost baselines may be modified.

Risk mitigation vs. risk response.

Risk mitigation is a planning technique used to reduce the probability of  a risk occurring or reduces the impact to an acceptable threshold.

Risk response is the action to be taken in the event that the risk actually occurs. As each risk in the risk register is identified, one or more responses to the risk are determined and documented. Creating the risk register along with risk mitigation and responses is important:

Imagine this scenario. Due to the complexity and unique nature of your organization’s business processes, the development of the business rules for a new ERP system is taking 3 times as long as expected. When the project sponsor asks about this set-back, you reply, “I knew this was going to happen!”

If you don’t have risk response previously identified, then the sponsor can ask you, “if you knew this was going to happen, why didn’t you have a response plan in place?!?”

Another element of risk is cause. The existence of something or the lack of something can cause a risky or dangerous situation to exist. The source or cause of this situation is referred to as a hazard. The degree of risk can be viewed as a function of hazards vs. safeguards where safeguards mitigate the level of risk. For example, lack of technical knowledge can be a hazard that can be mitigated by training.

The risk management processes occur throughout the project life cycle – starting with risk identification during the Planning phase, continuing with risk analyses and the creation of the risk register.

The risk register is reviewed during project monitoring:

  • Changes in the project plan can lead to additional risk identification.
  • The occurrence of a previously identified risk can result in changes to the project plan.
  • Scope changes can result in new risks. Scope changes can also result in the elimination of previously identified risks.

Look for Upcoming Post: Project Risk Management vs. Enterprise Risk Management (ERM).

Sources:

The Guide to the Project Management Book of Knowledge, 4th Edition (PMBOK Guide), ©2008, Project Management Institute

Practice Standard for Project Risk Management, © 2009, Project Management Institute

Project Management: A Systems Approach to Planning, Scheduling, and Controlling, Tenth Edition, by Harold Kerzner, John Wiley & Sons © 2009

© 2011, Jerry Bucknoff, MBA, PMP
Sphere: Related Content

Project Coordinator and Project Expediter Roles

March 10th, 2011

Organizational Structures for organizations that do not have a full-scale project management environment.

Guide to the PMBOK, 4th Edition, defines Project Manager as “The person assigned by the performing organization to achieve the project objectives.” (Pg. 444). In full scale project management environments, the project manager devotes his full time to managing projects or, as a program manager, managing programs of projects.
This is in contrast to a Functional Manager, which the PMBOK Guide, 4th Edition defines as “Someone with management authority over an organizational unit within a functional organization. The manager of any group that actually makes a product or performs a service. Sometimes called a line manager.”(Pg. 26, 436)

Many organizations do not have a full-scale project management environment. This is particularly common in IT environments, although, thanks to the growing recognition by organizations of project management as a profession, this is rapidly changing. When the organization has a functional management structure and does not support a full-scale Project Management environment, the following project support roles may be used.

Project Expediter
The Project Expediter monitors and reports on the status of the project to senior management. This role has no authority.

The Project Expediter acts as a communication coordinator only and cannot enforce any decisions.

Project Coordinator
The Project Coordinator role is similar to expediter, but has some limited, referential authority. The project coordinator may report to someone higher on the management food chain than the expediter. The Project Coordinator has some authority to make decisions.

In IT, this person may be what recruiters refer to as “a PM who can roll-up his sleeves and debug code” or “PM/Business Analyst who can create project documentation and supervise others.” These are actually team member roles and not true project manager roles. However, in addition to his/her hands-on, team-member, tasks, this person also has some limited supervisory responsibilities as well project monitoring and status reporting responsibility.

These two roles are not limited to organizations that do not have a full-scale project management environment. These roles can also be utilized in situations where a project manager (PM) or program manager (PgM) has responsibility for large, complex, project or program. Some components of the project monitoring, reporting, may be delegated to a junior person (less than 3 years of PM experience). In addition, where the scope of the PM’s or PgM’s work is large, tasks that are not appropriate for a PM or PgM or can be taken off the PM’s plate, such as requirements gathering, setting up meetings, identifying resource availability, writing management reports, creating presentation, can be delegated to a project coordinator.

In some cases, where the project is very small or the project effort is short (less than 3 months, less than 50 person-days, less than 3 team members plus the lead), a project coordinator can be assigned to supervise the day-to-day work and ensure that targets and committments are being made.

In PMOs (project/program management offices), a PMO analyst (often miscorrectly refered to as “the PMO”) may also take on project coordinator tasks such as helping the PM develop the project schedule, project scope, generate communications, collect and report project status.

Do not confuse these, very different roles. In particular, do not confuse these roles with that of a project manager or a program manager. Occassionally, due to the economy or, more rarely, by choice a project manager by profession may take on one of these roles, usually on a contractual basis between full-time jobs. However, while the person is a project manager by profession, he/she is not performing in that role while taking on one of the above, more junior, project roles.

Jerry Bucknoff, MBA, PMP

Upcoming Article on PM Best Practices

May 27th, 2010

Watch this spot

Coming soon . . .

January 28th, 2010

This spot reserved for a future article.

Management Planning

This spot reserved

January 21st, 2010

This spot if reserved for the Jan 21, 2010 article.

Contribute to the Project Management Knowledge Base

December 30th, 2009

One of the key professional responsibilities of a project manager is contributing to the project management knowledge base. What does this mean?

In a nutshell, don’t keep your knowledge and experience locked in your brain. Share it!!  Brain

  • Share knowledge
  • Research
  • Build the capabilities of colleagues (i.e., teach, mentor, provide opportunities for your colleagues and your team members to build experience and knowledge)
  • Advance the profession (engage in activities that will improve the overall PM profession; engage in activities that will promote the profession)
  • Step up, at your own organization, to champion the value of project management. That is, playing a key role in the growth of PM within your organization
  • Always record “lessons learned” at the end of a project or project phase; contribute to your organization’s organization process assets (OPAs). These 2 activities contribute to PM knowledge base and will help your colleagues during future projects
  • Participate in PM forums, conferences and PMI chapter meetings
  • Write articles


PMI expects PMPs to stay engaged with the profession.

Sphere: Related Content

How Can I Get Started on the PMI-RMP Certification?

December 6th, 2009

During my time at PMI’s Global Congress in Orlando, one of the questions that came up repeatedly was “how can I get started on the PMI-RMP Certification? What materials should I be using to prepare myself for the exam component of the certification”

Here’s what I learned.

The four PMI standards you should be focusing on are:

1) The Guide to the PMBOK 4th Edition, particularly Chapter 11 (Project Risk Management). Because risk communication represents 27% of the topics on the exam component of the PMI-RMP credential, you should be comfortable with Chapter 10 (Project Communication Management) as well.

2) The Standard for Program Management, 2nd Edition, particularly Chapter 11 (Program Risk Management)

3) The Standard for Portfolio Management, 2nd Edition, particularly Chapter 5 (Portfolio Risk Management)

and especially:
4) The Practice Standard for Project Risk Management, 1st Edition, 2009.
PMI writes: “The Practice Standard can be used by project management practitioners to validate the risk management process being employed in a specific situtation, project or organization. The Practice Standard for Project Risk Management is consistent with the current release of A Guide to the Project Management Body of Knowledge (PMBOK® Guide) — Fourth Edition.” Risk_Slots

You can supplement your study with books such as:

Risk Management: Concepts and Guidance, 3rd edition by Carl L. Pritchard. Pritchard was the Team Lead for Chapter 11 of the current PMBOK Guide.

Risk Management, Tricks of the Trade for Project Managers by Rita Mulcahy. This is a practitioner book with plenty of exercises to develop and reinforce your risk management skills.

Linkedin.com has a PMI-RMP group and a PMI-RMP study group, both hosted by Annette Suh, PMI-RMP

If any of you out there do go through the process of earning this credential, please keep me apprised of your progress and share your experience with the process with the rest of us.

Add to favorites


How is the PMP Certification different from I.T. “certs”?

December 1st, 2009

Unlike I.T. “certs”, PMP Certification is a Professional Credential.


I.T. and other technical certifications (e.g., MSCE, CCNA, CSJD, CSP, ITIL) are Knowledge based:

  • Measures vocabulary, the documented body of knowledge, some standard protocols or practices
  • The ability to perform at a certain level is not measured and can only be assumed
  • In most cases, there are no experience or prior educational requirements; there are no ethical standards or code of conduct required to maintain the credential; the only requirement to earn the “cert” is the ability to pass an exam
  • Certifications are bestowed by the individual owners of the “certification” exam, often a for-profit organization; recognition of the “certification” may vary from cert to cert and from organization to organization

Professional certifications (e.g., PMP, CPA, ABA BAR) are Competence based and, as such, are best described as credentials as opposed to simply certifications:

  • Infers a candidate’s ability to actually perform professional tasks (e.g., Project Management) at a given level
  • Encompasses both knowledge of the subject and the necessary skills to apply that knowledge
  • Certain experience and educational requirements are required and must be verified (++)
  • Credential is bestowed by a non-profit, professional association (e.g., PMI, AICPA, ABA, etc.) and, sometimes by local authorities (countries or states). In the case of the PMP, the credential is bestowed and monitored by PMI, a globally recognized not-for-profit, professional association.
  • Continuing professional education and professional development activities are required to maintain the credential (e.g., for PMP, 60 professional development units each renewal cycle; this can include seminars, formal education, participation in PMI activities, publications, lecturing and teaching, etc.)

Read the rest of this entry »

Sphere: Related Content

What is the PMBOK Guide

November 30th, 2009

Clearing Up Some Misconceptions About the PMBOK Guide

Listening to PMP candidates, project managers, and students of management and project management,  I’ve learned that there are some misconceptions about what the PMBOK Guide is. Some think that it’s intended as a textbook on project management. Others think that it describes some kind of project  management methodology. Yet others have the notion that it’s meant as a study guide for the examination component of the PMP credential. Some even think that the PMP exam is on something called “PMBOK” (whatever that is) and that the Guide to the PMBOK is a study guide or textbook covering the topic of “PMBOK.”

I’d like to clear up some of the misconceptions.
Read the rest of this entry »

Sphere: Related Content

Project Management Lessons Learned from the Apollo Moon Landing Project

November 23rd, 2009

Looking at the Apollo program, we can see a very vivid (and real life) example of how the Triple Constraint works in a large, very expensive, politically charged and highly visible project.

Project: Put a man on the moon

“First, I believe that this nation should commit itself to achieving the goal, before this decade is out, of landing a man on the Moon and returning him back safely to the earth.” (President John F. Kennedy, Joint Session of Congress on May 25, 1961)

Scope: Landing a man on the Moon AND returning him safely to Earth

Time: Before the decade is out

Cost: Whatever Congress will approve

Triple Constraint

What are the immutable constraints here?
Read the rest of this entry »

Sphere: Related Content