home
Home » Methodology

ROI is Deceptive Without REAL Requirements and Quantified Intangibles

Submitted by RobinGoldsmith on Tue, 2007-03-20 09:59.

by Robin F. Goldsmith

Common presumed best practices for determining Return on Investment (ROI), advocated by almost all apparent authorities, in reality often undermine ROI's very purposes.

ROI is supposed to provide a valid and reliably supportable objective basis for making decisions: the quantified dollar benefits of an approach versus its quantified dollar costs. However, the customarily recommended practice of listing but not quantifying the dollar value of "intangible" benefits leaves a gaping loophole that can render even seemingly conscientious ROI analysis a deceptive sham.

The dirty little secret of ROI is that voluminous documentation and calculations often are merely a smokescreen obscuring the fact that in most organizations the proponent's favored outcome almost always prevails. Although perhaps not consciously recognized, calling the exercise "justification" indicates a mindset where there's not even a  pretense of objectivity, since measurements are chosen to justify the proponent's predefined answer.

AttachmentSize
ROI Is Deceptive Without REAL Requirements and Quantified Intangibles.pdf398.42 KB
» login or register to post comments | printer friendly version | 2417 reads

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Attachment?

Submitted by rcauvin on Tue, 2007-03-20 10:46. *

Is there supposed to be a PDF attached? This looks like an abstract, not the article itself.

» login or register to post comments

Don't see the full article

Submitted by anupa on Tue, 2007-03-20 11:04. *

Guess the full article was not attached. One other reader has communicated that too. Hope it will be taken care of. Thanks.

» login or register to post comments

You have to click on the attachment above comments to see it

Submitted by RobinGoldsmith on Wed, 2007-03-21 00:07. *

and below the abstract

» login or register to post comments

RE: You have to click on the attachment above comments to see it

Submitted by rcauvin on Wed, 2007-03-21 11:04. *

Robin, the attachment wasn't there when they first posted the article. They later added the attachment.

» login or register to post comments

Problem Pyramid

Submitted by rcauvin on Tue, 2007-03-20 11:31. *

I like the problem pyramid. A couple of questions about it:

1. What is the relationship between the Now Measure and the Goal Measure? The Now Measure is "the measure of the problem now that tells us it is a problem". The Goal Measure is "the desired measure of the problem that indicates it's been solved". Shouldn't the metric be the same, and the limits we apply to the metric be different?

2. What is the relationship between the Requirements and the Goal Measure? Are they perhaps one and the same? Or perhaps the difference is that the requirements measure the extent to which we address the As Is Causes, while the Goal Measure measures the extent to which we've solved the problem itself?

» login or register to post comments

Problem Pyramid™ Measures

Submitted by RobinGoldsmith on Wed, 2007-03-21 06:50. *

Now and Goal measures ordinarily are different values of the same things. You could call that limits, but I don’t think the term is meaningful to most people and would obscure the distinctions between Now and Goal Measures that produce the value.

There are separate boxes because Requirements (Box 5) are not the same as the Goal Measures, and Requirements are not just a variation on or reaction to the Causes. The Requirements are _whats_ in their own right, not a derivative. If the Requirements are met, the Goal Measures are achieved. Meeting the Requirements accomplishes the Goal Measures because the Causes that produced the Now Measures are no longer determining the results.

» login or register to post comments

RE: Problem Pyramid™ Measures

Submitted by rcauvin on Wed, 2007-03-21 11:17. *

"Now and Goal measures ordinarily are different values of the same things."

Okay, that makes sense to me. If the Now Meaure is "it takes ten minutes for an agent to process an order", the Goal Measure might be "it takes less then five minutes for an agent to process an order". Right?

"There are separate boxes because Requirements (Box 5) are not the same as the Goal Measures, and Requirements are not just a variation on or reaction to the Causes. The Requirements are _whats_ in their own right, not a derivative. If the Requirements are met, the Goal Measures are achieved. Meeting the Requirements accomplishes the Goal Measures because the Causes that produced the Now Measures are no longer determining the results."

