Definition of ROI – Return on Investment

By Scott Sehlhorst | February 1st, 2006

Franklin

We talk about ROI all the time – what is it, in layman’s terms?

ROI is the acronym for return on investment. Another way to think of it is “How much profit will we make if we invest in this project?” Profit is revenue minus costs. Technically, the question should be “How much profit will we make, relative to our investment, if we invest in this project?” We’ll look at both definitions, and see the differences below.

Note – we also have posts explaining expected value and net present value (NPV). Both of these should be incorporated into any real-world ROI calculations, but the examples in this post do not include them, for the purpose of making ROI easier to understand.

A very simple example

We will imagine a software project to build a website for our company. The website takes 4 months to develop, plus we will need some developers to fix bugs for the first month after the site goes live. So, we will be spending money for 5 months. We’ll also assume that we already have the server and network access, so there are no extra costs associated with running this project (other than the developer salaries). We have a plan to get the software delivered as quickly as possible, so once we get the project running, we will double the size of our staff (in the third month of development). In the last month of development, we will increase our costs by another 50% because we have a real-world project, and we discover that we’re going to miss our deadline if we don’t increase staff (or pay for some overtime).

Here’s what our costs per month look like.

[Ed: 86% of you can assume the costs are measured in thousands of USD. 10% of you should assume your local dollars, 3% should use british pounds, the rest of you can use euros, yen, krona (Swedish and Icelandic), rupee, shekels, dirham, won, rubles, baht or pesos. That covers the top 20 currencies for our readers as of this writing.]

cost data chart

We also see that the total cost of the project is projected to be 80. So our investment is 80.

Cost is only half of it – what about revenue?

In our setup, we identified that the website will go live after four months, and will start generating revenue in month 5. Also, since we measure things in internet time, we will assume that we are only projecting revenue for the next twelve months. Twelve months from now, we have no idea if someone will compete with us with a better, free, open-source solution, or if we’ll keep making money. So we’ve decided to only look at revenue that happens between now and twelve months from now. If we add that projected revenue to our cost data, we get this:

cost and revenue data chart

It’s now very clear that we will spend 80 units to get 230 units back. Our profit is 230-80=150. So we get almost twice what we invest back. The answer to our first question (How much will we make if we invest in this project?) is 150.

ROI – Return on investment

The ROI, or return on the investment is 150. To determine the relative earnings, we simply need to divide net revenue by the amount that we invested. 150/80 = 1.875, or 187.5% This answers our second question (How much will we make, relative to our investment, if we invest in this project?) is 187.5%.

The ROI for this project is 187.5%. Sounds like a really good project.

This article was published on Wednesday, February 1st, 2006 at 9:41 pm and is filed under Definitions, ROI.

You can leave a comment on this post

Trackback URL

2 Comments

Marcus Ting-A-Kee

Posted February 2, 2006 at 12:19 am

Great post!

Comparing ROI between projects (or potential releases items) is an excellent way to prioritize development activities. One thing that you must be careful with is the timing of the cashflows. The more distant they are, the less they will be worth in terms of today’s dollars (e.g., I’ll give you $100 3 years from now if you give me $100 today. Somehow I don’t think anyone will accept.) In your example, this is not an issue because everything occurs within the same year.

If you do not use Net Present Value (NPV) you may choose a project that has a higher absolute dollar return but is actually worth less in terms of current dollars. Generally, some discount factor is applied to future cashflows which accounts for inflation, the cost of borrowing and some additional percentage points (opportunity cost). The NPV formula will account for the compounding affect. You can read up on NPV @ http://en.wikipedia.org/wiki/Net_present_value

Reply to this comment
Scott Sehlhorst

Posted February 2, 2006 at 7:28 am

Thanks Marcus!

Yes, I absolutely want to get into NPV, IRR and hurdle rates, payback period and other measures. There’s a bunch of this stuff to cover, just starting with the basics for now. Thanks for the wikipedia link too.

Reply to this comment

17 Trackbacks

By The best way to improve ROI is with good requirements -Tyner Blain on February 1, 2006 at 9:44 pm

[...] One ROI benefit of good requirements is being able to work on the most important stuff first. The top 3 reasons for project failures identified in their poll: [...]
By Five measures of product manager performance -Tyner Blain on February 1, 2006 at 9:45 pm

[...] Measure the “missed ROI“ of the delivered project, relative to the initial plan. [...]
By Describing the software development process -Tyner Blain on February 1, 2006 at 9:47 pm

[...] Market analysis. The problems or opportunities that express potential ROI opportunities. These can be captured in an MRD. [...]
By A requirements documentation mistake -Tyner Blain on February 1, 2006 at 9:48 pm

[...] Remember – this is a $100 million (ROI) project. And we’ve got hours invested in defining and documenting how sorting should work. I definitely did not have my eye on the ball. [...]
By Prioritizing requirements - three techniques -Tyner Blain on February 1, 2006 at 10:54 pm

[...] Our customers buy our software because it increases their profits. It’s an investment for them. The payback can be in cost-savings (bottom-line growth) or increased sales (top-line growth), or anywhere in between. We could be cutting overhead (and therefore cost of goods sold) by reducing their cost-to-quote. We could be optimizing their supply chain (reducing the dollars invested in work-in-process inventory), or we could be opening up a new sales channel (a portal website for resellers to directly submit orders to the factory). The bottom line is that it all comes down to ROI. In a comment on a recent thread, Marcus asked how we would trace requirements to corporate strategy. One example he used is the tactic of becoming the low-cost provider in a market. We have to abstract that back up to get to the dollars. Follow the money. A low-cost provider can increase market share, and potentially lower costs through automation. The strategy was presumably accepted (by the business) based upon a projected impact on company profits. We need to understand that impact-projection, and use the resultant profitability forecast to value our requirements. [...]
By Brainstorming - making something out of everything -Tyner Blain on February 1, 2006 at 10:55 pm

