Even small, smart, agile organizations can make disastrous computer-system mistakes.
Even small, smart, agile organizations can make disastrous computer-system mistakes.
Jerry Moody has a lot in common with FBI director Robert Mueller. They've both been in law enforcement -- Moody is a former policeman, or "used cop," as he likes to put it. They both head investigative organizations -- Moody founded and runs Coast Guardian Investigations in Hayward, Calif., which each month conducts some 600 background investigations of job applicants on behalf of mostly well-heeled corporate clients. But Mueller and Moody also happen to share a noteworthy accomplishment, albeit one they probably don't put on their resumes: They both presided over ambitious technology projects that turned into money-sucking fiascoes.
"I love people in general," graphic novelist Alan Grant once said. "But I find that on an individual level people are bastards." That pretty much sums up the relationship many companies have with technology. We swear computer systems have done so much to improve the way we do business, and yet any given information technology project can cause impressive sums of money to disappear into the pockets of IT professionals -- all to pay for something we might gladly trade for a quality lava lamp.
The FBI will back me up on this, having flushed some $150 million down the tubes in the past five years on a system that was supposed to allow agents to share information about cases with one another and with other agencies but which now appears to be destined for virtual shredding. In the inevitable post-disaster finger-pointing, congresspeople have been shocked -- shocked! -- to learn that this much money could be wasted on a system that doesn't do the job. They have forgotten, apparently, that the Federal Aviation Administration, the IRS, every branch of the military, and many other federal entities have lost far more on big dead-end technology projects.
But those who sneer at the inability of lumbering bureaucratic government agencies to manage technology probably haven't run a company. Because while having a computer-system development disaster take place on your watch may sound like reason for cringing in shame, it's actually more the rule than the exception -- the vast number of failed projects churned out at businesses just don't happen to get the press. "More than half the large custom systems that are started never reach users," says Joseph Goguen, a computer science researcher at the University of California at San Diego. "Usually they're just canceled, but sometimes they're declared a success and then not used." Small and midsize businesses build these clunkers by the tens of thousands, too, he adds -- and often blow a larger percentage of revenue on them to boot.
That's what happened to Coast Guardian's Moody. Six years ago, reeling from the costs and delays from the paperwork involved in running background checks on job applicants, Moody wondered why he couldn't do it all online. He hired a systems developer. Two years and $20,000 later, the system still wasn't working, and the developer had stopped returning calls. "I could have hunted him down, of course," says Moody. "But what for? The money was gone. And $20,000 was a big hit to us then."
To an outsider, runaway computer projects may smack of incompetence. But even companies with gilded technology reputations suffer mammoth failures -- IBM, for example, participated in a mid-1990s project that helped burn $1.5 billion of taxpayer funds in a futile effort to revamp the nation's air traffic control systems. And Goguen notes that when experts studied the costs of fixing failed computer projects, they found that only about 20% of the costs were related to problems with programming or system design. Another 20% or so were related to a failure to address the needs the organization had stated. But about 60% of the costs went into the real culprit: the organization's failure to explain its needs. "The developers end up designing and building the wrong system," says Goguen, "and they don't realize it until they're almost through." Sometimes the technology people do a poor job of listening, he notes, but more often the failure is at the business end.
You might have thought that saying what you want your computer system to do is the easy part. But managers often give the process short shrift, says Les Kent, president of Progent, an IT consulting and outsourcing firm in San Jose, Calif. "Key decision makers often participate at a cursory level early on because they're busy and it isn't fun," he explains. "Then they get upset later on when the project isn't going the way they envisioned." Small and midsize companies are usually too stubborn or strapped to just kill a bad project, he adds; instead they force it on users anyway, limping along for years with what he calls an "albatross solution."
But even when managers do take the time to spell out exactly what they need, projects can fail. The problem, notes Danny Shader, founder and CEO of mobile applications and service provider Good Technology in Santa Clara, Calif., is that companies operate in fast-changing environments. As a result, they sometimes end up with systems designed to meet their needs of 18 months ago. "If you give a developer a snapshot of your business to work with, you're going to have a problem," says Shader. "Systems have to be built with the expectation of changing needs."
Come to think of it, it's so easy to screw up just the tell-me-what-you-need part -- never mind actually designing and building the system -- that it seems miraculous that any system works. That many do may in part be luck. But there's also a growing awareness on the part of smart businesses and technology developers that there are ways to avoid the standard traps. For example:
Make sure developers understand what users really need. Justin Hectus, director of information for the Los Angeles-based law firm Keesal, Young & Logan, turns himself and his team into benign spies for a while at the beginning of every project in order to get a feeling for the needs of those who will be dependent on the system. "We spend significantly more time studying how people work than we do on the actual programming and development," says Hectus. The goal isn't to meet all of everyone's needs, he adds; a system that meets only a handful of the most important needs of the most productive users will usually be considered a wild success and will be cheaper and faster to build. One recent success: a system developed in partnership with Good Technology that lets the firm's 80 professionals keep track of everyone else's workload via mobile device, so that a lawyer who's swamped can see at a glance who might be available to help out.
Throw together a rough prototype to bounce off users. People often think they know what they want, says Goguen, until they sit down in front of it and realize they want something else. The trick, he says, is to find a fast and cheap way to uncover that sort of mind-changing. When Goguen's students took on developing an online system for a local jazz festival, he had them sit representative users down in front of a cardboard box on which handwritten pages were taped, providing a zero-cost simulation of a first iteration of the system. One of several discoveries that came out of the sessions was that the jazz fans, who tend to be older, preferred easier-to-read large type on the "screen" -- a simple change that would have been costly to make at the end.
Break the contract into pieces. TechGame Networks, a Colorado Springs application developer, offers its clients contracts that call for the project to be developed in two-month chunks. After each chunk, the client is free to walk away or renegotiate the remaining pieces. That way, explains TechGame co-founder Shane Holloway, the project won't get far off track before problems are identified.
Coast Guardian's Moody, for one, learned enough from his early disaster to make sure things worked out the second time. When he turned to Progent 18 months ago to try again, he was ready with a detailed description of exactly what he wanted. Three months later he had a system that cut 80% of his paperwork and shortened applicant investigations by 10 days. One highly impressed multimedia client started spreading positive reviews, and the value of the resulting new business has already exceeded the $40,000 cost of the system. "No one in this industry has anything like it," says Moody. "I'm thinking of licensing it to others."
It sure beats a congressional investigation.
David H. Freedman (firstname.lastname@example.org), a Boston-based writer and Inc. contributing editor, is the author of several books about business and technology.