business case info project portflio decision makers

Expert Reference Series of White Papers

1-800-COURSES www.globalknowledge.com

The Business Case: Information for Project Portfolio Decision Makers

Copyright ©2010 Global Knowledge Training LLC. All rights reserved. 2

The Business Case: Information for Project Portfolio Decision MakersJames Swanson, Global Knowledge Instructor, PMP®

IntroductionIncreasing numbers of enterprises, whether commercial, non-profit, or from the public sector, are incorporating project portfolio management in their strategic and tactical planning. Although the presence of the word “proj-ect” implies this is a project management topic, the portfolio is really about business decisions to meet business needs. The portfolio is analogous to a personal financial portfolio, which is intended to meet personal financial needs consistent with the resources and preferences of those individuals. And just as individuals use financial reports and analyses to consider various investment options, the enterprise uses an analysis called the Business Case to evaluate various project proposals for inclusion in the project portfolio. This paper discusses the typical contents of a business case and how that information is used by the portfolio decision makers.

Project Portfolio ManagementA project portfolio is a collection of investments in the form of projects or programs that an enterprise has select-ed to meet their business needs. An individual project is a tactical endeavor that creates a change in the environ-ment (the project product) within a defined time period. The project manager manages that endeavor so that the major constraints of costs, time, and scope stay within planned boundaries; this is the project life cycle. However, portfolio management includes the larger picture: the product life cycle. In order to truly measure the value of the project as an investment the post-project, operational costs and project product benefits must be factored into the equation. Project portfolio management also includes the processes to evaluate and select potential projects for the portfolio. The following diagram shows the relationship between the project and product life cycles.


The project life cycle is typically managed through a Project Management Office (PMO). The actual operational charter of this organization can vary considerably, but it usually manages the processes and resources related directly to delivering the project. Sometimes the PMO can be given extended responsibilities related to project portfolio management, but this is not typical. Enterprises that have implemented portfolio management will often create an organization somewhere between the PMO and the executive level. This group may be called a steering committee, portfolio governance, or a Project Portfolio Management Organization (PPMO). This group is a cross-functional, “roll-up-your-sleeves” group that must select and prioritize projects for the portfolio and manage the integrated portfolio for changes. This group makes portfolio recommendations to higher manage-ment for final decisions. The discussion above implies portfolio management is at the enterprise level, but it actually can occur at any level in the enterprise.

Project portfolio management is analogous in many ways to the financial portfolio for an individual. The analo-gies between a financial portfolio and a project portfolio are described in the following table.

The Business CaseEach potential investment in a portfolio must be evaluated for meeting the criteria important to the individual or enterprise. How is this done for individuals? They consider various analyses for each potential investment. An investor can use services such as Morningstar, Moody’s Investor Services, Standard and Poors, or Dun and Bradstreet to evaluate stocks, bonds, mutual funds, and commercial and government enterprises’ information and health. For project portfolio management we use the Business Case.


The business case is an analysis of a proposal for inclusion in the portfolio. Business cases come in the form of written reports and are often summarized in a presentation to the PPMO. The business case should contain the information the decision makers will use to compare proposals and evaluate them for inclusion in the portfolio. Some common content of a business case will be discussed shortly.

Proposals have sponsors, but the sponsor will rarely develop the business case. The author of the business case is the Business Analyst (BA) or someone wearing the hat of a BA. The project manager will get involved once the project is selected and, although there are project managers who have developed business cases, in doing so they are wearing the BA hat. The BA role is still evolving; the most accepted source for the BA discipline is described by the International Institute of Business Analysis (IIBA) in their Business Analysis Body of Knowledge (BABOK). As described in the BABOK the development of a Business Case is part of the Enterprise Analysis Knowledge Area.

Business Case Contents There is no universal business case template. An effective way to consider what should be contained in a busi-ness case is to think like the decision makers. Put yourself in their shoes and imagine you were being held ac-countable for selecting the best investments for your enterprise. What would you want to see in business cases that would lead you to those decisions? The information would probably include the following information.

• Executive Summary

• Why consider this project?

• What does this project deliver?

• The financial case: How much will it cost? What are the benefits? How does this project compare to other projects?

• What is the time frame?

• What are the risks?

• What is the forecasted resource usage?

• What other alternatives were considered?

Contents: Executive SummaryThe executive summary is the leading section in a business case, but the last part written. It contains the concise summary of the business case main points which are elaborated in the other sections.

Contents: Why consider this project?There must be a compelling reason for the project. Some potential reasons include:

