Determining project ROI is difficult because:
- Many ideas are half baked
- No one defined what they meant by project ROI
- The requestor expects the PMO to come up with the business case for their project
Trying to develop ROI for projects without input and guidance from your leadership team and finance department is a sure-fire way to fail.
Our Advice
Critical Insight
Financial analysis is not the business case, but it makes your business case defensible. The outputs of various calculations are critical to standardize a business case process. However, finance is part science and part art. The business case should transparently represent the assumptions built into the analysis and should overtly explain what those numbers mean, and what the implications of the numbers are, to the audience reviewing the documentation.
Impact and Result
- Collaborate to define the necessary KPIs and calculations for the business case standard.
- Have a clear and agreed upon RACI for the business case process.
- Determine when it makes sense to invest the resource time and money to develop a comprehensive business case.
Member Testimonials
After each Info-Tech experience, we ask our members to quantify the real-time savings, monetary impact, and project improvements our research helped them achieve. See our top member experiences for this blueprint and what our clients have to say.
9.0/10
Overall Impact
20
Average Days Saved
Client
Experience
Impact
$ Saved
Days Saved
Correctional Service of Canada
Guided Implementation
9/10
N/A
20
Over all, the experience was very good. I really appreciate the involvement and the expertise of the advisor.
Build a Comprehensive Business Case
Help decision makers understand the ROI for large, complex projects using cash flow projections.
Analyst Perspective
ROI is overused and ill-defined business jargon.
“The number of organizations claiming to use return on investment (ROI) as a criteria in their project portfolio prioritization structure is high. However, the number of organizations calculating ROI for the projects in their portfolio is very low.
I’m not surprised by the discrepancy between this aspiration and actuality, but allowing ROI to be a heavily weighted criteria, to steer the direction of the portfolio, without having any defensible business cases, is detrimental to organizational effectiveness.
The lack of standardization, documentation, and financial analysis, facilitates an environment where business leaders make decisions blindly and by gut feel. And for every underperforming, poorly defined, and disappointing project that gets approved, the opportunity cost grows.
The objections to a formal business case process typically involve responses like: I don’t know how to create a business case, or I don’t have the right data, or it takes too much time.
So how do we solve this conundrum? Well to address the first concern, it’s time to create a template. It’s both inefficient and ineffective to start from scratch every time. A template allows decision makers to understand what they’re looking at and helps requestors understand what information they should be looking for when building their business case.
To find the right data, you may need guidance from outside your department, specifically from finance or procurement. Collaboration is key to creating a thoughtful and defensible document.
To avoid taking too much time, use the business case process sparingly. Not every project needs a business case. There is a cost to building the case itself. Use proper project classification to build business cases for requests that have enough risk, complexity, and magnitude to warrant the additional cost.”
Teodora Siman
|
Executive Summary
Your Challenge
Determining project ROI is difficult because:
Trying to develop ROI for projects without input and guidance from your leadership team and finance is a sure-fire way to fail |
Common Obstacles
When you’ve tried implementing a business case process in the past:
Making business cases a universal requirement for projects has diluted their impact. |
Info-Tech’s Approach
Build a better business case:
|
Info-Tech Insight: Financial analysis is not the business case, but it makes your business case defensible.
EXECUTIVE BRIEF
Place the burden of proof on the project
Large, complex, risky endeavors require scrutiny. Dream big, but balance aspirations with feasibility. Business case analysis must be defensible and thorough because there is always an opportunity cost to approving the wrong projects.
Insight summary
Overarching Blueprint Insight: Financial analysis is not the business case, but it makes your business case defensible.
The outputs of various calculations are critical to standardize a business case process. However, finance is part science and part art. The business case should transparently represent the assumptions built into the analysis and should overtly explain what those numbers mean, and what the implications of the numbers are, to the audience reviewing the documentation.
Phase 1 Insight: Lack of fungibility between business cases misrepresents project value.
When decision makers can’t compare across a standard format, the risk of malinvestment increases.
Clearly define ROI calculations and other business case KPIs to uphold the integrity of your business case process. It is insufficient to state that ROI should be provided for the business case.
Should ROI be represented as a percentage, pay-back period, or dollar amount? Should it include TCO or just project costs? How is the forecast period determined? Does time zero begin once the project is finished, or when the project is starting?
Slight variations in calculations can have a big impact on results. Collaborate to define the necessary KPIs and calculations for the business case standard.
Phase 2 Insight: A process without governance will dissolve or diverge and become unrecognizable before it is adopted.
Have a clear and agreed upon RACI for the business case process.
Failing to assign responsibility and accountability for creation, validation, and approval of the business case will result in either chaos or complete abandonment of the process.
Be mindful of the expertise and authority each role must have to effectively govern the process.
Phase 3 Insight: A comprehensive business case may not apply to every project.
Determine when it makes sense to invest the time and money to develop a comprehensive business case. Where the risk is low, the project is simple, and the work effort is minimal, there is no sense in requiring a comprehensive business case.
The only thing that applying a one-size-fits-all approach to the business case process will do, is ensure exceptions are made regularly and the standard process is not followed.
Overprescribing business cases dilutes the gravity of overstating earnings and understating costs.
What is a business case?
Defined by the Oxford English Dictionary as:
“A justification for a proposed project or undertaking on the basis of its expected commercial benefit.”
Business cases should:
Many organizations forget to consider the ongoing cost of maintaining a new product or service. These costs can truly make or break the business case. A TCO calculation will give a more honest view into the potential upside of the project, while providing forethought to the transition to operations. |
While 96% of respondents said they develop business cases for most projects involving IT… (Source: APM, 2017) …only 31% of respondents said they were satisfied with the effectiveness of the business case process (Source: APM, 2017) |
Why are business cases important?
Neglecting to build business cases for large projects means:
|
70% of respondents said they place a high priority on a culture that centers on delivering customer value. (Source: PMI, 2020) Without a point-in-time analysis and a forecast of the business outcomes it becomes difficult to understand if project benefits are leading, lagging, or even realized at all. 38% of respondents believed their current approach led them to frequently overstate the benefits to obtain funding. (Source: MIS Quarterly Executive, 2008) If a business case process is just a formality to secure funding and it neglects post-project reporting to obtain actual results, the structure is incentivizing a behavior to inflate proposed business benefits. |
Market Overview in Historical Context
Every project needs a business case. Sort of.
“It’s often said that every project needs a business case. And for a lot of organizations, the entire intake scoring paradigm is based around return on investment (ROI).
But the practical reality is that very few IT projects are supported by a business case that would be recognized by Finance as being legitimately based on an appropriately comprehensive cash flow projection with revenue or income in the bottom half of the P&L.
For context, the early era of corporate information technology involved business cases with a serious commitment to costs and benefits. Misrepresentation of those financial drivers was seen as a grave injustice to the shareholder. Sure, the inability to forecast or constrain cost was legendary and the attainment of benefits was dubious, but the deliberate misrepresentation of the business case was unacceptable.
The ‘.com’ era of the late nineties changed everything. As business units and IT competed for scarce resources and executive attention, it became acceptable to inflate benefits forecasting with hockey stick hypergrowth in year three or four. It was probably impossible to get your project funded without a blatant lie, and a completely fabricated business case was increasingly seen as charming in an ‘aw shucks’ sort of way. Junior IT executives would shrug with a wry grin and say, ‘that’s how you play the game’ as they claimed multi-trillion dollar returns on their pet projects.
For the next 10 or 15 years, the business case became imperative but aspirational. The authors were rarely held to account for an actual cash flow projection, and ROI payback periods went largely unchallenged. The actual contribution to intake assessment was weak.
We are only now seeing the resurgence of business case legitimacy. As Finance reengages on the auditability of business cases, IT may have to relearn the age-old discipline of cash flow projection.”
Barry Cousins
PPM Practice Lead
Info-Tech Research Group
How can Info-Tech’s approach help?
Benefits may quickly be overshadowed by the project and ongoing maintenance costs.
|
The Info-Tech difference:
|
Info-Tech’s methodology for building a robust business case
Speak the Language of the Business | Customize your Business Case Framework and Governance | Leverage the Info-Tech Tools to Develop Your Comprehensive Business Case | |
Phase Steps |
|
|
|
Phase Outcomes |
|
|
|
Blueprint deliverables
Each step of this blueprint is accompanied by supporting deliverables to help you accomplish your goals:
Key deliverable:
Business Case Executive Presentation DeckMake your analysis consumable and meaningful with the Business Case Executive Presentation deck.
|
Business Case Classification MatrixInfo-Tech’s Business Case Classification Matrix can be used to develop a rubric that can assess the requirement to produce a business case for a potential project. This approach will help you create a standard and remove the subjectivity often involved when deciding whether a project request warrants the effort to go through business case development during project intake. |
Comprehensive Business Case Analysis ToolInfo-Tech’s Comprehensive Business Case Analysis Tool can be used to help develop steering-committee-ready deliverables for your proposed projects. Features include:
|
Info-Tech offers various levels of support to best suit your needs
DIY Toolkit |
Guided Implementation |
Workshop |
Consulting |
"Our team has already made this critical project a priority, and we have the time and capability, but some guidance along the way would be helpful." | "Our team knows that we need to fix a process, but we need assistance to determine where to focus. Some check-ins along the way would help keep us on track." | "We need to hit the ground running and get this project kicked off immediately. Our team has the ability to take this over once we get a framework and strategy in place." | "Our team does not have the time or the knowledge to take this project on. We need assistance through the entirety of this project." |
Diagnostics and consistent frameworks used throughout all four options
Guided Implementation
A Guided Implementation (GI) is a series of calls with an Info-Tech analyst to help implement our best practices in your organization.
A typical GI is between four to five calls over the course of two to three months.
What does a typical GI on this topic look like?
Phase 1 |
Phase 2 |
Phase 3 |
Call #1: : Scope requirements, objectives, and your specific challenges.
Call #2: Review the language of the business and unpack the hype around ROI. |
Call #3: Customize your business case framework and governance. | Call #4: Learn to use the Comprehensive Business Case Analysis Tool.
Call #5: Craft your Executive Business Case Presentation. |
Workshop Overview
Contact your account representative for more information.
workshops@infotech.com1-888-670-8889
Day 1 | Day 2 | Day 3 | Day 4 | Day 5 | |
Activities |
Define the current state |
Develop business case framework and governance |
Pilot the Comprehensive Business Case Analysis Tool |
Develop an Executive Business Case Presentation |
Next steps and wrap-up (offsite) |
1.1 Review the business context. 1.2 Identify the current pain points around business case development. 1.3 Become familiar with business and finance terminology. 1.4 Understand the key elements of a business case. |
2.1 Develop your Business Case Classification Matrix. 2.2 Determine responsibility and accountability for the business case as well as who should be consulted and informed. 2.3 Draft a workflow to detail the business case development and approval process. |
3.1 Brainstorm a candidate to pilot. 3.2 Set-up the comprehensive business case analysis tool. 3.2 Populate the project costs. 3.3 Populate the ongoing maintenance costs. 3.4 Review the results of the analysis. |
4.1 Determine the appropriate audience and forum for the business case presentation. 4.2 Craft a presentation using the Executive Business Case Presentation template and make the final recommendation. 4.3 Develop a roadmap to operationalize the process for business case development. |
5.1 Complete in-progress deliverables from the previous four days. 5.2 Set-up review time for workshop deliverables and to discuss next steps. |
|
Deliverables |
|
|
|
|
|
Phase 1
Speak the language of the business
Phase 1
1.1 Understand the terms and context to build a business case |
Phase 2
2.1 Determine your business case levels 2.2 Define the business case governance 2.3 Create the business case workflow |
Phase 3
3.1 Learn to use the Comprehensive business case Analysis Tool 3.2 Craft your Executive Business Case Presentation |
This phase will walk you through the following activities:
- 1.Defining ROI
- 1. Considerations when calculating ROI
- 1.3 Understanding business benefits
This phase involves the following participants:
- Portfolio manager
- PMO analyst
- Business analyst
- Business relationship manager
- Business unit representatives
Step 1.1
Understand the terms and context to build a business case
Activities
- Define ROI and variables
- Review business case terminology
- Understand business benefits
This step involves the following participants:
- Portfolio manager
- PMO analyst
- Business analyst
- Business relationship manager
- Business unit representatives
Outcomes of this step
- Aligned IT and Business stakeholders on business case terms
- Documented goals of the business case process
Unpack the Hype Around Return on Investment (ROI)
The fascination with requiring project ROI is common among our member base. However, it’s not typically the PMO requiring it. Most often it’s the CIO or CFO.
Usually, it’s made to sound like ROI should provide an apples-to-apples comparison among various projects. It implies that ROI will allow steering committees or governance groups to make the right decisions about what projects should be approved based on their value proposition.
But how true is that statement? At a surface level, the definition of ROI is quite simple. Typically expressed as a percentage, ROI is calculated as the following:
|
Let’s look at a simple example:
An organization is looking to purchase a new CRM software that is expected to generate $350,000. The cost of the new system is $250,000. Following the formula, the ROI would be:
ROI = 40% Case closed, right? This is perhaps the simplest way to look at an investment. However, there are many things we haven’t considered… |
The many variables affecting ROI
Context is important. The organization needs to have a standard way of calculating ROI, and those determining, aiding, or evaluating the business case should be familiar with the necessary components.
Accounting for the Time Value of Money:
|
Accounting for Opportunity Cost:
|
Accounting for Risk and Sensitivity:
|
Accounting for Estimated Useful Life of the Asset:
|
Apply Estimated Useful Life (EUL) to get the proper timeline for your business case
Estimated Useful Life is applied to capital expenditures.
You’ve probably heard the term CapEx thrown around the organization a fair bit.
CapEx or Capital expenditures are typically part of large projects and require a significant investment. Capitalization thresholds vary from organization to organization, but the general idea is that capital expenditures will generate revenue for more than one year. Capital expenditures are recorded as assets and then depreciated over their estimated useful life. Useful life refers to the number of years the asset is likely to remain in service. So why, despite different useful lives, do some organizations insist on analyzing the same time horizon for their business cases? Doing so neglects projects that perhaps have massive benefits beyond the three-year mark. It also fails to account for delayed benefits across the life of an asset. For example, delayed benefits can be the result of the steep learning curve that impedes adoption and delays the realization of benefits. |
Time Value of Money: A dollar today is now worth more than a dollar tomorrow
Time Value of Money is an important principle of finance. In simple terms, due to the combination of inflation and opportunity cost, a dollar today is more valuable than a dollar tomorrow.
If an organization has $1 million dollars today and let that money sit in a bank account for five years, they will likely be able to buy less in five years with that money than they could today (Recognizing the modern era of Central Bank interest rate policy). Their purchasing power has gone down because costs have gone up due to inflation. Hence, a dollar today, is worth more than a dollar tomorrow.
If an organization could increase earnings by $250,000 in two years from implementing system A, and $550,000 in two years from implementing system B, their opportunity cost for choosing system A is $300,000. Because of multiple opportunities and their potential pay-off, again a dollar today is worth more than a dollar tomorrow. |
Opportunity Cost Defined: “The potential benefit foregone from not following the financially optimal course of action.” (Berman, Knight, Case, 2013) |