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.

Sources:

The Guide to the Project Management Book of Knowledge, 4^th 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

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

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

• 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.

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.” 

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.

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

• 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.)

Although approximately 50% of PMP holders work in the I.T. sector, the PMP credential is not an I.T. “cert.” The only connection between the PMP credential and the I.T. sector is that, just like marketing, construction, government, architecture, research & development, political campaign and space mission projects, I.T. projects need to be managed and, therefore, using PMPs to manage the projects verifies that the credential holder has certain experience, knowledge and education; that the individual follows a code of professional behavior; and that the individual has committed to on-going continuing education and to making contributions to the PM profession. — Oh, and yes, that the person passed a rigorous exam, though that is only one part of earning the credential.

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.

The PMBOK Guide is a standard for the project management profession. Its intention is to serve as a guide to the body of knowledge within the project management community and as practiced by members of the profession. There is no single document that contains the project management body of knowledge. Indeed, some of it is not published at all but, rather, is simply recognized as good practices and norms within the profession. This body of knowledge is growing every day.

The PMBOK Guide is not intended to be used to learn project management or project management concepts. It’s especially not intended to teach or suggest PM techniques or methodologies.

It’s not a “how to” book nor is it a description of a methodology. It’s a standard, not a methodology. PM professionals and the organizations they work for can use the PMBOK Guide as a guide for developing their own methodologies or for creating organization standards.

It’s particularly important to understand that it is not a standard or specification for the examination portion of the PMP certification. For one thing, at least 30% of the material on the examination is not covered by the PMBOK Guide. (There IS an exam on the PMBOK Guide. It’s the CAPM exam, which only covers knowledge of the PMBOK Guide.)

While the PMBOK Guide only changes once every 4 years, the exam component of the PMP credential is constantly changing. Much of the material that showed up in the 4th (2008) edition of the PMBOK Guide has ALREADY been showing up on the PMP exam for several years – e.g., PTA, TCPI, etc. PMBOK Guide 4th edition came out in December, 2008, but these topics have been showing up on the PMP exam as early as 2006. The group at PMI that develops the standards (such the PMBOK Guide, the Standard for Risk Management, etc.) and the group at PMI that develops the the certifications and their corresponding exams (such as PMP, CAPM, PMI-SP, etc.) are two separate groups that DO NOT interface with each other. They are two separate groups. If anything, the standards group looks at the work that the credential group (PMP, CAPM) does and uses it as one of the many inputs for what they put into the standards such as the PMBOK Guide.

A reviewer on Amazon.com observed that there is a widely held notion that PMBOK = Project Management. I disagree with that observation. The false notion he observed is only held by those people who do not know what the PMBOK is. Also “PMBOK” is not the same as “PMBOK Guide.” PMBOK is an acronym for the Project Management Body of Knowledge. As I said, above, there is no single document that contains the project management body of knowledge. It’s simply the body of knowledge that is collectively known among practitioners,  academics and organizations who practice or research project management. The document known as the PMBOK Guide is simply a guide to that massive body of knowledge; an entry-point to further information and a standard for developing protocols, methodologies, techniques and practices within your own organizations and project management practices.

The PMBOK Guide is a reference work, not a text book or a study guide. It’s not meant as an introduction to project management any more than a volume of statutes is meant to be used as an introduction to the practice of law or the Physician’s Desk Reference (PDR) is meant to be used as an introduction to pharmacology for doctors and pharmacists. As with technical references for other professions (such as statute books for lawyers, clinical references for doctors, etc.), non professionals may find the PMBOK Guide difficult to follow and even dry. An experienced and trained project manager should find the PMBOK Guide perfectly understandable and not very difficult to follow. An experienced and professional project manager looking at the PMBOK Guide for the first time may find its format unfamiliar (at first), but he/she should find the material and the concepts in the document familiar (though organized in a way they may not be used to).