• Broken processes• Inefficiencies that need to be corrected• Market opportunities• Product updates• Infrastructure additions or updates

• Regulatory mandates


Except for mandated projects all projects are optional and must compete for limited funds. Projects exist to meet business needs and the business case must plainly state those business needs. In addition, data which supports this statement of need can be presented, often in an appendix. This data, for example, could include metrics that reveal broken or inefficient processes, or market analyses supporting new or updated business lines or products.

In addition all projects must pass a certain test before they are selected for the portfolio. As compelling as the project appears, it does not belong in the portfolio if it cannot be aligned with the enterprise high-level business objectives. These objectives are the directives given by the business leaders to guide business decisions. These high-level objectives are usually hierarchical. An example hierarchy includes:

• Mission/vision statement – This is a succinct statement of purpose that can express ethical position, public image, target market, products or services, and growth expectations. Strategic objectives are cre-ated to support this mission.

• Strategic objectives – Strategic objectives express how the mission will be accomplished. They de-scribe how an enterprise wants to position itself or focus capabilities or resources. Tactical objectives are created to meet strategic objectives.

• Tactical objectives – Tactical objectives are specific measurable steps that create financial value. Most projects specifically address tactical objectives. Tactical objectives can also meet other tactical objectives.

Although not a business objective per se, an enterprise may have documented core values that also factor into the decision to select a project. A project is not likely to be selected if it contradicts the enterprise core values.

An example of a business objectives hierarchy is displayed below.

Mis s ion

T a ct ical ob jec tiv es

Strat e gic ob jec tiv es

Industr y leader

New sales Lower costs

Product qualit y

Defect reduction

Time t o market

Production costs

Service costs

Lean processes

Requisitio n processes

Fa cili ties costs

Component costs


Contents: What does this project deliver?Once the project business need is clearly stated and the project’s alignment with business objectives articulated, the next step is to describe what this project will deliver. The business case must effectively communicate what the decision makers will be getting for their investment. There are a number of ways to present this information, depending on the type of project. One simple approach for all types of projects is to describe the product scope (what the project will produce) and a brief summary of the project scope (the work to build the product, includ-ing a list of deliverables). A high-level Work Breakdown Structure (WBS) can help model the scope. If the project will create changes to the enterprise, a before-and-after description or a visual model can be very effective for communicating the differences.

Contents: The financial caseUltimately, the decision to select a project boils down to whether it makes financial sense, so it is no surprise that this is the most critical part of the business case. The financial case must be based on a thorough analysis of all project costs, operational and support costs over some period of time, and benefits that will be realized over some period of time. The business case can suffer, and the BA’s credibility can be damaged, if costs or benefits are missing, poorly calculated, or presented in a haphazard fashion.

The terms costs and benefits seem simple enough, but there is actually much confusion in their use. Enterprises spend money every day, which are obvious costs. The question for a proposed project is how will the costs be affected and how do we calculate the differences caused by the project. This may be easy for new business projects where additional costs are clear, but for projects that change the existing environment, it is not so easy. Most people understand benefits, but there can be confusion here also. A new product or product line can generate additional revenue. Those are obvious benefits. But cost savings or cost avoidance, which keeps money from flowing out, is a benefit and should be included in the benefits column.

So how can we avoid some of these confusions and present a clear financial picture? The following steps will help clarify the presentation.

1. Develop a financial model that describes the enterprise’s “Money in” and “Money out” transactions.

2. Create a cash flow statement of the “As Is” or “Business as Usual” environment.

3. Create a cash flow statement of the proposed environment.

4. Create an incremental cash flow statement by subtracting the “As Is” flow from the proposed flow, and create an incremental cash flow statement. The increments in this flow represent the costs and benefits of the proposed project

5. Apply financial metrics to the incremental data to compare one project to another.

These steps are elaborated below with sample cash flows.

1. Develop a financial model for the enterprise

The financial model describes the part of the enterprise environment that is affected by the proposed project. The model is one of the key components of the financial case, so it is critical to ensure all relevant financial fac-tors are included. This model describes:

• Current operational spending (money out): labor, operational costs, maintenance or support contracts, production costs, costs of sales, etc. To be effective, costs must be specific and supported by data.

• Current revenue (money in): For commercial enterprises this is sales revenue. For some non-profits, it may be revenues or donations.

• Other financial factors that have to be considered: The enterprise may have processes that produce errors or defects. These errors require additional labor or material to rectify. These expendi-tures should be part of this financial model

