The Project Business Case

Every project needs a business case. This may be informal – especially for small and/or internal projects. It may also be very formal, as is likely the case for very large and very visible projects run for customers outside of your organization. In most cases, the customer has put together a business case in order to gain their own funding for the project. In some cases, they’ll need your help – as the project manager – in putting together the project business case and thus justifying the project and associated expenses to others within their organization.

Below is Carl Pritchard’s take on the Business Case documentation as outlined in his book “The Project Management Communications Toolkit.” I found it to be an interesting read and hope that some PMs find this of value on the projects they are working or getting ramped to work on.

The Business Case Documentation

Purpose

The business case establishes the fundamental rationale for a course of action. It is the documented history of why a project, effort, or approach was selected. It details the objectives, the projected outcomes, and the projected investments associated with the effort. As such, it allows decision makers to examine the breadth of information currently known about the effort to determine whether or not the project is a good idea in terms of cost, benefit, and organizational objectives. It may include statements about the impacts on existing business practices, resource constraints, and environmental considerations so as to provide a comprehensive understanding of the project. In some instances, risk analysis is a key component. It is the primary document defending the rationale for the project.

Application

The business case is normally applied early in the project and may be developed by senior management, marketing groups, the project office, or by any group or organization responsible for initiating large-scale activity within the organization. Business cases in mature organizations follow consistent formats to allow managers to review multiple projects in similar contexts.

The business case will list the key proponents of the project, the sponsor, the users or beneficiaries of the project, and any deliverables. At a high level, it will describe the approach to be used and the business justification or rationale for that approach. Normally, that rationale will incorporate some form of cost/benefit analysis, although the types of cost/benefit analyses and their applications vary widely.

A general outline for a business case might look like this:

• Executive Overview
• Project Description
  • Proponent(s)
  • Sponsor(s)
  • Users/Beneficiaries
  • Deliverables and Quality Criteria
  • Rationale
  • Cost/Benefit
  • Schedule/Time Frames
  • Communications and Reporting Requirements
• Environmental Considerations
  • Project Development Environment
  • Project Implementation Environment
  • Organizational Processes
• Risk Factors/Risks
  • Risk Management Approach
  • Preliminary Risks Identified
• Assumptions

Content

The information supporting each of those outline components should be developed as objectively as possible. To achieve that, each element should be reviewed by at least one other person. The content may be expanded (or compressed) based on the business needs of the organization conducting the analysis. At a high level each section should contain the specific information discussed in the following subsections.

1.0   Executive Overview

The executive overview is a general scope statement identifying the time, cost, and requirements for the project, as well as the business need driving the effort. It should include the names of the project sponsors and project manager, as well as a description of the beneficiaries of the effort. The executive overview should provide a synopsis of the cost/benefit analysis, regardless of whether those costs and/or benefits are tangible or not.

2.0   Project Description

The project description should provide more depth on most of the issues raised in the executive overview, including the background, sources, and history for any data provided as rationale for the project or the cost/benefit analysis. This section may include cross-references to other project documentation, including draft plans, product descriptions, and stakeholder analyses or surveys.

3.0   Environmental Considerations

The cultural, technical, or physical environment may described here in depth, providing information on the practices and protocols typical within the environment.

4.0   Risk Factors/Risks

The risk approach described here may include the means and practices to

be employed for risk identification, qualification, quantification, response development, contingency allocation, and risk reassessment. Any initial or signifi

cant risks identified in developing the preliminary information (like the cost/benefit analysis) should be identified here as well.

5.0    Assumptions

Assumptions are beliefs that are held as true to allow for ongoing planning. In an effort to ensure that they have value, assumptions identified here regarding all aspects of the project (resources, environment, client culture, organizational behavior, and so on) should be validated as practicable.

Approaches

