Banking

ROI equation for development projects: What not to forget

When measuring your development project's ROI, it's important to go beyond the basic calculation. Here are a few important costs and returns that you may have overlooked.

 

While participating in the BNET Webcast Effective Customer Experience Management, I answered a listener's question about how to measure a project's ROI. This got me thinking about how rare it is for ROI to be measured in development projects. Even when it is measured, it's usually not done correctly.

Without proper ROI measurement, it can be very difficult to justify a development project when the belt tightening comes. Here's a list of factors that you should remember when calculating your project's ROI.

Investment costs

To understand ROI, let's first take a look at the investment aspect, which is where many ROI measurements go wrong. The investment in a project is more than just the salary of the people directly working on it, and the materials consumed along the way.

Read this list of commonly overlooked costs to see if you're including the right things in your ROI equation.

  • Benefits: The people on your development team have benefits (such as a 401(k) and life insurance) that cost roughly the same regardless of the person's salary. When estimating your cost, you need to include the cost of benefits on top of salary. For many employees who are low on the salary ladder, their benefits can often come close to their salary.
  • Operational overhead: Are you doing a ton of cross-country conference calls? If so, it might be a big phone bill. Energy and cooling costs are becoming major cost centers too; travel can take a big chunk out of your budget as well. On one project that I worked on, I realized that about 10% of the entire sale was spent simply to send the team onsite to perform the initial evaluation. There's little ROI possible with an investment like that!
  • Opportunity cost: This is an opportunity cost: When someone is working on a project, what revenues are they not generating? For example, when a developer is maintaining legacy code instead of helping to roll out a new project, a new revenue stream is delayed, which is lost revenue. When the sales team gets too involved with the business analyst's role, they are not selling, which means lost sales.
  • Management time: Every time you need a VP to come in and settle a dispute, it costs money. Whenever you have a meeting and decide to talk to the stakeholders who are not directly involved, it costs money. It is very easy to forget that management's time has a cost too, and it is tough to accurately measure it.

Not-so-obvious "returns"

Direct revenue is the obvious number to measure the return on a development project. But you can also find a ton of extra "returns" on your investment that might not be so obvious. When the chips are down, and it's "put up or shut up" time in the budget review, you'll want to have the following numbers in hand.

  • "Synergy" revenue: If you can determine that customers who purchase Product A are 10% more likely to purchase Product B, you should include that "synergy" revenue into your ROI calculation for Product A. On the other hand, Product A may also render Product C obsolete or irrelevant, which would be a loss of return.
  • Side effect savings: Some projects may not generate much (if any) revenue, yet they save the company money. For example, a Web site redesign project might reduce calls to the Help Desk by 40%, which is a significant savings that you should not overlook. On the other hand, you also want to bring up any items that count against the return column. For instance, if a product has a lot of defects and incurs a lot of returns, it can wind up costing the company money.
  • R&D levers: Some projects (particularly infrastructure and framework projects) can make it possible to slash the R&D time and effort needed for other projects. Try to figure out how much of a leg up your other projects get and put that as a return.

Formulate the right equation

To sum up, it's important that you go beyond the basic ROI calculation of, "We spent $X on salary to develop the product and saw $Y in sales of the product, so the ROI is $Y - $X and the profit margin is $X / $Y." These types of simplistic calculations make a lot of valuable development projects look like a waste of time.

J.Ja

Disclosure of Justin's industry affiliations: Justin James has a working arrangement with Microsoft to write an article for MSDN Magazine. He also has a contract with Spiceworks to write product buying guides.

---------------------------------------------------------------------------------------

Get weekly development tips in your inbox Keep your developer skills sharp by signing up for TechRepublic's free Web Developer newsletter, delivered each Tuesday. Automatically subscribe today!

About

Justin James is the Lead Architect for Conigent.

18 comments
fourcadm
fourcadm

Negotiate your starting salary or pay raise by being better informed about salaries at your company. Learn about conditions proposed by other companies in your field in order to target and choose accordingly your professional advancement. Boost your career with WhatSalary.com

code4living
code4living

> "When someone is working on a project, what revenues are they not generating? For example, when a developer is maintaining legacy code instead of helping to roll out a new project, a new revenue stream is delayed, which is lost revenue." How can maintaining legacy code a lost revenue? Maintaining code is the process of making sure your system software continues to run and to prevent it from breaking. Whether it's legacy or not, any code that your company needs to run is actually what keeps your company from running thus generating revenue. Not maintaining code only puts your company at risk of losing revenue.

