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.
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.
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.JaDisclosure 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!
Justin James is the Lead Architect for Conigent.