Business cases in some organizations may be voluminous and detailed. Others span only a page or two. Regardless of the level of depth, they should provide insight into the considerations that were used to determine if there is a valid business reason for moving forward with a project. They should be directed at an internal audience, because they may include information about the internal response to and structure for the customer relationship. The internal audience should, at a minimum, include the project sponsors, the project manager and executive management.

Considerations

Because the business case may contain sensitive competitive information, it should be disseminated only to those who have achieved a level of trust within the organization. The author of the document should be clearly identified, and contact information for that individual should be included as well. Although the business case is an initiating document, it should be reviewed and revisited on a regular basis to ensure that the cost/benefit analysis and proposal are still being pursued.

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.

Communication Weak Links

Whenever work passes from one person or department to another, or from a project team to a department or other personnel, the opportunity for delay or misunderstanding is present. By knowing where the weak links exist, you will be able to ensure that the project moves forward, on track, and on schedule.

You will encounter a communication weak link whenever you deal with someone else, and whenever your team members explain, discuss, or speak to another person. In other words, effective communication itself is the solution to the identification and elimination of weak links.

The weak links include:

Project Manager to team member. Whenever you speak to a team member, you encounter a weak link. For example, you instruct a team member to “document the issues and summarize it on a worksheet.” Unless you can clarify exactly what you want, the work may not be performed in the way you expect. All issues or just the ones for this task? How should it be summarized? How should the issues be prioritized? What will the worksheet look like?

If you don’t communicate clearly, chances are the work will have to be revised. And whenever that happens, the team member will complain that your instructions were vague. Thus, make sure that your instructions are absolutely clear, that you explain exactly what you want, and—most of all—that the team member understands exactly what you expect.

Project Manager to outside department manager. Your second weak link occurs when the manager of another department is involved—either as a resource for your project or as someone a team member reports to. The more clearly you explain the scope of the project and the time it will require, the better your chances for full cooperation. The other manager has a point of view you need to respect and understand. For example, the project may make his or her job more complicated, as it takes a resource away from the department. An outside department employee might view your project as extra work, while the other manager may see it as a strain on a limited staff.

Respect other managers’ problems and conflicts. Recognize that their priorities are not the same as yours. Although your project may demand you time and effort even more than the work in your department, that isn’t necessarily the case for other managers.

Project Manager to outside resource. No matter how urgent your deadlines or how important the project is to the company, you may have difficulty getting response from an outside resource—a consultant, a vendor, or another division. Their priorities are simply not the same as yours. Thus, the potential weak link is a considerable one.

Anticipate problems in the way you schedule, in the timing of your requests, and in the way you keep in touch. Don’t wait until the deadline is upon you, but plan well ahead to eliminate the problem through communicating as clearly as possible.

Project Manager to PMO Director and/or Company Executive. Once you are given a project, your first task should be to ensure that you and management are in complete agreement. What is the purpose and the desired end result? You may execute a project according to the highest standards and come in on schedule and within budget. But if the result is not what the director or executive wanted, your efforts will have been wasted. You need to define your processes and your schedule, and check with the person who gave you the assignment.

Another problem may arise when the director or executive changes the assignment. This may occur without your knowledge. For example, a decision is made at the board level, and the executive’s priorities change, but you are not informed of this decision. Anticipating that this could occur, you need to make periodic reports while your project is underway.

Hopefully, in the case of a PMO, the processes are already in place for a regular reporting structure so you should never be able to stray too far off course. But that’s not a given as many PMOs are floundering or have vague or inefficient processes in place. It’s the director or executive’s responsibility to draw your attention to a wrong direction, but this may occur only if you make the effort to reaffirm the way you are executing the assignment.

Defining Risk Management – Part 3: Risk Identification

Ok, so I decided to make the two-parter into a six-part series. I’ve received emails and comments on the first two parts and decided that I couldn’t end it until we dove further into defining risk identification, quantification, response, and control. In this entry from the book “The Project Management Question and Answer Book”, we’ll look further into Risk Identification.

What is risk identification?