• Assumptions: Many of the entries in the cost model may be based on individual or series of as-sumptions. It is important that these are clearly stated and vetted with decision makers. For example, assumptions on the number and the costs of production errors may have to be based on some calcu-lations that factor in the assumptions.

• Time period: There must be agreement on how much time must be considered for evaluating the project costs and benefits. For example, an IT technology project may only have a 3-year product life cycle, while a building may require analysis spanning decades.

2. Create a cash flow statement of the “As Is” or “Business as Usual” environment

The model that was developed in step 1 is now used to describe the money-in and money-out cash flow of the current environment. The flow is typically developed in a spreadsheet that shows the detailed line items spread over the agreed to time period.

3. Create a cash flow statement of the proposed environment

Another cash flow statement is created to describe the environment represented by the proposed project. One big difference is quite evident. The project will have upfront costs that are the project costs. While many think of this as the investment costs, we cannot forget that there may be additional operational costs resulting from the project. This cash flow statement will include those costs in the cash flow. Project assumptions are critical for understanding this cash flow statement.

4. Create an Incremental Cash Flow Statement

The incremental cash flow statement is created by subtracting the as-is cash flow from the proposed cash flow. This highlights the positive and negative cash flows created by the proposal. These increments represent the costs and benefits from the project. For this to work properly cost savings/avoidances should be counted in the benefits section.

The following example is a simple demonstration on how this works. This is a manufacturing enterprise where currently 2000 units are sold yearly, but with a defect rate of 100 units. According to assumptions this project will create the following changes:

• An increase in sales of 100 units per year

• A decrease in labor costs per unit

• A 95% decrease in defects per year

• The project is estimated to cost $50,000 in year 0

• All costs and benefits are considered for the 3 years after project completion


The project will result in a benefits increment of $90,900 for an incremental cost of $62,000 over the 3 years after the project is complete. This data is now ready for the application of financial metrics.

The real challenge with the model and the data is to represent business factors and changes that are difficult to measure. Difficult to measure benefits can include factors such as customer or employee satisfaction or the value of brand recognition. This topic is outside the scope of this paper but the basic message is that there is usually a way to measure any benefit, even in financial terms. Remember that if the changes cannot be mea-sured in financial terms there is no way to compare the value of the project with another.


5. Apply Financial Metrics

Once you have the granular data from the cash flows, most financial metrics can be applied to the incremental cash flow data and then compared with other projects. The incremental changes represent the costs (negative values) and the benefits (positive values) of the project. The most common financial metric is return on invest-ment (ROI). However, this is just one choice and not the best. One trouble with ROI is that it does not figure in the time value of money. A future dollar as a cost or benefit is not the same dollar as today, due to inflation and the investment value of money. Some common metrics include:

ROI: Return on investment can be a confusing metric because there are a number of variations. The most com-mon formula in this context is:

Benefits – Costs

Costs

Benefit-Cost Ratio (B/C): Another related metric to ROI is the Benefit/Cost ratio. It is often discussed as a metric in selecting projects. But the B/C ratio can be directly calculated from the ROI:

ROI = (B – C)/C = B/C – C/C = (B/C) – 1


Payback Period: Payback period is a popular metric. It calculates the break-even point of the project. The value is expressed in years. Projects with lower payback periods are preferable. Also, larger payback values imply higher risks.

Net Present Value (NPV): The trouble with the metrics so far is that they do not factor time into the calcula-tions. The incremental cash flow statement shows net incremental changes for years 1-3 as $19,725 each. How-ever, these amounts are actually affected by the time-value of money. The year 3 amount is less than the year 2 value and year 2 is less than year 1. These values must be discounted so that they are converted into today’s dollars. The future values are discounted by applying a discount percentage rate, usually provided by the CFO. If the discount percentage is 5%, each future value is calculated in today’s dollars as follows:

Year 1: $19,725 / (1.05)

Year 2: $19,725 / (1.05)2

Year 3: $19,725 / (1.05)3

The sum of all these discounted values is the Net Present Value of the entire cash flow. Note that the incremen-tal changes in year 0 require no discounting. This value becomes an effective metric for comparing the relative value of one project with another. Higher NPV projects are considered more valuable than lower NPV projects.

Excel provides a function that can easily calculate NPV:

NPV = (discount interest rate, cell range of cash flow values)

