Working on the railroad

I work for a large railway company, and in the past 10 years I’ve witnessed some IT catastrophes that bake my noodle. One of the worst was a $30 million project to develop a software system that controls and tracks how we plan trains, put them together, and move them into and out of our yards. Someone decided to purchase the rights to a system that was in development by another railroad, Kenosha Southern, which we would then customize and redevelop for use within our own environment. This made a perfect fit with our recent adoption of a “buy don’t build” philosophy, and would save us big money on development costs.

Free IT resource Hear how top CIOs turn change into a competitive advantage. Sponsored by HP Free IT resource TechNet: More ways to know it, share it, and keep it running. Sponsored by Microsoft

Or so we thought.

After a number of changes at the upper levels, an external contractor took over the job, personally billing $2.5 million over the course of the project -- and that didn’t include overtime and travel. His primary agenda seemed to be building walls around deliverables, and refusing to make trade-offs between sub-projects for the greater good of the undertaking.

To make matters worse, halfway through the project someone realized that although grain shipments made up approximately 25 percent of our revenue, no one had interviewed the grain group or had taken the time to understand the peculiarities of shipping grain. Only a major infusion of cash and a slip in deadlines allowed us to fix this, and similar problems occurred in almost all of our major lines of business. In fact, no one seemed to be representing any of the business groups involved in the requirements and development process.

Around this time we sent a few IT troopers down to KS to see what was going on. It was the last point the project could have been killed or redirected, so I checked in with my friend Michael, a savvy project-management contractor. He did an analysis comparing the functionality and cost of reinventing the system in house with modifying the business processes involved in the KS model; KS’s business processes were very different from ours. Michael calculated that if we continued with the collaboration as planned the price would not be $30 million or even $60 million. It would be closer to $70 million. The cost of developing a new system from scratch -- one that would perform the same functions as the KS system and be properly designed for our business groups -- would only run about $45 million.

Ultimately, my friend presented his analysis to the VP of IS. When he finished, the VP asked, “Have you shown this to anyone else?”

Michael, who is politically adept, said, “Absolutely not, you’re the first person I’ve shown this to.”

“Well,” said the VP, “you’d better not -- ever -- if you want to keep your job.”

To make a long story short: Our company went ahead with the original project -- and Michael was amazingly accurate. Officially the project ran $50 million, but when you add training, change management, and lost productivity the number rose damn close to the $70 million he predicted. We brought the system up over a very protracted implementation phase and are currently kicking off a project to “enhance” it. Does anyone hear $90 million?