Risk Management Planning

I’ve offered – and provided already to many requestors – my template for a Risk Management Plan. It’s not groundbreaking or even earth-shattering, but there are just some key concepts to include and critical areas to ensure are covered. It’s not absolutely necessary to even have a formalized plan, unless you’re working on a critical government project and it’s required or you’re working with a project staff or customer that is missing the point of managing risk…then it may be necessary to formalize it for them.

I recently ran across another outline for a risk management plan and I am sharing it below. If you want my copy/template as well, just send me a note and I’ll email it to you – mine comes as a prepared document and you can just insert your info.

Risk Management Plan

Purpose

The risk management plan lays down the groundwork for how risk management will be carried out in a project. It serves as guidance for the risk process, its thresholds, and its formats, defining the roles and responsibilities of stakeholders in risk management. It is notable that the risk management plan is not a listing of specific risks and is not used to establish the particular strategies for risks, once they are identified.

Application

The risk management plan is shared with project stakeholders to clarify their roles and responsibilities in the risk management process and to identify when specific potential risks are truly of concern to the organization. It also outlines the risk budgeting process, detailing how and when risk contingency funds may be allocated and applied.

Content

The risk management plan consists of basic information about how risk management will be conducted during the project. It does not address specific behaviors associated with specific risks, but instead forms a framework for the rest of the risk management process.

1.0 Risk Process

Risk process may be as simple as two steps (e.g., assessment and response) or as complex as six or seven steps (e.g., planning, identification, qualification, quantification, response development, and response control). The process steps should include clarification on how each of the processes will be carried out and the level of depth of information to be provided for each.

2.0 Risk Responsibilities

Just as the buyer and seller in project environments have different responsibilities for deliverables, so do they have different responsibilities for risks. Those responsibilities should be outlined here. Responsibilities may include information on who will identify risks, as well as who should evaluate them and develop strategies for those that are of the greatest significance.

3.0 Risk Thresholds

Thresholds represent personal and organizational tolerance for risk. They are the definitions of tolerance in terms of budget, schedule, requirements, and other sensitive cultural issues (e.g., politics, media exposure). They are normally expressed as ceilings beyond which the project should not proceed, or as notification points for upper echelons of management.

4.0 Risk Finances

This element of the risk management plan may address both funds set aside for risks within the project (contingency reserve) and funds set aside within management control for risks outside the project’s purview (management reserve). In both cases, this component of the plan details how and when the project team may draw down funds from those reserve accounts. Risk finances may also provide detail on how the amounts for the reserve accounts will be established.

5.0 Risk Evaluation

Because evaluation protocols vary from project to project, the risk management plan should include some detail on how risks will be scored and termed. Particularly for risk qualification, there should be some definition of terms for both the probability of a risk’s occurrence and for the impact should it come to pass. Many projects employ the high–medium—low (H-M-L) scheme for both impact and probability. The risk management plan should define each of those terms.

6.0 Process Timing

High-risk projects may require frequent risk reevaluation. Projects with lower risk may not require such frequency. The risk management plan should include detail on the frequency of risk identification, assessment, and response development, as well as the appropriate application of any tracking processes or documentation.

Dealing with Changing Specifications

I’ve already written a lot about customer indecision, change orders, and the customer’s inability to truly know what it is they want. And I’m sure I’ll write considerably more on the topic as it is one of the most critical issues we deal with and our ability to manage these situations is often directly tied to customer satisfaction. It’s our job as project managers to drag that out of them and to anticipate what some of their unstated needs are along the way.

Even though I’ve shared many of my own thoughts on this topic, I still find that it’s interesting to present other view points and text giving different angles on the same popular topics. Most of the text from this article comes from the book “Integrated Project Management” by Earl Hall and Juliane Johnson. This is subsection of their chapter on project change and deals with the how to handle customer indecision and changing requirements. It’s a little dry, and I think it underestimates the amount of changes that PMs must deal with in the course of an implementation, but fundamentally it’s pretty sound.

Management of Customer Indecisions

A project manager must begin working on a project with the expectation that the customer will request change at least once, perhaps several times, regarding the project outcome(s). The project manager must be prepared for the possibility that a task leader or an external subject matter expert will discover and present a new or better way to perform tasks after the completion of the task list. If the proposed change occurs during the project planning period, it can be accommodated by backing up the planning process and replanning with the change(s) in mind. Before this is done, however, the project manager must create a new, revised specification statement and clear it with the customer, appropriate subject matter experts, and key team members. The project must always be working toward one clear goal, and all prior specifications must be destroyed.

Change requests that arise during the project’s planning process are not hard to deal with if they are few and infrequent. Changes do interrupt the planning process and cost time and money, but aside from that and the frustrations the team experiences, they can be handled effectively. When a customer is uncertain about exactly what he or she wants and frequently changes his or her mind this must be dealt with as a special case.

Customers often want a project to begin before they have decided on a precise outcome. They may not expect to be able to precisely define what they want for some time. However, integrated project management (IPM) is based on the premise that a precise outcome statement—specification—must be decided upon before planning can begin. Both experience and logic support this proposition. Nevertheless, when thinking is at the scope level, it is often reasonable for the customer to be uncertain of the precise outcomes. Can an integrated project be started under these conditions? The answer is yes. A preliminary specification can be created. A project manager begins the project by leading the creation of this specification.

