Big IT: Doomed

Big IT projects are doomed. Want proof? Just look at the four-year, $100 million-plus project to rebuild the air-travel reservation system run by Sabre Holdings Corp. . Sabre's decades-old system was 10 million lines of mainframe assembly language code. The new version is C++ and Java running on 17 HP NonStop database machines and 45 Linux servers -- which means everything is getting overhauled. And halfway through the project, it's all working.

So how does this big -- and successful -- IT project prove that big IT projects are doomed? It became successful only because Sabre stopped running it as a big IT project.

See, Sabre has tried to overhaul its reservation system before -- most infamously from 1988 to 1992, when it spent $125 million on a megaproject to do just that. This was Sabre's giant leap into the future. Project architects polished the design down to the last interface and buffer. Project managers broke it into manageable pieces to be built in parallel, just the way the experts said it should be done.

After three and a half years of development, the pieces were put together into a finished system. It didn't work well. Three months before the project was set to go live, with partners like Budget Rent A Car and the Hilton and Marriott hotel chains waiting to use it, managers began to realize the problems might not be fixable.

A few weeks ahead of the promised completion date, Sabre had to junk the entire system.

Now that was a big, doomed IT project. And for 10 years, it spooked Sabre away from anything that big.

So what makes this new four-year, $100 million-plus success different from that old four-year, $100 million-plus catastrophe?

This time, it wasn't a big leap. Borrowing techniques from so-called agile programming, Sabre did it as a series of small steps.

Because of that, the project's architecture has already changed twice so far. Originally, all the mainframe functions were going to be ported to the fault-tolerant NonStop servers. As the project progressed, some of those functions were shifted to Unix servers. Then they were moved to Linux. And the data-replication system was also rearchitected midstream.

As a result, the system already looks a lot different now than the design did in 2001, when the project started. Small steps -- and a willingness to change direction -- make that possible.

Small steps also make it possible to respond to changes in technology. That's why Linux, which didn't look like a viable option in 2001, could be brought in later in the game.

And small steps make it possible to go live with each iteration of the system before moving forward -- to make sure the technology works and to make sure the system is what users need. If it's not, it can be changed.

That doesn't sound like a big IT project, does it? Everything we expect from a big IT project is missing: the grand, detailed plan; the divide-at-the-start-and-integrate-at-the-end strategy; the years-before-it-goes-live schedule.

That approach has doomed big IT projects for generations. It had too much risk built into it, requiring too many predictions in the face of too much change -- and depending on too much perfection in execution.

Now that approach itself is doomed. There's no longer any justification for putting a major project at risk with a traditional big IT project approach. We know it doesn't work.

And we know what does work. We've seen it at Sabre.

So don't fear big, doomed projects. Break them down. Take them live as a series of small steps. Change your designs in response to new technology -- and as you go, make sure they work.

That way, no matter how large they get, your IT projects never have to be doomed again.

Frank Hayes, Computerworld's senior news columnist, has covered IT for more than 20 years. Contact him at frank_hayes@computerworld.com.

See more Frankly Speaking columns.

To express your thoughts on Computerworld content, visit Computerworld's Facebook page, LinkedIn page and Twitter stream.
4 high-growth tech fields with top pay
Shop Tech Products at Amazon