I'm still a little hazy on the Requirements box. It makes sense that meeting the requirements results in satisfying the Goal Measures. And it makes sense that this happens as a result of addressing the Causes that produced the Now Measures. But that also could be true of the How (Design). If we implement the right How (Design), it will satisfy the Goal Measures by addressing the Causes.

So what is the distinction between Requirements and How (Design)? If the Requirements were simply the same thing as the Goal Measures, it would be clear.

» login or register to post comments

Requirements vs. design

Submitted by RobinGoldsmith on Thu, 2007-03-22 06:05. *

A quick simplistic example. The difficulty is people get caught up in the example rather than the concept. For instance, "How" might be Oracle Financials. Another "How" might be SAP. Another might be a drop down list. That's three of many possible "Hows." Do any of these "hows" mean you'll get your order time down to 5 minutes? Of course not. In fact, there's no saying any of them can actually accomplish the order you need to enter. You need to know the "whats" REAL, business requirements that must be satisfied including the choices for the drop down list and doing it in 5 minutes. Maybe the problem is that it takes the customer 10 minutes to figure out what they want and get sign-off from their five kids--does it matter that the order is for lunch? Have you been in line behind this family? None of the above "Hows" seems likely to address the REAL "whats."

» login or register to post comments

RE: Requirements vs. design

Submitted by rcauvin on Thu, 2007-03-22 13:16. *

Your example makes perfect sense describing the "what" versus the "how". In your description, the "what" seems to be getting the order time to 5 or fewer minutes. The "how" is Oracle Financials or SAP or a drop down list.

My question is, then, what is the requirement in your example? Is the requirement getting the order time down to 5 minutes? Or is that the goal measure? Or both?

» login or register to post comments

REAL Bus. Reqs. whats accomplish Goal Measures

Submitted by RobinGoldsmith on Fri, 2007-03-23 05:13. *

Five minutes for an order is a Goal Measure which can be achieved by satisfying REAL, business requirements _whats_. Oracle, SAP, or drop-down lists are presumed ways _how_ to satisfy the _whats_; but just implementing one of those techniques will not necessarily improve the order time, unless it actually satisfies the REAL, business requirements _whats_. Identifying the _whats_ involves identifying the Causes of the current 10 minute order time. If the problem involves the kids not making up their minds what they want for lunch, I don't think Oracle, SAP, or a drop-down list will make any difference because they are unlikely to be addressing the REAL, business requirements. See if you can figure out from a business standpoint _what_ would result in the kids' deciding what they want in five minutes; and then the _how_ is your way to make the _what_ happen.

» login or register to post comments

  Sponsored Announcements & Special Offers


FREE Web-based Requirements Management (not just a trial, no time limit)
Lighthouse is a web-based IT project workspace for managing requirements, change requests, project scope, and much more. Lighthouse also automates traceability through the entire life cycle so you will always know the impact of change requests and whether requirements have been built, tested and fulfilled. Free for 5-users, sign-up today.

Download a free trial of ActiveVOS for BPM application development for a chance to win an ultra-portable Lenovo IdeaPad S10 netbook
With the ActiveVOS Business Process Management system (BPMS), the creation of compelling business process applications is compatible, scalable and affordable for everyone from the developer to the business analyst. Download a free, 30-day supported trial of ActiveVOS for the chance to win a Lenovo IdeaPad S10 netbook. No purchase necessary. Download ActiveVOS today at www.wheel-of-function.com.

Writing Use Cases with Word and Excel? Suffered enough?
Create use cases, requirements, diagrams, test cases, and screen prototypes - in one easy-to-use tool. Generate Word and Excel specifications automatically. Consistent, traceable requirements in less time. Try CaseComplete FREE for 30-days.


© 2007 Requirements Networking Group All rights reserved. contact | advertise | privacy
Requirements Networking Group