Comments on: Definition of ROI – Return on Investment

By: Little K’s Blog » Blog Archive » Managing scope creep is not a zero-sum game

Sat, 29 Apr 2006 14:01:02 +0000

[...] 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. [...]

By: Requirements vs design - which is which and why? -Tyner Blain

Requirements vs design - which is which and why? -Tyner Blain — Sat, 11 Feb 2006 19:42:38 +0000

[...] Market requirements. The problems or opportunities that express potential ROI opportunities. These can be captured in an MRD. [...]

By: MRD to PRD requirements conversion -Tyner Blain

MRD to PRD requirements conversion -Tyner Blain — Thu, 09 Feb 2006 06:24:52 +0000

[...] 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: Using ROI for requirements is a risky business -Tyner Blain

Using ROI for requirements is a risky business -Tyner Blain — Sun, 05 Feb 2006 03:14:53 +0000

[...] 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: Definition of expected value -Tyner Blain

Definition of expected value -Tyner Blain — Sat, 04 Feb 2006 17:05:43 +0000

[...] 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: Scott Sehlhorst

Scott Sehlhorst — Thu, 02 Feb 2006 13:28:49 +0000

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.

By: Marcus Ting-A-Kee

Marcus Ting-A-Kee — Thu, 02 Feb 2006 06:19:40 +0000

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

By: Stop wasting your time - don’t bother writing functional specs -Tyner Blain

Stop wasting your time - don’t bother writing functional specs -Tyner Blain — Thu, 02 Feb 2006 05:23:10 +0000

[...] 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: Getting past the ’suck threshold’ -Tyner Blain

Getting past the ’suck threshold’ -Tyner Blain — Thu, 02 Feb 2006 05:10:23 +0000

[...] 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: Communicating a delivery schedule with use cases -Tyner Blain

Communicating a delivery schedule with use cases -Tyner Blain — Thu, 02 Feb 2006 05:09:22 +0000

[...] 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: Top five use case blunders -Tyner Blain

Top five use case blunders -Tyner Blain — Thu, 02 Feb 2006 05:07:16 +0000

[...] 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: CRUDdy use cases and Shakespeare -Tyner Blain

CRUDdy use cases and Shakespeare -Tyner Blain — Thu, 02 Feb 2006 05:06:05 +0000

[...] It’s hard to imagine Shakespeare’s Hamlet without Yorick’s skull – but the ROI comes from the idea, not the chosen implementation. [...]

By: Foundation series: Software process (waterfall process versus incremental process) -Tyner Blain

Thu, 02 Feb 2006 04:57:12 +0000

[...] 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: Brainstorming - making something out of everything -Tyner Blain

Brainstorming - making something out of everything -Tyner Blain — Thu, 02 Feb 2006 04:55:39 +0000

[...] 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: Prioritizing requirements - three techniques -Tyner Blain

Prioritizing requirements - three techniques -Tyner Blain — Thu, 02 Feb 2006 04:54:48 +0000

[...] 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: A requirements documentation mistake -Tyner Blain

A requirements documentation mistake -Tyner Blain — Thu, 02 Feb 2006 03:48:48 +0000

[...] 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: Describing the software development process -Tyner Blain

Describing the software development process -Tyner Blain — Thu, 02 Feb 2006 03:47:18 +0000

[...] Market analysis. The problems or opportunities that express potential ROI opportunities. These can be captured in an MRD. [...]

By: Five measures of product manager performance -Tyner Blain

Five measures of product manager performance -Tyner Blain — Thu, 02 Feb 2006 03:45:44 +0000

[...] Measure the “missed ROI“ of the delivered project, relative to the initial plan. [...]

By: The best way to improve ROI is with good requirements -Tyner Blain

The best way to improve ROI is with good requirements -Tyner Blain — Thu, 02 Feb 2006 03:44:09 +0000

[...] 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: [...]