Internal Rate of Return (IRR): IRR is a way to calculate the value of the project investment in terms of an interest rate. This calculation is a non-determinative calculation that, through trial and error, calculates the discount rate where the costs and benefits net to zero. The higher the IRR value, the better the project looks. Enterprises will often have hurdle values that the IRR must exceed before the project will be considered for the portfolio. The best way to calculate IRR is to use the Excel function:

IRR (cell range of cash flow values)

Note that IRR can only work if there is at least one negative cash flow value and at least one positive cash flow value.

The table below shows the various financial metrics using the data in the sample incremental cash flow statement.

Metric ValueROI (90,900 – 62,000) / 62,000 .47

B/C 90,900 / 62,000 1.47

Payback Payback 30,275 / 19,725 1.535 years 1.535 years

NPV @ 5% discount NPV (0.05, 19,725, 19,725, 19,725) - 30,275 $22,324.83

IRR IRR (-30,275, 19,725, 19,725, 19,725) 42.8%


Contents: What is the time frame?Timing can be critical especially if there are drop-dead dates in the schedule or there are windows of opportu-nity that may shut suddenly. The proposed project may also depend on other projects in the portfolio or those projects may be impacted by the proposed project. Stakeholders may need project schedule information so the proposed project can be folded into the overall portfolio.

Contents: What are the risks?Decision makers expect some form of risk analysis for the potential project. This initial analysis should include any risks that will impact the business. All risk analysis includes identifying specific risks, some form of qualita-tive or quantitative estimate of impacts and probabilities, and the response planned for that risk. Decision mak-ers are also interested in the risks if the project is not executed.

While these individual risks are important, the decision makers are usually interested in additional risk analysis. How much confidence do we have in the financial and schedule data? The financial data, in particular, may be based on a series of assumptions. Although reasonable, they still may change. We can factor in our individual risks and assumptions using a Monte Carlo analysis and a Sensitivity analysis.

Monte Carlo Analysis: A Monte Carlo analysis is a number-crunching technique that can factor in many variables and get a range of expected values for your target data. For example, a Monte Carlo analysis can take all your individual risks with their probabilities and impacts and see how those risks impact the schedule or financial outcome of the project. The results can display various confidence levels. For example, the results may show there is a 90% chance the project will finish in one year but a 30% chance of finishing in 6 months. If there were a drop dead-date in 5 months, this project may be a very risky venture. In the past, Monte Carlo analyses were beyond the means of most enterprises but an Excel plug-in can be acquired as a feasible alterna-tive for most.

Sensitivity Analysis: A sensitivity analysis is an analysis of factors that we use in our financial or schedule analysis. Specifically, it tries to identify the factors that, when changed, have the most impact on our results. For example, suppose the financial analysis used the price of oil to estimate future costs. What happens to the results if there are major changes to the price of oil? Combine that with a long payback period, and the value of the project may not look so favorable. Other factors may have little impact on the value; they would be consid-ered less sensitive.

Contents: What is the forecasted resource usage?One of the responsibilities of the portfolio steering committee is the prioritization of projects within the port-folio and reconciling the resource requirements of each project with the resource capacity of the organization. The business case, therefore, should contain some estimation of resources required and when they are required. With that information, the decision makers can decide if the project is feasible or how it can fit into the existing portfolio. This ability to forecast and manage resources is one of the weakest areas in portfolio management for most enterprises. In order for this to work well, the enterprise must have a good handle on the resource categories, their experience levels, their current and forecasted assignments, and a process to update that data. For the business case, the BA must present the resource requirements in a manner consistent with the enterprise resource management data.


Contents: What other alternatives were considered?Many enterprises require multiple solution alternatives. These may be presented as alternatives to the steering committee, or they may be considered and rejected by the BA and team who created the business case. If the steering committee expects to see multiple solutions, then the business case analysis must be repeated for each solution. Any solutions that are considered but not recommended should be described in this section. Reasons for rejection should be explained.

Presenting the Business Case InformationBusiness cases are typically detailed in documents, but the decision makers may expect a presentation. The doc-ument is typically divided into text and appendices. The text summarizes each of the sections described in this paper, but the supporting data is located in appendices. For example, the financial analysis text may describe the basic cost and benefit models, their assumptions, and overall findings, but the appendix would contain the de-tailed cash flow statements, along with any detailed explanations of calculations and assumptions. The presen-tation is usually high-level and may include a standardized set of slides that present the topics of most interest.

A wise BA will make sure that the information is vetted with various members of the committee. This vetting can help uncover potential objections to assumptions and the approach, as well as foster allies within the commit-tee. The presentation should not be the first time members of the committee see the business case information.

