Escaping the ROI trap

A strong ROI is the key to getting management approval for new systems, right? Not always. With the weak economy over the past two years, I've observed a trend in which, many times, executives refuse to approve new system investments no matter how compelling the business case is. I call this the "ROI trap."

What it is
The ROI trap works like this. The user sees a pressing need for a new system and submits a funding request. Executive management reviews the request, agrees that a new system is desirable, but indicates that no funds will be granted without a clear and compelling business case. So the user launches a significant effort to gather data on the projected benefits as well as the expected costs. The user may also enlist the help of an outside consultant and the software vendor, who are all-too-happy to provide an ROI template and participate in the effort to gather data. To avoid surprises, the team interviews executive management to determine reasonable assumptions. The team finally puts together what they think is a compelling business case and makes the presentation to executive management only to see the project shot down, put on hold, or worse--directed to "gather more data."

Why executives don't believe ROI calculations
I've theorized that the ROI trap has to do with the nature of uncertainty surrounding most ROI calculations: that is, the benefits are uncertain, but the costs are absolutely certain. In other words, the decision maker isn't sure of the benefits, but he is quite sure of the costs. So the executive, deep down, doesn't trust the ROI, no matter how compelling it is. In the face of uncertainty, the safe decision is to say no--or, if the decision maker is timid, to ask for more data.

Recently, I've been reading Judgment in Managerial Decision Making by Max Bazerman (2002, John Wiley & Sons), which explains common biases in how managers make decisions. Bazerman's research indicates that people are "naturally risk-averse concerning gains and positively framed questions" and "risk-seeking concerning losses and negatively framed questions." Read that part in italics again, and think about it, because it is the key to understanding the ROI trap.

Bazerman references a study in 1981 where participants were asked to make two decisions. The first decision was between:
  (a) a sure gain of $240, and
  (b) a 25% chance to gain $1000 and a 75% chance to gain nothing.

Result: 84% of the participants chose (a)--the small sure gain rather than the potentially larger gain.

The second decision was between:
  (c) a sure loss of $750, and
  (d) a 75% chance to lose $1000 and a 25% chance to lose nothing.

Result: 87% of the participants chose (d)--the potentially larger loss rather than the smaller guaranteed loss.

Bazerman's research, in plain English, means this: when looking at benefits, people would rather choose a small benefit that is guaranteed rather than a larger benefit that is uncertain. On the other hand, when looking at costs, people would rather choose a greater loss that might NOT happen than a smaller loss that is guaranteed.

Bazerman points out that this is why insurance payments are called "premiums" instead of "guaranteed losses." Think about it. When you buy health insurance you are choosing a small guaranteed loss (the premium) over a great uncertain loss (a large medical bill). But if the premium were designated as a "guaranteed loss," there would probably be a lot less insurance sold, or people would choose higher deductibles (i.e. smaller guaranteed losses.)

In other words, when considering benefits, people generally like to "take the sure bet." But when considering costs, people generally like to say, "I'll take my chances."

Now think about how most new system investments are presented to management. They are presented in terms of guaranteed costs and uncertain benefits, exactly the opposite of what the decision maker finds most appealing. How much more attractive the business case would be if it could be presented with the costs as an "insurance premium" against possible great losses and, at the same time, with some element of "guaranteed benefits."

If Bazerman is correct, then the ROI trap is a threat to many investment decisions. But I suspect that the cash-constrained environment that many businesses have been operating in over the past few years has made the ROI trap more deadly.

How to escape the ROI trap
When you suspect that your new system request is threatened by the ROI trap, I would suggest the following:

1. Emphasize problems with the current situation and the risks of doing nothing. Frame the business case to highlight the problems, including the worst-case scenario, of staying with the existing system, e.g. loss of vendor support, regulatory non-compliance, inability to meet the needs of the business, need to hire additional headcount, or loss of competitive position. If there are any disaster recovery or business continuity concerns, play those to the hilt. When you're facing the ROI trap, the most likely outcome is "no decision." So, build the case for action first. Otherwise, the rest of the business case will fall on deaf ears.



2. Structure the deal to reduce fixed costs, especially up-front costs. See if you can move the deal to a subscription model, where many of the upfront software license and implementation costs are amortized over a three or five year period. Where this is not possible, a financing or leasing arrangement can have the same effect. Frame the remaining fixed costs as an "insurance premium" against the problems of the existing system, not as a cost to get future benefits.



3. Build the ROI around the firm tangible benefits. Even better, show those tangible benefits as a discount against the fixed "insurance premium." For example, show the benefit of not having to pay license fees or maintenance on the existing system--a benefit that is indisputable.



4. List intangible or soft benefits, such as "improved management decision making," as a secondary category. Let the decision maker himself pull any of those soft benefits back into the primary rationale for the decision. When the ROI trap is threatening, it is better to be criticized for being too conservative than too aggressive.

These tips are no guarantee that the new system will be funded, but they should lessen the chance of your falling into the ROI trap.

Update: Read Part 2 for more on this subject.

Companies mum on savings from IT offshore outsourcing

