Intelligent Enterprise

Better Insight for Business Decisions

RSS
Webcasts
Whitepapers
Subscribe
Home

November 18, 2003

Predicting Software Success

Some new applications are destined for failure, others for greatness. Here's how to tell before you see a line of code

by Joshua Greenbaum

Seeing new applications emerge from the primordial soup of technology and business process has always interested me. There's no shortage of bad ideas that will become the evolutionary dead-ends of the future — the best example being the nerd-developed application in search of an unknown business problem to solve. Although once the source of all new apps, the nerds are now the dinosaurs of development. Indeed, we're so far beyond technology for technology's sake that nerd-driven development is almost a sure sign of failure.

Software that starts on the business side of the equation, however, seems to have a chance of surviving the Darwinian software industry. And most software companies today claim to fit that new requirement. But even this simple rule still yields average life expectancies for new applications that are lower than we'd like. There must be more to software success than eschewing technology for its own sake.

My years of sitting through new product briefings, followed by an equal number of years tracking products' successes or failures, have led me to conclude that successful new products have three key characteristics that, although not guarantees, serve as a great benchmark for predicting success for the vendor and, more important, success for you as the buyer. (Other factors, including the financial and managerial viability of the vendor and the ability to leverage existing technology and applications infrastructure, play a role as well, but I'll assume you already know something about them.) Knowing the origins of a successful application will help you better understand new software offerings and their relationship to your business.

Automates Existing Processes

One of the most important lessons we learned from the dot-bomb disaster was that getting companies to do things in an entirely new and different way, particularly one that requires many companies or partners to sync themselves into new modes of interaction, is one of the hardest effects a piece of software can hope to create.

The best example is the trading hub or Internet market, those once ubiquitous and now irrelevant online marketplaces that were supposed to shift all business-to-business buying from the phones-faxes-mail paradigm to the wonderful world of Internet interaction. Turns out this transition required too many companies to shift their business processes in too radical a way, and the downside of natural selection took over.

Companies soon realized that they could really only automate existing, nonautomated interactions between two business partners, such as converting EDI transactions to an Internet technology base. The EDI upgrade is viable because change comes not from the creation of new business processes but from making existing ones more efficient. Forcing complete process changes — such as was postulated by Internet markets and trading hubs — was just too much for customers to swallow.

A good example of how an existing process can be automated comes from Edge Dynamics Inc.'s Business Operations Compliance software, which automates companies' compliance with existing business rules and policies. We all strive for policy compliance, but who has bothered to automate it? The moral of the story is simple: Letting businesses do the things they already do in a faster and more efficient manner makes a lot more sense than forcing massive process change alongside technology change.