The Project Is Selected – What’s Next?Congratulations! The project has been selected, based on the business case analysis. But this is not the end of the story. The project has not even started. One of the characteristics of a project is that it is developed using progres-sive elaboration. This means that as the project matures, the project must be adjusted and re-planned. This also means the business case may need to be revisited and the original data re-validated. Are there new risks to the business? Are the costs and benefits still in line with the original analysis? Have windows of opportunity closed? Has the business changed directions and the project no longer aligns with the new objectives? A revisit of the business case may lead the portfolio management organization to cancel projects or rebalance the portfolio.

SummaryThe business case is a key element to making effective decisions for a project portfolio. The development of the business case is a business analyst responsibility. The business case should describe what the project is, articulate how it aligns with business objectives, present clear creditable data that justifies the financial case, document risks, forecast resource usage, and describe schedule or time requirements. With such data, decision makers are armed with the data that can justify adding a project to the project portfolio.

Learn MoreLearn more about how you can improve productivity, enhance efficiency, and sharpen your competitive edge. Check out the following Global Knowledge course(s):

Effective Business Cases

Building the Business Case

Applied Project Management (PM08)


For more information or to register, visit www.globalknowledge.com or call 1-800-COURSES to speak with a sales representative.

Our courses and enhanced, hands-on labs and exercises offer practical skills and tips that you can immediately put to use. Our expert instructors draw upon their experiences to help you understand key concepts and how to apply them to your specific work situation. Choose from our more than 1,200 courses, delivered through Class-rooms, e-Learning, and On-site sessions, to meet your IT and business training needs.

About the AuthorJim Swanson is a Certified Project Manager and Managing Principal for JR Swanson Project Services specializing in Project Management and Business Analysis consulting, coaching, mentoring, training, and course develop-ment. As an instructor for Global Knowledge, Jim has taught classes in IT Project Management, PMP exam preparation, Project Portfolio Management, Business Analysis Essentials, Business Process Analysis, and Require-ments Development and Management. Jim has developed Global Knowledge courses on requirements develop-ment and management, and developing effective business cases.

Previously Jim was a 25-year employee with Hewlett-Packard. With HP Jim had a wide-range of responsibili-ties including Development and Management of HP’s lease management systems, Customer account support, Escalation Engineer for HP Operating Systems and Network Products, and 15 years as a Project Manager for HP Trade Customers. Projects included Network infrastructure and Outsourcing Projects for the chemical, insurance, airline, retail, and auto industries. Jim was a Senior Project Manager with responsibilities for managing other project managers, developing project standards, and training in HP’s Project Management Methodology. Prior to his career at HP, Jim worked 6 years as a Geologist with the U.S. Geological Survey.

Jim has a B.S. degree in Geology from the College of William and Mary and an M.S. Degree in Computer Science from the University of Santa Clara. Jim is a member of the Project Management Institute and has maintained the Project Management Professional (PMP) Certification since 1996. He is an avid guitarist and woodworking hobbyist.

Suggested ReadingBrannock, James W., Business Case Analysis – Examples, Concepts and Techniques, STS Publications, 2004.

Breierova, Lucia and Choudhari, Mark, An Introduction to Sensitivity Analysis, Massachusetts Institute of Technology, 2001.

Flyvbjerg, Bent, From Nobel Prize to Project Management: Getting Risks Right, Project Management Journal, 2006.

International Institute of Business Analysis, A Guide to the Business Analysis Body of Knowledge, Release 2.0, www.theIIBA.org, 2009.

Levine, Harvey A., Project Portfolio Management, Jossey-Bass, 2005.

Microsoft, Introduction to Monte Carlo Simulation, Microsoft Online – Microsoft Office Excel, 2008.

Project Management Institute, Inc, A Guide to the Project Management Body of Knowledge – Fourth Edition, Newton Square, PA, 2009.

Reifer, Donald J., Making the Software Business Case – Improvement by the Numbers, Addison-Wesley, 2002.


Schmidt, Marty J., Business Case Essentials – A guide to Structure and Content, Solution Matrix, Ltd., 2007.

Schmidt, Marty J., The Business Case Guide, Solution Matrix, Ltd., 2007.

Schmidt, Marty J., Soft Benefits in a Hard Business Case – Legitimacy and Value for Difficult Benefits, Solution Matrix, Ltd., 2007.

Schmidt, Marty J., The IT Business Case – Keys to Accuracy and Credibility, Solution Matrix Ltd., 2007.