As the project manager helps migrate the project from scope to specification, he or she aims for a precise specification that will capture the current best estimates of what the outcome should be. This specification will be used in the initial planning and execution of the project. At the same time, the project manager puts in place a project specification change procedure to deal efficiently with the outcome changes the customer may desire later on.

Experience has proven that this approach is more efficient than simply starting in a general direction, then adjusting, redirecting, and reorganizing as an outcome concept emerges. It must be understood that in IPM, replanning will be a major event and will not take place piecemeal. It will not occur often during the life of the project. Small and frequent modifications of the specification must be prevented because such practices kill projects.

The rationale for insisting on the creation of a specification before starting project planning derives from the processes that must take place when the change in a project is executed. Before a project can be changed, there must be something to change. The effort to get the customer to agree on what the “current” best estimate of what the outcome should be is defined within the statement of work. Sometimes, customers do not decide on exactly what they want until they see what is involved in providing them with what they think they want. Sometimes, the general dimensions of an outcome are identified, but the exact characteristics of the outcome must wait on “research in progress.” The customer and the project manager agree that a precise outcome definition within the general framework of the expected outcome will enable the project manager to begin the project planning. It also will provide for the startup of project execution. The initial plan is expected to be relevant when the revised outcome statement is decided upon.

Creation of the initial project plan gives the project team something useful to do now, and it creates a good plan for the team to examine and change when a specification revision is presented. This fits in with the fundamental process of project change. When a change is proposed, the original project plan—the Gantt chart and the resource table—is the necessary reference for the considerations of what can be done and what this will cost.

A Discussion on Project Success

How do we define project success? For me, the analysis is usually broken down into these four categories:

• Customer satisfaction
• End product usability
• Budget management
• Schedule management

Gary Heerkens’s brief case book entitled “Project Management” takes a cut at the definition of success. I’ve included a slightly modified version of this section below.

Defining Project Success

The definition of project success is obviously critical. After all, that’s how you’ll be judged as a project manager. Unfortunately, there are almost as many definitions of project success as there are project management professionals. To add to the confusion, every organization has its own view of what matters in project outcomes.

So, instead of trying to focus on one definition, I’d like to offer a framework of thought on success. I’ve found it valuable in the many discussions I’ve had over the years. If you consider the various ways that projects could be deemed successful, you come to realize that project success exists on four levels, each with a unique perspective and set of metrics. And despite the specific values used to quantify success or failure, the principle remains constant. Following are the four levels of success that I use:

Level I—Meeting Project Targets

Did the project meet the original targets of cost, schedule, quality, and functionality? Although it’s certainly admirable to beat these targets, my concept of success is tied to whether the project manager did what was expected. In other words, maximum success is zero variance between project targets and results. There are at least two reasons why I embrace this interpretation. First, it supports the organization’s need for certainty. Second, I believe that project managers who chronically beat targets are suspect, at best.

Level II—Project Efficiency

How well was the project managed? This is a metric for the process. If the project meets its targets, but the customer groups, project team, or others were adversely affected by the project experience, the project will probably not be perceived as successful. Project efficiency can be evaluated through the use of criteria such as the following:

• The degree of disruption to the client’s operation
• How effectively resources were applied
• The amount of growth and development of project team members
• How effectively conflict was managed
• The cost of the project management function

Level III—Customer or User Utility

To what extent did the project fulfill its mission of solving a problem, exploiting an opportunity, or otherwise satisfying a need? If the project did not satisfy the true need, the project may be perceived as a failure.

Here are some questions to help assess Level III success:

• Was the original problem actually solved?
• Was there a verifiable increase in sales, income, or profit?
• Did we save as much money as expected?
• Is the customer actually using the product as intended?

Level IV—Organizational Improvement

Did the organization learn from the project? Is that knowledge going to improve the chances that future projects will succeed at each of the three levels described above? High-performing organizations will learn from their failures—and their successes—and use that knowledge to improve their success rate in over time. This level assumes a long-term perspective and measures organizational learning and a resultant increase in project successes. The primary tools for organizational improvement are the maintenance of accurate historical records and the widespread use of lessons learned.

Feedback

What is your definition of project success? What is your organization’s definition…or your PMO’s definition? Some organizations focus on customer satisfaction. Others focus mainly on budget or schedule. I’d really like to hear your feedback and thoughts.

IT Process Improvement – Staying on Track

In an IT shop, our PMOs and project managers rely heavily on the IT department for many things: support, personnel, technology for the project, and did I already mention support?

Process improvement and overall IT governance can make your IT organization transparent and in better alignment with corporate strategy, which better enables IT to support the various units within the organization – including the PMO.

This article is based loosely on information I gathered from an InformationWeek article from late 2008. Below are nine traps to avoid in order to keep your IT departments process improvement on track.

Poor Expectation Setting

Before leaping into process improvements, it’s critical to set realistic expectations for management, peers, and other stakeholders. A process improvement plan, like hardware and software buys, must have agreed-on requirements, configuration, and customization to be successful. It takes a long-term commitment, and unless your organization is willing to change, it will likely fail.

