Technology Never Fails, But Projects Can

I once taught logic—mathematical logic—to college students. There was a clarity to it that appealed to me. Things made sense. Technology, unfortunately, doesn’t always conform to logical expectations.

In the mid-’70s, I got involved on the tail end of a really sexy project in publishing, creating a system that allowed editors to take text and mark it up on screen. That hadn’t been done yet; paper, pencil and typewriters still ruled. It was ahead of everybody else. At the time, we were sort of the Cadillac of systems. We had the New York Daily News as a customer, both papers in Dallas, in Cleveland, in Houston—back in the day when all those cities had two papers.

The project came in on time, it came in on budget—and it was a miserable failure, because basically you needed a minicomputer for every person. The technology just wasn’t there yet. That taught me that it’s much more important that the project works, not just the technology. It’s got to do something that makes sense. It’s got to be practical.

I’ve never seen a project fail for technical reasons. Never. Management may have picked the wrong technology for the purpose, but the technology itself wasn’t the cause.

With that publishing system, management misunderstood whether anybody could acquire the supporting technology. The actual text system worked fine—fantastic, in fact—but nobody could afford the whole package. You could digitize photographs and put them on the system, but one picture took an entire hard disk. So then it became a storage issue. It was ahead of its time in terms of the technology—but the hardware and the infrastructure hadn’t been able to keep up with it.

That project had a dimension a lot of people who work in an organization don’t have to face: What do you do when the technology succeeds, but the project to install it fails?

With that project, the software got ahead of us, ahead of where the hardware was. The same can be said about any technology department within a corporation. Sometimes the department gets ahead of the company. That causes frustration: The technology staff can’t convince the business side of the value.

Once, at a mutual-insurance company, we were called in to fix a buggy system that kept track of its membership. The company had just given the project to a business-side guy who brought a number of businesspeople over with him. There were 65 people on the project and me—the only outsider.

We got into testing and began finding bugs. The business guy had trouble hiding his discouragement every time a new one was found. But when you move into testing, you only succeed by failing. You reward people for finding flaws. Still, he kept getting discouraged. He was being pressured. His bosses were rushing him. Then he did something that I’ve never understood. After another run-through that didn’t work, he said, “Why don’t we stop this testing and just put it in production?”—kind of like saying, “The plane doesn’t fly; let’s get aboard and go someplace.”

There’s not much you can say to someone who’s displaying that kind of flawed logic. It’s an emotional reaction. He didn’t see the progress. He felt he had no control—and, to be honest, he didn’t. I tried to explain, in terms he could understand, the rationale for finding the bugs first, and that finding them was actually a good thing: “You’re not putting the bugs there, you inherited them. We’re just tracking them down.”

But there was still a feeling of failure on his part. And this was a very bug-ridden system. In the end, of course, the system went up and the company could handle its members’ information; our success redeemed his “failure.”

You can’t fix everything. You have to have others to fix the problems and enable them to do it. A manager’s like a snowplow or a cowcatcher, clearing the way so the people who can do their stuff can actually do it. I can get the administrative and political junk out of the way, and leave them alone to do what they do. If you trust your people, and they’re good, they’ll succeed where others fail.