The first step in risk management is identifying the risks that we will see in our project. These are the things that threaten to stop us from delivering what we have promised on the schedule we promised for the budget we promised. If we were completely certain about everything in the project and how it was going to turn out, we would not have to worry about risk management. From this lack of knowledge of how the project is going to unfold come the problems that we will have to deal with. These are the risks we want to identify. Every practical means must be used to discover the risks that are associated with the project. Meetings must be held throughout the project to discover new risks that have appeared and to dismiss risks that can no longer take place.

All of the assumptions that have been made to date on the project are potential risks as well and should be listed among the other risks identified.

The first thing we must do in risk identification is recognize the areas of the project where the risks can occur. This means that we will have to investigate the following areas:

• Scope. We must look at the work of the project. The work breakdown structure (WBS) will be useful here. The project scope must be clearly defined in terms of both the deliverables and the work that must be done to deliver them. Errors and omissions on the part of the project team and the stakeholders must be minimized. As always, the WBS will be very helpful in doing this.

• Time. Estimates for the duration of the project and the duration of the project tasks must be done accurately and reliably. The sequence of work must be identified, and the interrelationships between the tasks must be clearly defined.

• Cost. Estimates for tasks must be done accurately and reliably. All associated costs must be considered and reported accurately. Life cycle costs should be considered as well as maintenance, warranty, inflation, and any other costs.

• Customer Expectations. Estimates of project success must be considered in terms of customer needs and desires. The ability of the project to be scaled up or manufactured in different quantities or for different uses and sizes must also be considered.

• Resources. This involves the quantity, quality, and availability of the resources that will be needed for the project. Skills must be defined in the roles that will be necessary for the project.

• Organization. This is the ability to interface with the stakeholder’s organization in terms of communications and knowledge.

Many people both inside and outside the project will be necessary for risk identification. This includes input not only from the project team and all of the stakeholders but also from project managers who have managed this type of project before and even consultants who have special expertise about certain kinds of risks. It may be necessary to organize the types of risks into categories so that separate teams of people can be brought together more efficiently.

Many of the risks that will affect the project are risks that have happened in one form or another on other projects of this type. Utilizing the information available in the previous project’s lessons-learned documents will be very helpful in identifying risks for this project. An organized review of past projects should be done as part of the risk identification process.

Since much of the risk identification process will involve large numbers of people, formal group dynamics techniques should be used.

Brainstorming Technique. Most people are familiar with this process, and many have had disappointing results. In brainstorming a facilitator briefs the meeting attendees and asks the participants of the meeting to name risks that they think could occur in the project. The facilitator encourages the participants to name any risk they can think of, even ones that seem silly, and makes a list of the risks on a board or flip chart. What happens in brainstorming is that the ideas of one person generate new ideas from another person, and a kind of chain reaction takes place, producing the identification of many ideas about risk.

There are some problems with brainstorming that will affect the success you have with the technique. The main problem is that unless you have an excellent facilitator, there will be minimum participation from the attendees and few risks will be identified. This problem is even worse when there is a large difference in the status of the individuals attending. A person who is the supervisor of some of the participants may intimidate them or dominate the meeting.

Delphi Technique. This technique of group dynamics eliminates the problem of dominance, shyness, or intimidation that sometimes occurs in brainstorming meetings. In the Delphi technique the participants are anonymous to each other. This technique can be conducted with Internet messaging or even by e-mail and has the advantage that people can participate from many different locations.

In this technique the facilitator asks for input from the participants. He takes their ideas and consolidates them into a list that is sent to each participant. The participants then add ideas to those already listed. This circulation of the lists continues until no additional ideas are generated.

The Delphi technique creates a lot of work for the facilitator. All ideas have to be listed by the facilitator, who also usually has to telephone many of the participants in order to get them to participate in each round. The overall time to do the Delphi technique can be weeks depending on how dedicated the participants are.