Lack of Balance

When looking at a process improvement plan, the people and technology landscapes must be considered, too. Think of people, technology, and processes as a triangle: Focusing too heavily on one area will pull the others out of alignment. When designing a software tool, consider the processes dependent on it and the staff who will use it. We’ve seen many organizations focus on one of these areas, not see results, and then move on to focus heavily on another area. This approach isn’t effective and often wastes money.

No Consensus

Some process initiatives are bottom-up, and others are top-down. In the end, however, process improvement affects many people, and without consensus, the initiative will fail. Resistance from one group or even an individual can impede progress.

Lack of Automation

The IT environment of today has never been more dynamic, and the ability to automate process between systems is critical. A few years ago, there was a lot of energy around startup runbook-automation tools that helped organizations automate processes. However, customers’ failure to buy these tools in large numbers took much of the steam out of this market. The concept is still a sound one: Automating complex IT processes helps reduce manual errors, meet compliance requirements, and track discrete tool costs.

Insufficient Commitment from Leadership

A bottom-up approach can jump-start the process, but without the support of leadership, the overall initiative will fail. Full-scale process improvement takes a significant, long-term commitment from the leadership team. Organizational change, investment in tools and training, and culture adjustments are all significant undertakings.

Lack of Practical Training

Hundreds of companies offer process training. Many organizations will specialize in ITIL or Six Sigma or PMI processes and PMP certification, and while these can provide a common vocabulary, most organizations stop there. We hear many stories, of companies that have spent good money to train their staff, but then are frustrated when the company doesn’t change after all that training.

Stagnation of Planning and Documentation

Like documentation, planning is important, but if there’s no way to incorporate it into the organization, planning isn’t much use. We see far too many dusty process documents sitting on office shelves. Typically, outside consultants or internal groups wrote them with the best of intentions, but they were never internalized or implemented.

No Workable Process

Processes can be extremely exciting for some, but you must guard against conforming to a single best-practice framework too rigidly. Some of the most successful process implementers start with a best-practice framework, and then blend elements from other frameworks and unique business drivers into their overall approach. While this may sound like heresy to some purists, best-practice frameworks evolve, and incorporate the best of what’s done in the field.

Hands-off Outsourcing

There are a lot of companies out there that would love to improve your processes. This option may sound very appealing, but make sure you do it the right way. You need to own the processes at the end of the day, and you know more about your business than anyone else, so take a mentoring approach rather than a total outsource. And be sure you allocate enough time to work with the outsourcer.

Book Review: Project Governance

The July 2009 book review from Project Management Tipoffs (brought to you by Arras People) covers Ralf Muller’s book entitled, “Project Governance.”

The concept of the book is that without a governance structure, an organization runs the risk of conflicts and inconsistencies between the various means of achieving organizational goals, the processes and resources, causing costly inefficiencies that impact negatively on both smooth running and bottom line profitability. Please read on…

Project Governance

A night to read and some real practical solutions to implementing governance in your organisation – either at portfolio, programme or project level. “Project Governance” from Ralf Muller is a little misleading as it doesn’t just cover project level governance. Starting at the corporate level, with academic theory, the book soon moves onto programme and project governance taking into account different organisational models. Is your organisation a “Flexible Economist Paradigm”? Or in others words has your organisation established project management as a core competence, with professional project managers? Governance within this environment will follow a different path to that of a “Conformist Paradigm” organisation where project management is performed by technical experts as an on-the-side task.

So what is governance and why would you want to know more about this area of project management? Governance is defined in the book as:

“Governance provides a framework for ethical decision making and managerial action within an organisation that is based on transparency, accountability and defined roles”

This book covers everything from portfolio management, sponsors & steering groups, strategic and tactical project management offices, programme management, in fact it brings together a lot of areas and topics already within the public domain. There are two sections that are particularly worthy of note; a governance framework for project management and how much governance is enough? The framework provides a three step process which enables an organisation to increase its PPM governance. Within each step there are three areas; what can be done, what should be done and what is done. Step 1, includes basic training and methodology use (it talks about the adoption of methodologies such as PRINCE2), introducing steering committees (ensuring what is learnt is adopted and put into use) and the use of audits and reviews to ensure the “what is done” or learnt has translated to successful project delivery.  A simple framework which covers the different levels of organisational maturity has been conveyed well in this book and would be a welcome addition to any programme office manager, portfolio manager or organisational change specialist’s bookshelf.  That said, this is also a book aimed at the project manager, especially their role within project governance but also programme level, portfolio level and ultimately how their delivery impacts the corporation as a whole.

Knowing when there is enough governance – appropriate to your organisation and the programmes and projects it delivers – is also covered. A simple approach which focuses on the relationship between project manager and steering group and the roles & responsibilities of each may be useful insight for any project manager.  Like much in project management, communication is the key for effective governance at each level of the organisation and Muller’s book goes a long way to showing how to utilise effective communication to achieve a integrated governance model.

More information and review text about Mr. Muller’s book, as well ordering information, is available at Gower Publishing.