I was trying to determine the return on investment (ROI) on a project recently and got hopelessly stuck—and I’m running the project. None of my developers were able to help either. You may find yourself in a similar bind when upper management requires an ROI figure before giving your project the green light. The task may seem difficult, but don’t give up yet.

ROI offers tremendous leverage and benefits in establishing the business case to justify technology initiatives. However, it is just one of several financial measurement tools that can be used to support an investment decision. For some IT projects, it is nearly impossible to express the benefit in numbers. However, the return can be significant, albeit of a nonfinancial nature (e.g., competitive advantage, product differentiation, customer service). Executives today are therefore deeply interested in ROI. In the majority of cases, the returns will be substantial—if the project is deployed correctly.

The first step in justifying the value of IT is to perform an ROI analysis of planned projects. You must evaluate projects based on costs, savings, strategic benefits, and risks in order to determine the most advantageous initiatives for the enterprise. Executives want to know which projects will contribute the most to the strategic and tactical business goals.

I recently met with a group of fellow project managers to discuss IT ROI. The discussion was interesting in that the project managers I interviewed could tell me how much they spent on their technology initiatives, but very few could actually say what that investment returned to the enterprise.

IT projects are inherently risky, and many fail to deliver on stated business objectives. Every organization has limited resources and more to do than the budget will allow. Already squeezed on their spending allocation, executives are typically left with a meager 10 percent of their IT budget for innovation—once operations, maintenance, upgrades, and migrations are paid for. So projects that fail to deliver value are a major source of contention within organizations. That is why so much emphasis is placed on high-quality project management and why project managers really need to pay closer attention to ROI.

In fact, leading industry researchers are saying:

  • 79 percent of companies now require ROI analysis to be performed on IT investments (Ernst & Young, 2002).
  • 60 percent of all technology spending is controlled by business or functional managers and 40 percent by IT organizations (Gartner, 2002).

Project managers and vendors responsible for enterprise projects say that they’re getting better at establishing organizational goals for projects and avoiding the scope creep that is so common in most software/hardware implementations. Their projects actually delivered expected ROI numbers, such as increased revenue and lower costs.

The financial people are the ones most interested in ROI. They go by various titles, such as CFO, financial accountant, or project manager. Regardless of title, they’ll examine project expenses and trends to determine whether it makes financial sense to proceed or simply cancel a project. If you’re managing a team of developers writing 30,000 lines of code on a specific project that doesn’t justify a solid return, your CFO may cancel any financial backing. A case in point is when the economy slowed down, one of the first casualties were projects with poor returns. Had those projects shown a positive ROI, I’m confident they would have survived. Unfortunately, as I’ve experienced myself, the majority of executives and project managers cite that they and/or their teams do not have the tools, training, or facilities to communicate the ROI and value of IT effectively. Yet, it’s that very discipline that will hold the project manager to account for and deliver on expectations. Understanding and respecting the ROI of IT projects will keep you honest.

Reasons for determining your ROI
Here are leading ROI advantages:

  • It’s a great selling technique for senior executives.
  • It allows you to set investment screening thresholds (e.g., considering only projects that deliver ROI of at least 190 percent).
  • It enforces an understanding of the top/bottom-line business impact of the investment, since it is impossible to complete an ROI analysis without understanding the potential impact on cost and revenue generation.
  • It facilitates investment prioritization by making a project-to-project comparison between investment options, letting stakeholders focus on the intangible benefits separately.
  • It brings discipline on the part of vendors and decision makers to support business impact claims by taking a more quantifiable approach to business justification.
  • Lastly, it enforces accountability on the part of the project executive for the success or failure of the project.

Hitting home with ROI
We’ve established that ROI is a measurement used to evaluate (IT) initiatives in terms of financial value to an organization and should be used to help justify those same initiatives. But it’s important to note that the concept of ROI and the measurement of ROI vary from company to company and from executive to executive. This is because there are different criteria by which to measure ROI, and there are many ways to quantify it. In its simplest form, though, ROI is the ratio of present value of expected benefits over the present value of expected costs. Therefore:


You may say, “Hold it. Some IT investments are nearly impossible to quantify.” I agree, but there’s always a way. A typical example is a business intelligence (BI) project. Even intangible benefits can be quantified with some creativity, and it is important to find a way to do this. Again, the financial person on your project can help.

Going back to projects that can be quantified, a basic rule of thumb is that projects with an ROI of less than 100 percent should not be undertaken unless there are compelling reasons to do so and strong executive sponsorship for the project. Anything over 100 percent has a better chance of passing the CFO’s scrutiny. Also, an important point to consider is the project’s expected payback. When the expected benefit exceeds expected costs, and that benefit is expected to be realized within the first year of the project implementation, the more likely the project is to proceed.


The best way enterprises can improve their ROI is by not inflating benefit expectations.

During the development phase, there may not be any measurable benefits. However, if a project goes live earlier, it stands to reason that project costs are reduced and revenue is increased. However, project managers should also understand that simply “crashing” or reducing the development phase by adding more resources (i.e., developers) will not bring about a better ROI, because more resources will add to the investment. So, you should carefully analyze the cost/benefit with the ROI expert on your team.

Figure A illustrates the concept of ROI within a project environment. It shows how project managers work with an ROI database and determine the ROI prior to the start of a project. The project review team documents the projected costs, potential savings, and risks. Make sure that someone who has a good financial background assists with the accuracy and logic of the ROI calculation. The results are then finalized and submitted to the executive team for approval and a go/no-go decision. If the project is of strategic value, the project manager may present such findings to the executive team.

Figure A
ROI in a project environment

Here are the steps you need to take for projects that fall into the (1) ERP, (2) CRM, (3) wireless, (4) legacy systems upgrade, (5) managed services, or (6) outsourcing categories:

Step 1: Determine the full scope of your project and baseline it.

Step 2: Estimate the resource costs to be used on the project.

Step 3: Use an ROI template/cost accountant to assist with the accuracy of the calculation.

Step 4: Submit to the executive team for review.

Factors affecting ROI
Since ROI may not factor in all risk or intangible rewards, it is prudent to list some of those risks and intangibles that may impact an IT project as a separate item on your document. Here are examples of factors that impact any ROI:

  • Lack of resources—Developers or testers may not be available or may not have the proper skill sets, requiring additional funding from the company.
  • Dissatisfied client—The client or users may be dissatisfied with the IT solution you delivered and reject it until it’s corrected. You may need to add code, burning up more time, testing, and money. Or, the solution may not be compatible with current or future operating systems, platforms, or other applications.
  • Unsatisfactory executive commitment—The executive team may not be fully committed to the project (e.g., dissatisfaction with the proposed project budget).
  • Vendor delays—Sometimes, vendors may be unable to deliver hardware or software when you need it, impacting your release date and potential revenue.

Understanding ROI will help you sell and manage your projects better from a financial perspective. In the future, project managers will likely place a greater priority on determining the ROI of a project. Available ROI calculators are somewhat fuzzy and difficult to pin down. Project managers should strive to understand ROI calculations. If you cannot get suitable training, get a financial person on your team to analyze ROI for you. Project organizations, boutique firms, educational institutions, and presenters should also begin addressing ROI prior to each project start. ValueIT ProjectROI is one commercial tool that I’ve found useful for calculating and assessing the ROI for any new project or proposal, thereby allowing you to align your IT budget accordingly. But that comes at a price. There are also free ROI tools available online.

How’s your ROI?

How do you calculate ROI on IT projects? Do you find Jason’s tips helpful? Do you have questions about calculating ROI? Post your questions or comments to the discussion board below.