Nominal Group Technique. This is another type of meeting technique. In nominal group the participants are known to one another as in brainstorming, but the ideas are submitted to the facilitator as written lists. This makes the ideas, if not the participants, anonymous. The facilitator lists the ideas on a flip chart or a board, and the participants add more ideas in another round of written lists until no additional ideas are added.

This technique reduces any status concerns or intimidation that might be present in a brainstorming session but does not eliminate it entirely. There is more work for the facilitator, but the nominal group method can be done in a single meeting, and participation improves over brainstorming even if some enthusiasm may be lost.

Expert Interviews. There might be experts available either inside or outside the company for a new project and a new kind of business. Expert interviews must be handled with care. If the project team is not prepared for the expert interview, much time can be wasted with the expert simply telling stories about his or her past exploits. An effort should be made to develop a list of questions for the expert.

Ishikawa or Fishbone Diagrams. Fishbone diagrams or cause-andeffect diagrams, also called Ishikawa diagrams after their founder, Kaoru Ishikawa, a Japanese quality engineer, are useful in identifying risks.

Defining Risk Management – Part 2

In Part 1 of this series, we looked at the general definition of Risk Management. In Part 2, we dive into the four steps in Risk Management and define each step. This is another excerpt from Michael Newell and Marina Grashina’s book entitled “The Project Management Question and Answer Book.”

What are the basic steps in risk management?

There are usually four steps considered in managing any risk. This will vary from author to author, so we will stick with the Project Management Institute’s Guide to the Project Management Body of Knowledge. The PMBOK lists the steps in the risk process as follows:

• Risk identification
• Risk quantification
• Risk response
• Risk control

Risk Identification

Risk identification is the process of identifying the threats and opportunities that could occur during the life of the project along with their associated uncertainties. The life of the project means the complete life cycle of the project, not just the time the project team is in place, the time until the final acceptance by the customer, or even the end of the warranty period. Risks should be considered through the useful life of the product or service that we are providing by doing this project. The risk of corrosion causing a catastrophic product failure during the useful life of a product that we have designed and built should be considered, and corrective action should be taken in accordance with the seriousness of the threat. Risks can be identified in a large number of ways, and all of the productive and economical ways should be employed.

Risk Quantification

Risk quantification is the process of evaluating the risk as a potential threat or opportunity. We are mainly concerned about two items: risk probability and risk impact. Risk probability tells us the likelihood that the risk will take place, and risk impact is the measure of how much pain or happiness will result if it does take place. Risks that have very high impacts with very low probabilities and risks that have very low impacts with high probabilities are usually of little concern, so we need to consider the combination of these two items before considering how important a risk is. The combination of impact and probability is called severity.

We do not need to worry too much about the risk of a hurricane impacting our construction of an apartment building if the project is taking place in Moscow. Hurricanes seldom occur there so there is a very low probability—even though the impact of a category five hurricane on Moscow would probably be quite significant. We may want to worry about the risk of heavy snowfall, however, which does occur frequently.

We also do not need to worry too much about the risk that one of the construction workers on the project will call in sick one day during the project. Although the probability is very high that this will occur more than once in the life of the project, we are able to anticipate this problem and the impact is relatively small even for skilled workers.

What we do need to concern ourselves about are the risks that have a relatively high impact and a relatively high probability of occurring.

Risk Response

Risk response is the process of doing something about the risk. It is how we respond to risks. In this process we address the best approaches to dealing with a risk that has a high enough severity that consequences of the risk cannot be accepted.

Responding to a risk includes ignoring the risk, letting it happen, and worrying about the consequences at the time. It also includes doing something about the risk before it happens. This might be putting together a work-around plan that can be quickly implemented when the risk occurs. It might include subcontracting the responsibility of the risk to an outside vendor or even an insurance company, or it might include avoiding the risk altogether.

Risk Control

Risk control is the process of controlling the risks. This involves keeping track of the risks that have occurred and can no longer occur, the risks that can still occur, and changes in the probability and impact of such risks. Generally, a reporting system is maintained so that the current picture of the risks is known.