Project Management Best Practices » best practices

Risk Management

JBucknoff — Fri, 02 Dec 2011 18:54:24 +0000

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:

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

© 2011, Jerry Bucknoff, MBA, PMP

Sphere: Related Content

Upcoming Article on PM Best Practices

JBucknoff — Fri, 28 May 2010 02:03:03 +0000

Watch this spot

Project Management Lessons Learned from the Apollo Moon Landing Project

JBucknoff — Mon, 23 Nov 2009 21:57:08 +0000

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.

While the “triple constraint” is often viewed as an abstract concept — something out of project management text book or a PMP exam prep class, in fact, it’s a real world set of contraints with very practical considerations . . . as the Apollo project so vividly proves.

Over the past 5 or 6 years, there has been a trend to add an additional constraint to the equation (or, at least, coordinate the original three constraints with it). This constraint is “strategic alignment.”

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

Sphere: Related Content

The P3MO (Part 2) – Best Practices

JBucknoff — Mon, 09 Nov 2009 23:26:25 +0000

High-level View of Project, Program, and Portfolio Management

In part 1 of this series, we defined the P3MO as an acronym for “Project, Program, and Portfolio Management Office.” It’s based on the concept of a PMO (project management office) elevated to cover project portfolio management as well as project and program management. In part 2 we will discuss the relationship between the three components of the P3MO: project management, program management and portfolio management.

Project management ensures the successful completion of initiatives and their associated deliverables within the time, scope and cost parameters agreed to by the end-users of the product, service or result. The project manager manages stakeholder expectations and communication between all team members and stakeholders.

P3MO Relationship Venn - Click on image to enlarge

Program management provides overall leadership and vision to the project management process. The program manager is responsible for delivering value to the community of stakeholders.

Portfolio management aligns the portfolio of projects and other work with the objectives of the organization and ensures that the work delivers value to the business.

The relationship between projects, programs and portfolios

Portfolios are made up of projects, programs and other work. (Other work includes on-going operations, ad-hoc activities and other “business as usual” work.)

The diagram, above, represents a typical portfolio structure.

Where needed, sub-portfolios are possible, in which case they would each be consolidated up into the parent portfolio for the purposes of portfolio optimization, strategic alignment and financial control.

Projects that share a common benefit or serve a common business unit or market may be collected into a program. For example, projects supporting an enterprise-wide directive from the board of directors, such as the acquisition of a new operating company, could be managed as a program. Other examples would be a group of projects serving a single market or geographic region; or the collection of projects supporting the roll out of a new product or service.

A good rule of thumb would be, if managing 2 or more projects together would result in benefits and control not available from managing them individually, then these projects should be managed as a program, with one individual (either the function head or an assigned program manager) accountable for its success.

While the nature of initiatives (projects and programs) is time-based with a defined start and end, the portfolio is on going, its mix of initiatives fluid and changing over time.

Coming up in December and January . . .

Part 3 – Realizing value from the P3MO

Part 4 – Implementing P3MO best practices

Part 5 – The three “pillars” of project success

Sphere: Related Content

The P3MO (Part 1) – Best Practices

JBucknoff — Sat, 31 Oct 2009 20:06:45 +0000

My experience at PMI’s 2009 North America Congress was excellent and, as always, well worth the trip. I met and exchanged ideas with some of the top practitioners, researchers, consultants and authors in the project management industry.

There is no doubt about it. The benefits realized from a sound and well-organized project management methodology based on globally recognized project management standards have been well established. These benefits cannot be overstated. Organizations that make full use of the power of a project-focused environment gain a competitive advantage over those organizations that do not leverage this power. They also gain a competitive advantage over those organizations that publish an “official” project management standard but make little or no attempt to implement it or to make it a part of organizational policy. *

One of the hot project management topics at the Congress was the P3MO (project, program, portfolio management office). Another was that of “value driven project management”, the topic of Harold Kerzner’s closing session speech and the topic of his new book, co-authored with Frank P. Saladis. An integrated project portfolio management environment (i.e., a P3MO) with a focus on driving business value represents the state-of-the-profession thinking right now. I can personally confirm that this approach is beginning to emerge out in the field. At my most recent client, a global life insurance company doing business on three continents, my colleagues and I recommended exactly this approach and delivered guidelines for achieving this. **

So what, exactly is a “P3MO.” At first, my colleagues and I were hesitant about using this acronym. It sounds too much like “CP30″ from Star Wars and could be a candidate for a lot of jokes around the water cooler.

As it turns out, just as C3PO represented state-of-the-art “droid” technology, the P3MO, very much, represents state-of-the-art project portfolio management (PPM).

P3MO is an acronym for “Project, Program, and Portfolio Management Office.” It’s based on the concept of a PMO (project management office), however it is elevated to cover project portfolio management as well as project and program management.

PMO’s are designed to support project managers, including, but not limited to:
• Establishing and maintaining project management guidelines, standards, policies and methodologies
• Monitoring compliance with project management standards and policies
• Managing shared resources across projects
• Guiding and coaching project managers and project team members
• Coordinating communications across projects, including communications with stakeholders and with the business

All PMO’s maintain the following objectives:
• Reduce Delivery Time
• Reduce Project Cost
• Reduce Delivery Risk
• Improve System Quality
• Improve Customer Satisfaction
• Manage Customer Expectations
• Define Standards and Methodologies

The P3MO takes the PMO function to the program and portfolio management level. It shares the objectives of a PMO with the following additional objectives:
• Integrating related projects into programs
• Identifying and delivering the stakeholder and business benefits of programs
• Working with executive management to identify and approve programs and align these programs with the goals and objectives of the business
• Integrating approved programs into one or more business project portfolios
• Providing guidance to the Steering Committee (or other governance body) and assisting them with optimizing portfolios to ensure continued alignment of initiatives and other work with business objectives; modifying the program/project “mix” as business objectives change
• Providing guidance, direction, training and coaching to project managers and program managers
• Maintaining communications with executive management

PMO’s can be categorized into three types:
1) Supporting PMO. Focuses on supporting projects through training, mentoring, administration and reporting. This type of PMO acts in a consultative capacity.
2) Controlling PMO. In addition to providing supportive functions, this type of PMO has a stronger influence on project delivery by offering controlling services, including implementation of standards and policy, and ensuring compliance with those standards and policies. They also conduct project reviews, audits, assessments and project governance.
3) Directive PMO. This type of PMO actually manages projects directly. In a Directive PMO, there is a pool of project managers who report to the PMO Director as their supervisor. This collects all of the project work within an organization to one department.

Coming up . . .

Part 2 -The relationship between the three components of enterprise project portfolio management.

Part 3 – Realizing value from the P3MO

Part 4 – Implementing P3MO best practices

Part 5 – The three “pillars” of project success

* See: Thomas, J., & Mullaly,M. (2008). Researching the value of project management. Newtown Square, PA: Project Management Institute.

** My thanks to Mario Arlt, Vice President of Client Engagements at ESI International and to Oscar de Lucio of UMT Consulting for their captivating and enlightening presentations at the 2009 PMI Congress in Orlando.