ndsatya
ndsatya

Justin, Excellent piece. I am just wondering whether the formulae (metioned last) are correct. I guess ROI = ($Y - $X)/$X and profit margin = $Y - $X. Could you please inform? Thank you, Satya

jslarochelle
jslarochelle

I hope managers read this post. Some of my favorites: - Opportunity cost: I see this getting neglected quite often. One interesting variation on this theme: having people work on meaningless tasks because the gate process gets in the way ("you cannot start coding before gate 3" type of thing) - Side effects savings: maintenance work on existing projects is often difficult to justify because saving in the service division is neglected (this one is worth repeating) Keep up the good work! JS

ibogorad
ibogorad

In my experience, economic analysis of projects presents a significant challenge to many individuals and organizations. Not unlike the matters of world economy, marketing, real estate or investing, it seems that I am yet to find a manager or an executive who cannot do it. Meanwhile, my company consistently sees extremely poor cost benefit analyses, which stand no chance. I would not be in the shoes of an author of a botched case, because it is often a career limiting move. Surprisingly, even the largest consulting companies seem to produce suboptimal results, at a cost of tens and hundreds of thousands of dollars. This keeps us busy, so I should not really complain, however, I think we would all benefit from doing things right. Here are my pointers, three out of hundreds: - Know what you are doing. You cannot put together a cost benefit analysis just by piling up a bunch of numbers. - Economic analysis (NPV, RO, IRR, payback, etc) is just one side of the story. Don't forget about qualitative and capacity benefits. - Economic analysis must be performed on a cash basis. Disregard non-cash accounting treatments, such as depreciation, entirely. Ilya Bogorad ibogorad@bizvortex.com www.bizvortex.com

Justin James
Justin James

Please re-read that sentence carefully. It is quite clear: someone maintaining legacy code is someone *not creating a new product*. New products = new revenue streams. Of course maintenance must be done... it's why we do it. But if you are running a company, wouldn't you rather have 2 products potentially bringing in money than one? Of course. J.Ja

Justin James
Justin James

Satya - You're pretty close. :) "Profit" is simply the difference between costs and gain (revenue + savings). "Profit margin" is the profit divided by the cost, as a percentage (for example, if you gain $200 for every $150 spent, the profit is $50, and the profit margin is 33%). "ROI" usually refers to the profit number. The major difference between the traditional idea of "profit" and the newer concept of "ROI" (even though the calculation is the same), is that "profit" usually deals only with the obvious dollar numbers: direct revenues and direct costs. ROI, on the other hand, allows for less direct items to be included too, such as "synergy renevues", time savings, and so on. In other words, ROI involves a much more comprehensive picture of both the "return" and the "investment" than a profit calculation does. Hope this helps! J.Ja

hans16
hans16

In addition to all of the items mentioned in this item, I believe the most important is HONESTY. I do not know how many ROI analyses I have seen, many of them done by the project sponsors or consultants thereto, that were basically dishonest. Each entry must be backed up by a premise and then the numbers, as well as the most important part probability. Without these three elements, the ROI analysis is either misleading or patently dishonest. Enjoy

Justin James
Justin James

Ilya - That is some great information. One of the things I think a lot of companies could use, is a staff statistician or economist, someone who simply understands numbers and what they truly mean. As you say, most managers simply are not knowledgable about these topics, and I really can't blame them either. J.Ja

Tony Hopkinson
Tony Hopkinson

the iffiest of the lot. After talking to a % of the market, x% indicated they would like some software to do this and would pay about this for it, so therefore this development is worth total market * x% * price. My arse..... ROI on enhamncement usually sucks as well. Change all the icons etc in branding exercise, yes. Refactor to increase performance. or reduce fragilty. iffy Refactor to reduce future maintenance costs, get out of here.... All depends on who suggests it, as far as I can make out all suggestions made my non technocal types have ROI by default, no matter the cost.

code4living
code4living

I think your sentence is quite clear. Let me quote you again. You wrote: "... when a developer is maintaining legacy code instead of helping to roll out a new project, a new revenue stream is delayed, which is lost revenue." I think I understand now that what you wanted to say instead is "lost opportunity to potentially create new revenues." But definitely, not creating a new product because you are doing maintenance work is a lost revenue. It's like manning a store. You have to be there every day to make sure that customers can do their business thus generating revenue for you. If you wanted to create a new store somewhere and you have to abandon the existing one then you'd definitely lose revenue from that store. The new store you plan to create is not yet a guaranteed revenue earner. It's only a potential revenue earner. Like a new product, you don't know that it could be a flop. Developing a new product is like R&D which Wikipedia defines it as a cost center. It's not a source of revenue stream. http://en.wikipedia.org/wiki/Cost_centre

