The numbers are astounding, even after all these years. A full quarter of all IT projects are canceled before they’re done. Half of the ones that reached the finish line didn’t come in on budget, and a similar percentage had unexpectedly high maintenance costs.

A whopping 60 percent don’t get done on time. Even more disturbing, some 40 percent didn’t deliver enough business value even after they were eventually rolled out.

You’d think after decades of experience doing these sorts of projects that we’d get them right. It’s not like we don’t know why this happens. In his 1997 book “Death March,” author and industry veteran Edward Yourdon spelled out the reasons, which haven’t changed much in all the years since the book came out.

Politics heads the list, of course. Some projects are just excuses for power games. Unrealistic expectations are a big factor, too. Panic among the executive pigeons is likewise a big one. We in the high-tech industry haven’t adequately addressed many of those causes, because we really can’t. The business side has to deal with them. But we have begun to address one: naiveté.

I include in naiveté the innocent belief that businessfolk and IT providers are actually talking to each other. I think it’s safe to say that they actually don’t. Not only do they speak different dialects of English, but they also have a mutual distrust of each other that causes static on the line.

There is an old programmer’s joke that if a bug is discovered in software, you can just document it and make it into a feature. An even harsher inside joke is to attribute a user’s problem to the ubiquitous ID10T error (sound it out).

For their part, business users habitually rate IT support as somewhere between disappointing and hideous, and the software that issues from any IT department as obviously having been written by Eastern European hackers under the influence of too much vodka.

This subtle mistrust has been problematic for years, but as the price of software goes up, the downside of project failure has likewise grown, and companies that once tolerated the disconnections have found that failed projects are costing too much.

The ITers have responded in two encouraging ways:

• The emergence of the trained human-computer interaction specialist—the usability guru. There are now graduate programs in human-computer interaction that are turning out usability experts who are revolutionizing the online world in particular, where major e-commerce sites require massive investments and can’t afford dismal usability. There are two programs in Indiana alone, one at Indiana University (www.soic.indiana.edu), the other at IUPUI (informatics.iupui.edu).

• The industry has standardized the profession of “business analyst.” The title has floated around for quite a while, acquiring different meanings in different places, but today there’s a professional organization for business analysts, the International Institute for Business Analysis (IIBA), which is in the process of making the term more rigorous (www.theiiba.org).

Put simply, the business analyst is an interpreter, doing his job in much the same way a United Nations interpreter works. A good business analyst has to know both the business operations and the technical potential of both off-the-shelf technical products and custom software. The best analysts go further and not only understand both sides’ language, but their cultures and norms, too. Analysts operate with the finesse of a diplomat engaging in shuttle diplomacy. Their job is to make sure a custom or purchased product suits the needs of users.

The analyst does more than just talk and intercede. She compiles requirements that are reviewed and accepted by both businessfolk and IT personnel before a line of code is written. She might arrange to show prototypes of the proposed software to business users so they can visualize what they’re going to get when the work is done. She helps the business users prioritize features so development proceeds first on the vital few, while less important features might have to wait for version 2 of the software.

Sometimes the business users themselves don’t know how all their business flows work, so it can also be the business analyst’s job to document the flow before she can talk about requirements for products that will reduce choke points. The IIBA even has a certification program for business analysts, so employers will know what they’re getting, particularly if the idea of an analyst is a new one for them.

Not even the best business analyst can solve all the problems with dysfunctional development. She can’t keep C-level executives from jousting at one another, nor can she scrape up cash to keep an underfunded project afloat. But she can cut costs, make software more useful, make users happier, reduce the number and severity of failures, and help establish trust where there hasn’t historically been much. That’s progress.•

__________

Altom is an independent local technology consultant. His column appears every other week. He can be reached at taltom@ibj.com.