My assumptions about working closely with business units to define the benefits of a proposed IT project were confirmed by the results of a recent CIO Insight survey of 370 IT executives.
This survey, which focused on how IT groups view, use, and calculate a project’s return on investment (ROI), hammered home three vital points:
Two significant observations can be drawn from these statistics: benefits statements are most likely incomplete when IT attempts benefit estimating alone, and IT investments get more out of whack from business objectives when the IT group excludes their business counterparts during the development of project ROI metrics.
Not surprising, is it?
There is one essential element that is needed for any attempt to align IT investments with business objectives and that is the business.
The good news is that IT groups from large companies (those with revenues of $1 billion or more) work with the business side in developing ROI calculations in 86% of the cases, but this number drops dramatically to 69% and below for companies with revenues less than the $1 billion figure.
Based on experience, I know that it can be painful to get a business client to define the business requirements of a proposed project, let alone get them to estimate and quantify business value for the effort.
Because of this, I’ve come up with the following five-step approach. I’ve successfully used it several times for organizing the discussion with business colleagues and guiding them through the process of articulating business benefits that can be quantified and used as part of an ROI calculation.
Define the categories and benefits. Benefits can be defined in dozens of ways, some tangible, like increased revenue, and some not-so-tangible like brand value.
If your company is just getting started in the pursuit of associating business benefits to IT projects it is best to keep the number of benefits that you will trying to estimate relatively small and choose the categories of benefits that you and your business counterpart best understand.
For most companies the following set of business benefit categories and descriptions works excellently:
Define “mid-state” business metrics. To quantify the value of an IT project resist the temptation to jump immediately to dollars and cents.
Dollars are too difficult to estimate unless there is a measurable business process behind the monetary calculation. I call these business process measures “mid-state metrics.” When I define a mid-state metric I consider the IT application in terms of its effect on such measures.
To isolate the true impact of the IT solution being proposed, it is critical that you identify measures that will be directly affected by the specific IT application being evaluated. Try to avoid measures that could be influenced by other, concurrent business projects.
Take for example, the deployment of a new order processing system. Sample mid-state metrics for this IT application could include the number of orders processed daily by an order specialist or the number of orders accurately recorded the first time.
Translate mid-state metrics to a monetary unit value. Whether your mid-state metric is the number of widgets sold or the number of old servers being removed from the computing environment, each metric has an inherent value attached to it.
Keeping with our order processing scenario, we can determine the cost of processing an order in a variety of ways, but the simplest way is usually the best way. One such approach would be to divide the total cost of maintaining the team of order specialists by the number of orders processed in a year.
Take for instance the situation where the payroll and benefits expense for a team of 10 order specialists is $600,000 annually. If the company processed 10,000 orders during the same time period, then the average order costs $60 to process.
Estimate the impact to the business metrics. To successfully estimate the potential impact an IT solution can have on a business process two components are required: a baseline measure for the current business process, and an estimated measure for the future system.
Let’s start with the baseline or the “as is” measurements. For each mid-state metric selected, collect the necessary data, such as average number of orders an order specialist processed over the past year, and calculate the baseline performance. For example, if there are 10 order specialists and 10,000 orders were logged the previous year, then the average order specialist processed 1,000 orders during the year.
Next, estimate the future performance that can be confidently expected once the proposed IT application is deployed. Keep in mind that the best way to estimate the potential increase in any business function is to interview the people in the business that perform the function.
Never assume you know what people do. You have to talk to the people who will ultimately use the IT system being proposed. It is their opinion on how an application might help them to be more productive that is the most critical insight into process estimates and adds the credibility to the final estimate that business executives are looking for.
The difference between the “to-be” process measurement and the “as-is” process measurement is the impact of the mid-state metric.
Considering our order processing example, if the future order taking capability using the proposed IT system is 1,500 orders a year per order specialist compared to the “as is” capability of 1,000 orders per year we have a potential increase of an additional 500 orders per order specialist per year in the company’s order taking capacity.
Compute the monetary value. The final step in the process is to determine the dollar benefit associated to the mid-state metric.
Continuing with the order processing example and using the following sample assumptions and performance impacts, a monetary business value can be derived:
Increased annual order processing capacity: 500 orders per order specialist
If hard cost savings benefits are desired (remember cost reduction was one of our benefit categories) then the monetary benefits can be derived as follows:
If soft cost savings are desired (remember cost avoidance is one of our benefit categories) then the monetary benefits can be calculated as follows:
Hopefully, by now, you’ve concluded that aligning IT with the business can be improved with ROI metrics, but collaboration with the business side is essential to doing it successfully.
Regardless of where your company is at in its ability to define business value for IT initiatives, a straightforward, consistent method can guide you and your business counterparts through the process as well as lessen the pain.
Finally, how you classify the benefit should be dependent on the current direction and culture of your company. If done in a true IT-business partnership, IT groups will realize more accurate ROI estimates and a higher level of trust and respect from their business clients.
Jeff Monteforte is president of Exential, a Cleveland, OH.-based information strategy consulting firm, which specializes in IT governance, information security and business intelligence solutions. He can be reached at [email protected].