ndsatya
ndsatya

Thanks Justin. I think you are referring to ROIC in the later part of your explanation which takes minute things into account. From your explanation I think Profit Margin will be more close to BCR (Benefit Cost Ratio).

Justin James
Justin James

I agree completely. I think it helps when ROI is calculated by someone not emotionally involved with the project (whether a supporter or a detractor), less likelihood of fudges ("oh, this actually saved us millions in labor costs... 3 seconds saved per day times 10,000 employees!") J.Ja

ibogorad
ibogorad

...the truth is, this is something practically anyone can learn how to do. It is a mistake to think that this is some kind of sacred knowledge that should be left to higher priests of number juggling. There is no need for a resident economist and even less so for a statistician. This is a VERY valuable skill (necessary, in my opinion),which can give a person's career an enormous boost, not to mention the immediate value to the organization. You may want to look at my latest articles here: http://blogs.techrepublic.com.com/tech-manager/?p=564 Cheers, Ilya

Justin James
Justin James

When I say "maintenance", I am not talking about "bringing out the next release that customers will pay to upgrade to." I am talking about "fixing bugs in existing code." Doing that kind of maintenance work is NOT akin to "keeping the store open." It's more like "spending your day repairing the leaking roof or setting out mouse traps in the original store, instead of building the new store." Do you have to do it? Sure, if you want people to keep shopping at that first store. But at the same time, it isn't making your bottom line any bigger, just keeping it steady. J.Ja

Justin James
Justin James

I agree that anyone *can* learn to do it. But few people have the time, patience, or background to do it. Doing this kind of math really is not hard, I agree. Once you collect the relevant numbers, it is simple addition and subtraction to find the profit/loss number, and division to get the profit margin/ROI. The reasons why I suggest having a "higher priest of number juggling" involved are mostly unrelated to the math itself: * More likely to be beleived * A neutral source external to the project is more likely to present an objective picture of the situation * More likely to sniff out hidden costs and savings * Better able to handle more complex math such as asset depreciation and calculations of opportunity costs and "synergy revenue". I can tell you that a lot of people really do not understand even the basics of basic math, to the point where many people I know cannot calculate a simple percentage (nor do they understand the concept of "per cent"... "for every one hundred"). While the math is pretty trivial, I am dissappointed to say that many people in a position to be doing ROI calculations are not able to handle it. :( J.Ja

Justin James
Justin James

I agree that anyone *can* learn to do it. But few people have the time, patience, or background to do it. Doing this kind of math really is not hard, I agree. Once you collect the relevant numbers, it is simple addition and subtraction to find the profit/loss number, and division to get the profit margin/ROI. The reasons why I suggest having a "higher priest of number juggling" involved are mostly unrelated to the math itself: * More likely to be beleived * A neutral source external to the project is more likely to present an objective picture of the situation * More likely to sniff out hidden costs and savings * Better able to handle more complex math such as asset depreciation and calculations of opportunity costs and "synergy revenue". I can tell you that a lot of people really do not understand even the basics of basic math, to the point where many people I know cannot calculate a simple percentage (nor do they understand the concept of "per cent"... "for every one hundred"). While the math is pretty trivial, I am dissappointed to say that many people in a position to be doing ROI calculations are not able to handle it. :( J.Ja

Justin James
Justin James

I agree that anyone *can* learn to do it. But few people have the time, patience, or background to do it. Doing this kind of math really is not hard, I agree. Once you collect the relevant numbers, it is simple addition and subtraction to find the profit/loss number, and division to get the profit margin/ROI. The reasons why I suggest having a "higher priest of number juggling" involved are mostly unrelated to the math itself: * More likely to be beleived * A neutral source external to the project is more likely to present an objective picture of the situation * More likely to sniff out hidden costs and savings * Better able to handle more complex math such as asset depreciation and calculations of opportunity costs and "synergy revenue". I can tell you that a lot of people really do not understand even the basics of basic math, to the point where many people I know cannot calculate a simple percentage (nor do they understand the concept of "per cent"... "for every one hundred"). While the math is pretty trivial, I am dissappointed to say that many people in a position to be doing ROI calculations are not able to handle it. :( J.Ja

Editor's Picks