Michael Shermer's column, in the July 2007 Scientific American , "The Prospects for Homo economicus ", notes that we all impaired when it comes to making economic decisions.
Also, see Kathleen Melymuka's article in the July 23, 2007 Computerworld , "Boiling the IT Frog ". Harwell Thrasher suggests that simple ROI calculations don't work. The fact that we are all impaired in making economic judgements puts this observation into sharp perspective.
Also, see Jena McGregor's article in the June 15, 2007, Business Week , "Clayton Christensen's Innovation Brain ". "...the mathematics have an implicit assumption within them that if we don't do this innovation, the way things are today will maintain themselves in the future." In short, we assume we won't lose anything; which biases the analysis based on our biggest fear: loss.
Here's The Big Issue ™: We can't compare wins against losses. Our brain is wired for "Prevent Loss Decision-Making". We magnify losses (and potential losses) by a factor of 2.
Why? Clearly, we want to keep what we have. Future gains are just wishful thinking, worth only half of what people claim. Future losses are a serious kick in the pants, the impact will be twice as bad as the consultants predict
We can't inflate the future wins -- that's insanity. We can't easily diminish the potential for loss. Or can we?
The ROI Trap
Thrasher (and others) note that simple ROI calculations aren't always appropriate. First, ROI is usually based on a pack of lies. More important, however, is that ROI doesn't include "possibilities" like reusability, adaptability, flexibility, interoperability. It's hard to compute an expected value (probability times dollar value) for adaptation of software to an as-yet-undefined new business model.
ROI of potentialities is too rarefied for even an MBA in finance. What's the discount rate on an executive cutting a deal with a partner company that has a devastating impact on the current data model? We can't know. So we shouldn't try.
CYA
Because decision-making is irrationally loss-averse, it explains at lot of what passes for management. It explains, for example, why the possibility of risk is so central to IT decision-making. If there's risk, and if every manager on the food-chain has not identified the down-sides of a project, they will be excoriated by their superiors
` <http://www.sciam.com/article.cfm?articleIDThe Prospects for homo economicus</a>, notes that we all impaired when it comes to making economic decisions. </p> <p>Also, see Kathleen Melymuka's article in the July 23, 2007 <i>Computerworld</i>, <a href=>`_ , notes that we all impaired when it comes to making economic decisions.
Also, see Kathleen Melymuka's article in the July 23, 2007 Computerworld , This puts a lot of project rejection squarely in the prevent-loss mode. It also explains `Keep The Lights On Management . It supports KTLO decisions as replacing the risk of making a mistake with the non-loss strategy of Keep The Lights On. Any attempt to invest outside the KTLO minimum exposes the enterprise to the possibility of loss, which is unacceptable.
Making Progress
The deal seems to be the following: Don't Mix Wins and Losses.
If a manager wants to know what the "impact" of a software change is, don't give the full spectrum of answers.
The possibility of a screw-up (or other kind of loss) is one thing.
The potential win from getting the right software in place is another thing -- treat it as if it had different units.
Further Notions
Also, we know that software isn't really "done." If it's home-brewed, and has any value at all, people will mess with it forever. The pace of change may fall from initial development team to maintenance team. But there's no "done" until the day to turn the software off because it was replaced.
This means there's no price. At least, there's no final, single, big, ugly number. Software acquisition is about the rate of expenditure over future years. $1M this year, $900K next year, $150K per year after that, until the end of time .
With an infinite stream of payments, what does ROI mean? You have to do ROI on a year-by-year, or release-by-release basis. That's much more rational than asking your vendors like me to make up an "overall" price.
How It Might Play Out
If there's a 10% chance that you won't get things converted by July of next year, then there's a possibility of loss. You could assign an expected value to this. $1.5M spent, 10% of nothing to show for it. This is $150,000 loss. But that puts you squarely into ROI-world, where you don't want to be.
If there's a 90% chance of success and better software, you could try and put a dollar value on this. Except, of course, you will probably deliver incrementally, and you'll have some return very early, with accelerating returns after each release. And the "potential" returns are imponderable. What to do?
The only thing you can do, is avoid talking about loss and anything that looks like loss. Don't lie, but don't dwell. Yes, there's a chance of failure, but it's small and it isn't random -- it's bad management. Yes, we'll be discarding some old software, but the new software will allow [X], [Y] and [Z] which the old software didn't allow.
Note the discarding of "some" old software. In many cases, you will discard all old software. However, because of our hard-wired economic bias, discarding old software is a loss, and we cannot tolerate loss. Generally, when you are reworking old software, you will preserve the data, and many of the concepts. That's what's important, and that's what you can dwell on.
Say: "We're not reinventing the wheel." Even when you are going to delete the old code.
Say: "We're preserving all the old data." Even when you have to completely restructure it from the non-relational to the relational database.
Conclusion
It isn't IT managers (or managers in general) who can't make rational technology decisions. The natural human tendency is to inflate losses and discount gains. The only way to avoid the comparison problem is to keep the losses (and possibilities of losses) widely separated from the anticipated gains.
All of the project failures that I've ever seen in 30 years of IT have been management problems. Most are related to a fundamental unwillingness recognize that early phases of analysis (and architecture) are done in discovery mode. Learning something new during analysis should not be labeled as scope creep, and is not cause for cancelling the project.
Additionally, managers who want to grandfather in old software because it looks "cheaper" or "simpler" are usually wrong. They are also unaware of their own human bias toward preventing loss. They think their being rational, even-handed and skillful. Actually, they're just wrong about the cost (and benefit) of moving forward.