Here's more on the impact of IT outsourcing. Computerworld observes that many large public companies, such as Microsoft, AT&T, and IBM, who are usually quick to trumpet their cost-cutting initiatives, are slow to publicize how much they are saving by moving IT jobs offshore, fearing an anti-outsourcing backlash. Furthermore, major Indian outsourcing firms such as Infosys, Wipro, and Satyam have stopped announcing new customers.

"The problem is that companies aren't sure if it's politically correct to talk about it," said Jack Trout, a principal at marketing and strategy firm Trout & Partners. "Nobody has come up with a way to spin it in a positive way."

The article predicts that as many as 2 million U.S. white-collar jobs such as programmers, software engineers and applications designers will move offshore by 2014.

Impact of offshore services on IT job prospects in the US

Stephanie Overby writing for CIO Magazine has some scary scenarios for the future of information technology in the US. Part of the problem is simply supply and demand:

India graduates 75,000 computer scientists each year. The United States, 52,900. China, which currently brings 50,000 new IT workers into the world every year, could eventually provide 200,000 computer science graduates annually, according to Marty McCaffrey, executive director of Software Outsourcing Research.

Read the whole article.

Turning software validation into a meaningful exercise

Working with clients in the life science industries, I deal often with the issue of validation of commercial off-the-shelf software. But, because validation is an FDA requirement, companies often treat validation as nothing more than a documentation effort--an exercise in producing a large volume of paperwork that the company can point to during an FDA inspection. So, I've been thinking about what companies can do to make validation a "meaningful exercise," one that adds real value to the system being implemented.

One key point is to understand the meaning of the word validation. Validation is ultimately to ensure that a system meets its requirements. Most validation professionals understand this. But too often the validation team interprets "requirements" as nothing more than "what the users want the system to do." So they conduct a series of interviews to ask users what they want the system to do.

Unfortunately, when users are asked what they want the system to do, most leave out many important things from a regulatory perspective. A better approach, in my opinion, is not to start with what the users want the system to do but what the applicable regulations require the users to do. I have found great value in sitting down with users, walking through the regulations line by line, and asking, "Do you want the system to help you do this?"

For example, FDA regulations for medical device manufacturers require users to ensure that raw materials are only purchased from approved suppliers (21 CFR Part 820.50). If the user wants the system to help him do that, then he probably needs the system to maintain an approved supplier list and prevent production materials from being procured from suppliers that are not approved to supply that material. Once I have established such a system requirement, it is a no-brainer to validate the system against that requirement. I simply test whether I can purchase material from a non-approved supplier. A series of tests such as this, that challenge the system to directly address true requirements, is the only way to uncover design flaws and false assumptions of the developer, implementer, and user.

How much more meaningful is this type of validation in contrast to what I see too often: the validation team writes a long series of test cases in excruciating detail to see whether the user can add, change, and delete a vendor master, whether a user can add, change, and delete a purchase order, whether a user can add, change, and delete a line item, etc., etc.,--but never test to see whether it is possible to order material from an unapproved supplier. No wonder they seldom discover anything interesting. They are not testing the system against its requirements--they are testing it against its design specification. That might be considered a system test, but I would not consider it a meaningful validation.

The lesson: start with the regulations, use the regulations to derive system requirements, and use system requirements to design test cases.

There is much more I could write on this subject, but I'd like some feedback. What is your experience with software validation? How do you ensure that validation is a meaningful exercise?

Clash of the titans

CNET has a long article on the behind the scenes battle between SAP and Microsoft in the enterprise systems marketplace. The article highlights a $10 million win by Microsoft over SAP at Esselte, a $1.1B office supplies manufacturer. The win is the largest in the short history of Microsoft Business Solutions. While Microsoft is increasingly reaching up into such larger deals, SAP is reaching down with its SAP Business One offering to small businesses, Microsoft's home turf.

The article also highlights what I think is a more significant battle: the fight over for resellers. Resellers are the key to success in the small business ERP market, and SAP, it seems, has been courting a number of Microsoft business partners. SAP, which relies mostly on a direct sales channel, does not have anything close to the reseller channel that Microsoft picked up through its acquisitions of Great Plains and Navision. If SAP were to win over some of those resellers, it wouldn't have the big splash of Microsoft's win at Esselte, but the impact ultimately would be greater.

SCO ordered to put up or shut up

The SCO Group, which owns the IP rights to UNIX, has been stirring up a cloud of uncertainty and doubt about the open source Linux operating system. Earlier this year SCO sued IBM for allegedly incorporating UNIX source code in the Linux kernal. Linux supporters have been frustrated that SCO, for the most part, has been unwilling to reveal the "millions of lines of code" in Linux that SCO claims came from its intellectual property. The problem for enterprise system users is that the confusion undermines any motivation to migrate to Linux.

But the cloud may be about to lift. A US federal court judge has given SCO 30 days to show what proof it has.

Quoted in an Internet Week article, Eben Moglen, professor at Columbia Law School says, "This is the big moment in the factual determination of what's in SCO's hand, if there are facts to support the claim that SCO has made concerning literal copying from Sys V Unix into the Linux operating system kernel -- this is the moment where we find out. Provided that IBM is not prevented by court order from sharing that information, it will be possible for everyone to know what SCO claims is theirs."