[...] Make a list of the first cut requirements. We’re not done, however. There is usually at least one really good idea that didn’t fall in the top cluster because the “group” didn’t all agree that it was important. Give everyone in the room a chance to nominate one of the leftover requirements into the first cut group. Let them make a case for it. If we see something that we suspect is valuable, ask questions about it. Pull these ideas into the list. We don’t have a spec. Yet.Brainstorming isn’t the key to writing a requirements document. There’s a reason that design by committee and group think make us cringe – because nothing great comes (solely) of it. A brainstorming session gets us a starting point when we are faced with customers who “don’t know what they want.” Even people who don’t know what they want generally have a good idea about what they don’t want. It’s easy to be a critic. Use this first cut list of requirements as a starting point. Review the list in individual interviews. Understand the ROI of these ideas, validate their strategic alignment with the stakeholders. Having a concrete set of requirements is the easiest way to get someone to say “We don’t need that, what we need is this!”Use the results of the brainstorming session to seed the cloud of ideas in one-on-one interviews. Don’t just spell-check them and hand them over to the dev team for implementation. [...]
By Foundation series: Software process (waterfall process versus incremental process) -Tyner Blain on February 1, 2006 at 10:57 pm

[...] Budgeting and planning (winner: waterfall process) With a waterfall process, we decide at the start exactly what we intend to accomplish. We can therefore scope and schedule the project. We can also determine staffing and costs. Budget decisions are easy – IRR and ROI can be calculated – we can calculate expected values for both costs and (forecasted) benefits. With an iterative process, we’re saying “I reserve the right to change my mind later.” We fully expect to change the scope of delivery mid-project. We know we will learn more about how to forecast the benefits after each incremental release. Because we know about, and even desire future changes, we can’t reasonably estimate ROI. We can “fix” the budget (aka timebox the project), but we can’t predict the value we will achive within the time allotted. [...]
By CRUDdy use cases and Shakespeare -Tyner Blain on February 1, 2006 at 11:06 pm

[...] It’s hard to imagine Shakespeare’s Hamlet without Yorick’s skull – but the ROI comes from the idea, not the chosen implementation. [...]
By Top five use case blunders -Tyner Blain on February 1, 2006 at 11:07 pm

[...] Wrong priorities. We have to implement the right use cases, in the right order. The most important use cases need to be implemented first. Importance is driven by ROI. Balance this with implementation dependencies and change management constraints. [...]
By Communicating a delivery schedule with use cases -Tyner Blain on February 1, 2006 at 11:09 pm

[...] Imagine that we had an application with four main features providing 50, 25, 15 and 10 units of ROI, and each taking one calendar quarter to develop. If we constrain the analysis for our project to a two year payback period (not untypical with software projects), the return versus time is both faster and higher if we delivered each feature incrementally than if we delivered all features when they were all complete. In the following chart, the green represents incremental delivery and the red represents waterfall delivery. If you’re colorblind, the green is the striped area. [...]
By Getting past the ’suck threshold’ -Tyner Blain on February 1, 2006 at 11:10 pm

[...] In the consumer space, this can be the difference between having and not having a viral marketing effect. In the enterprise space, it can be the driver of user adoption rates (and if users don’t use it, there goes the ROI argument for the project). [...]
By Stop wasting your time - don’t bother writing functional specs -Tyner Blain on February 1, 2006 at 11:23 pm

[...] The challenge is in using the functional spec appropriately in communication. Each “consumer” of the spec has a different objective – validating ROI, scheduling user-training, scoping the delivery, and more. It makes sense that they will want to see different pieces of the repository, presented in different ways. Misuse of a functional spec is a bad thing, but so is misuse of a car or an education. That doesn’t mean a spec is a bad thing, any more than an education is. [...]
By Definition of expected value -Tyner Blain on February 4, 2006 at 11:05 am

[...] Understanding the expected value of a possible future event allows us to make mathematically sound decisions. We can decide if we want to make an investment. We can assign a reasonable price for our services. We can prioritize requirements. Expected value is a calculation that should be used when calculating ROI. [...]
By Using ROI for requirements is a risky business -Tyner Blain on February 4, 2006 at 9:14 pm

[...] We’ve talked repeatedly about using ROI to drive prioritization of requirements based upon value. ROI can be used as the basis for prioritization for all decision making. [...]
By MRD to PRD requirements conversion -Tyner Blain on February 9, 2006 at 12:24 am

[...] We need to talk about ROI ROI is the primary driver of this project. ROI has two components, the return, and the investment. We can’t determine what the investment will be until we decide the scope of what to do and estimate the cost of doing it. What we can do is define the potential ROI, and from that determine how much we would be willing to spend to achieve it. [...]
By Requirements vs design - which is which and why? -Tyner Blain on February 11, 2006 at 1:42 pm

[...] Market requirements. The problems or opportunities that express potential ROI opportunities. These can be captured in an MRD. [...]
By Little K’s Blog » Blog Archive » Managing scope creep is not a zero-sum game on April 29, 2006 at 8:01 am

[...] We can’t do “too much” of this. In addition to not wanting to be “walked on” or feeling professionaly abused, we also want to meet the financial goals of the project. That’s why we establish a budget up front. We’ll keep that budget a secret, to make sure the customer doesn’t just use it up. If we share the data, we run the risk of automatically getting enough scope creep to fill up our “investment bucket.” Make sure the ROI for the project will still be met – that drives the hard line in the sand. [...]