On the other hand, an entry-level project manager, or a non-project manager who is thrown into project management tasks may, indeed, find the PMBOK Guide difficult to follow and difficult to understand. This is not unlike a sophomore accounting student opening up a set of GAAP or IFRS guidelines and finding it hard to follow or finding the writing style very didactic and anything but light reading, while this would NOT be the experience of a certified CPA or an experienced accountant or financial professional.

Very important: The PMBOK Guide is not an I.T. text nor should it be considered part of the literature covering the topic of information technology. For some reason, the document is shelved in book stores along with I.T. books. It really should be shelved with books on management. In the same way, PMP examination study guides are also shelved next to I.T. books. The PMP credential is not an I.T. “cert.” In fact, it’s not even in the same class or category of “certifications” as technical and I.T. “certs.” The PMP is a professional credential, in the same category of certifications for other professions, such as accounting, law or medicine. Unlike I.T. “certs”, where the only requirement to earn the certification is the ability to make an appointment at the Prometric center and where the only criteria for earning the certification is the ability to pass a test, the PMP credential has experience, education, continuing education & professional contribution requirements. There is also a requirement to adhere to a professional code of conduct.

Because of the “cert” fever within the I.T. community and among I.T. workers, many non-PMs in the I.T. sector are pressured to add the “PMP” letters to their names. Recruiters are among those who create this pressure. Because they are not experienced project managers, these I.T. people are pressured into lying about their background and skills during the PMP qualification process — and getting friends to lie during the audit and vetting process. This may account for the number of (dishonestly earned) PMPs out there who may have the letters after their name (though they got those letters under false pretenses) but who are not really project managers at all. This is why people see a lot of “PMPs” who have no idea about what they are doing.

Project management is a profession. While there are many professional project managers out there practicing their profession, there are quite a lot of non-project managers who have been thrown into PM responsibilities and roles. While they do, indeed, hold a “job” as a “project manager” and are being asked to perform the tasks of a project manager (and may even have a title called “project manager”), they are not project managers. They’re just people who have been asked to do the work of project managers.

The PMP credential is not for people want to move into project management. It’s for people who ALREADY ARE project managers and have been for several years. The PMP credential verifies that the individual has the education, years of experience, professional training, adherence to a professional code of ethics, commitment to ongoing continuing education and commitment to ongoing contributions to the project management profession. The exam portion of the credential verifies that, in addition to all of the above, the individual has an understanding of the profession he/she has been practicing; that the individual knows that project management is NOT common sense and that he/she is not managing project by seat of his/her pants or via intuition; that the individual understands that sound project management is based on the past experiences of other members of the profession, based on research and sound empirical (scientific) study; that the “art” and practice of project management is based on science, not intuition.

Finally, as to the question “what would be the best alternative book”: there is no alternative. The PMBOK Guide is the accepted global standard and the recognized guide to the project management body of knowledge. That’s all it’s intended to be and it serves that purpose well. It’s not the end to all ends. The members of the project management profession who contributed to the document did not aspire to cover all there is to know about project management. It’s not perfect and it’s constantly changing (every 4 years) as the profession continues to grow and mature.

You can (and should) supplement the PMBOK Guide with other PMI standards and frameworks — e.g., The Standard for Program Management, The Project Manager Comptency Development Framework, The Practice Standard for Work Breakdown Structures, etc. There are supplemental standards and frameworks developed by other professional and academic organizations as well. However, as the GUIDE to the “body of knowledge” within the profession, the PMBOK Guide is the standard. There are other books and sources on other topics of project management, including sources on methodologies, leadership, PM tools, general management, the management of people, budgeting, scheduling, quality management practices, organizational behavior, etc. as well as industry specific literature on project management, such as marketing project management, I.T. project management, construction project management, research & development project management, etc. However, such topics are outside the scope and purpose of the PMBOK Guide. Of course, since anywhere from 60% – 70% of the material in the examination portion of the PMP certification either comes directly from the PMBOK Guide or requires understanding of the concepts in the PMP Guide, a knowledge of the material in the document is important to anyone who is planning to sit for the exam. So, while the PMBOK Guide is NOT a study guide for the exam and is not intended to serve as such, familiarity with it is an important part of both practicing the PM profession as well as earning the profession’s certification.