This ZDNet article has more details.

SSA's obituary was a bit premature

The Chicago Sun-Times ran an article (no longer available online) on local company SSA Global (SSA), pointing out that SSA, once given up for dead, is now in terms of annual revenue the fourth largest ERP vendor, after SAP, PeopleSoft, and Oracle. Quoting CEO Mike Greenough,

"In the mid-market ...everybody wants to be Number 1. But I'm there, and I don't intend giving it up and I think you can tell from my personality, I'm not the kind of guy who is going to roll over ... People laughed, thought I was delusional two and one half years ago. People thought we couldn't go to $300 million, then they said I couldn't get it to $500 million. We haven't even begun to fight. I just started rounding up the troops."

For more on SSA's strategy, see my article on Sep. 26.

B2B is hot, outsourcing not

Evans Data, a technology research firm, is reporting two interesting statistics in its Fall 2003 Enterprise Development Survey:

• B2B is alive! Business-to-business e-commerce projects increased a whopping 40% in the last six months, going from 11th place in last year's survey to first place this year.



• Outsourcing is so 2002. The survey indicates that outsourcing actually decreased in the last year by more than 20%. There were 56% of businesses outsourcing some development, down from 71% in the year prior. Only 7% of companies report that they are outsourcing a majority of projects, compared to 12% in the previous year.

What does this all mean? Line56 draws its own conclusions. Let me draw mine. I take the decline in outsourcing as a very positive sign. Companies are finally confident that the recession is past. They are less interested in pursuing cost-savings from outsourcing and more interested in taking control of IT and increasing in-house competencies. I see this already in some of my clients that are planning major projects for 2004.

Furthermore, I take the resurgence of B2B as a sign that we are well past the hype phase of Internet commerce and that companies see real payback from connecting electronically to customers and suppliers. Companies aren't pursuing e-commerce because it's cool but because it's good business. The Evans survey points to an increase in projects involving Web services, but I see it also in traditional and Internet-based EDI. I'm sure that some of this is due to Walmart's mandate for Internet-based EDI (EDIINT AS2) on its suppliers and similar initiatives by other major channel masters.

This mainstream adoption of Internet commerce is also seen in the B2C side. This past Thanksgiving-day weekend had retailers reporting a huge surge in electronic orders, with consumers just saying no to long lines at brick-and-mortar stores. E-business is just becoming business as usual.

The full survey is available (at a price) from the Evans Data web site.

Could FRx become a back door for Microsoft?

The trade press has written much regarding Microsoft's entre into the enterprise applications space with its acquisition of Great Plains and Navision, along with its development of its own applications such as Microsoft CRM. Such developments are perceived as a competitive threat to application software vendors that partner with Microsoft. But what is not often discussed is Microsoft's presence already as an application provider to over 100,000 companies due to its ownership of a widely used financial report writer called FRx.

FRx Software, which was acquired by Great Plains prior to Microsoft's acquisition of Great Plains, is probably the most widely implemented financial report writer among small and mid-sized businesses. It's a good product. So good, in fact, that a number of mid-tier ERP vendors include FRx as a complementary product or in some cases as their only option for financial reporting. Some of these vendors, such as Epicor, Ross Systems, Best Software, Expandable, Made2Manage, and MAPICS, are constantly going head-to-head with Microsoft Business Solutions (MBS) for ERP sales. Yet they turn around and offer a Microsoft application as part of their own offerings.

Once MBS has sold FRx into an account, it could use the FRx relationship as a back door into the account to sell its enterprise applications, such as Great Plains, Navision, Axapta, and Solomon. Or, they could simply mine the huge installed base of FRx users that already exist. I've not yet heard of MBS resellers attempting to exploit the FRx installed base to sell other Microsoft applications. But, if readers have any stories to share on this subject, please let me know.

Update, Dec. 4: A Microsoft reseller and a Microsoft competitor that resells FRx have both given me some feedback, and maybe my idea is just ahead of its time. The Microsoft reseller writes:

People here seem to agree that this would be a tough back door. One of FRx's selling points is that it doesn't really care what ERP system you're running, it can provide you with good financial reporting. So our going into an FRx account to talk about ERP is sort of contrary to that. As you note, FRx probably got into the account via the company that sold them their ERP system, so there wouldn't be any real MS relationship because of FRx.

My source at a Microsoft competitor has this to say:

We are also a reseller of FRx. I see no attempt on the part of Microsoft to leverage the FRx installed base. In fact I see nothing from Microsoft that would suggest using this as a tool to gain access. I dont think they have a clue on how to do this. The Microsoft application software groups are so removed from each other it is a wonder they even know each other exist. At all the Microsoft shows that I have been to, FRx was never mentioned. I know people at Great Plains and they never bring up FRx either.

Update, Dec. 9: A Great Plains reseller has confirmed what others are saying: "As a VAR we have no visibility into the FRx installed base. Also, I am not aware of any campaign for MBS to go after the FRx installs with an alternate ERP offering."