For more information on the relationship between the PMBOK Guide and the PMP Credential, see:
Is studying the PMBOK Guide enough to pass the PMP certification?

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

What are the immutable constraints here?

Time is a the most immutable constraint. NASA was determined to meet, the late, President Kennedy’s goal to send a man to the moon and return him safely to Earth before the end of the decade. This constraint simply cannot be changed. So Dec 31, 1969 would be the drop dead date.

The scope constraint defines the specifications and parameters of the project. In this case, it’s landing a man on the Moon and returning him safely to Earth. “We choose to go to the moon in this decade and do the other things, not because they are easy, but because they are hard, because that goal will serve to organize and measure the best of our energies and skills, because that challenge is one that we are willing to accept, one we are unwilling to postpone, and one which we intend to win, and the others, too.” (President John F. Kennedy, Speech at Rice University, September 12, 1962)

Cost can be modified, if approved by the “sponsor” (Congress). For all intents and purposes, the White House and Congress were prepared to spend as much as necessary to achieve the goal on time. “To be sure, all this costs us all a good deal of money. . . Space expenditures will soon rise . . . from 40 cents per person per week to more than 50 cents a week or every man, woman and child in the United States, for we have given this program a high national priority.” (President John F. Kennedy, Speech at Rice University, September 12, 1962)

Because of the tight schedule, and challenging scope, something may have had to give. While Congress was able to keep throwing money at the project, they could not add any more time to the project nor could they change the scope in any way. (As an analogy, think of creating a baby as a project. Even if unlimited funds for medical bills and care were available, from conception through gestation to birth, neither the time — 9 months — nor the scope — deliver a healthy baby — could be changed; even if we throw more people on the project. If it takes 1 woman to make baby, could we do in it 1/3 of the time if we use 3 women?!)

When the scope is immutable and you MUST get it done by a certain date — no exceptions — and throwing more money at the project will not change the parameters or change the maximum amount of time available for the work, if something to has to give, then that something could very likely be the safety and well-being of the project team.

Does this mean that it’s OK if some astronauts die during the project?

The answer is yes. In fact, some astronauts did die (Apollo 1).

Time and Scope cannot be changed. Cost can be modified but, while time and scope are the independent and immutable variables, the dependent variable of cost will have no effect (i.e., cannot change) the other two. Therefore, something will have to be sacrificed in order to meet the project deadline within time and scope. The sacrifices that might have had to be made (and, as it turned out, were made) were identified as part of the project assumptions and constraints.

Norrie and Walker maintain that the added strategy constraint is central to the achievement of the other three, traditional, constraints. The project and its deliverables must result in the realization of business benefits. These benefits must be aligned with the organization’s strategic goals.  [Norrie, J. & Walker, D.H.T, Project Management Journal, Vol, 35, No.4, 47-56, 2004]

In 2009, Harold Kerzner distilled the idea of strategic alignment with organizational goals further as: “Value.” [Kerzner, H. & Saladis, F., Value-Driven Project Management, 2009. Also see : "PMI North America Global Congress, 2009, "Session Closing Remarks", Orlando, FL. October, 13, 2009.]

The Apollo program (of projects) certainly met the strategic goals of the United States in the 1960s.

As far as value is concerned, in the Rice University speech, quoted from, above, President Kennedy identified the value that the United States (and the World) would receive from the space program in general and the Apollo program in particular.

Perhaps most projects do not have the political power, unlimited funding and strategic importance of the Apollo program. Very few have Apollo’s stark consequences, let alone the level of acceptability for such consequences. Nevertheless, one of the lessons learned from the project is that even such a unique and extraordinarily large and expensive project such as this one shares the same triple constraints with the, more down-to-Earth, projects that most of us participate in today, 40 years later.

© 2009, Jerry Bucknoff, MBA, PMP