If the tech profession is to stop making the same mistakes, it must share its worst practices. We're all ears.
Every IT pro loves a good disaster story, as long as it's not autobiographical. Not so much the data-center-buried-in-a-mud-slide kind of disaster. Nor tales of how power outages, cable breaks, hurricanes, and other extraordinary events wreaked havoc on an IT operation. The most intriguing IT debacles are acts of inexperience and incompetence, not of nature or other external forces.
Sure, anticipating the worst calamities requires great IT skill and foresight, but we can be forgiven if we haven't built in--or, more likely, couldn't get the funds to build in--fail-proof contingencies and redundancies. On the other hand, pity the IT management team that oversimplifies the technical or operational complexity of a project, puts way too much faith in its vendors, plows ahead on a major initiative without involving users or locking down the full support of the honchos, or refuses to change course when problems dictate otherwise. We're talking about projects that spiral out of control--well past deadline and over budget. Applications and architectures that grossly underperform on their promise.
You probably know something about the highest-profile tech disasters. There was the IRS's Tax Systems Modernization, a multibillion-dollar project launched in 1986 that languished in bureaucracy and the absence of accountability for well over a decade. In the mid-'90s, you couldn't swing an embattled CFO without hitting a public company that blamed its disappointing financials on an ERP implementation gone bad, but vendors SAP and Oracle were often made the scapegoats, not the companies' own IT organizations. Inventory management problems experienced by Nike in 2001 were the subject of much media scrutiny, mostly because Nike's high-profile CEO, Phil Knight, threw supply chain software supplier i2 Technologies under the bus, blaming it for all sorts of fiscal shortfalls. I2 then pointed the finger back at Nike, claiming it was the one that screwed up the implementation. More recently, the FBI's Virtual Case File system, a $170 million project launched after 9/11 to make it easier for agents to share information, languished in bureaucracy and the absence of accountability until it was shut down in early 2005. Sound familiar?
It's tempting to chortle at the tech neophytes--those poor government agencies and manufacturers that haven't got a clue. But tech disasters also are a tech company phenomenon. Cisco infamously had to write down $2.2 billion in excess inventory in April 2001, just after the dot-com bubble burst, after realizing that its demand forecasting systems had been telling it to make way too much product. Government regulators had to force CA to get its IT house in order. As part of the accounting-challenged software maker's settlement with the Justice Department and Securities and Exchange Commission last year, CA is required to overhaul and consolidate its myriad ERP systems, a $100 million project being undertaken with SAP and Accenture to make transactions and financial reporting more transparent internally and to auditors.
But for every FBI, Nike, and CA tale of tech woe, there are probably 100 similar disasters no one but the insiders know about. Something like a third of all IT projects are canceled or never implemented, according to various surveys, while another third to half fall behind schedule or go over budget.
Readers have told us: Show us what not to do; don't just regale us with best practices. If the IT profession is to stop making the same mistakes, it must share those worst practices.
Here's a start: InformationWeek is preparing a series of stories on the worst tech disasters--not to single out individuals or embarrass teams, but to relate cautionary tales about how not to manage large-scale projects. But we need your help: Tell us about the tech disasters you've experienced or heard about from colleagues over the years. Some InformationWeek swag is in the offing for the best leads. Drop us a note at the e-mail address below.
IT's Reputation: What the Data SaysInformationWeek's IT Perception Survey seeks to quantify how IT thinks it's doing versus how the business really views IT's performance in delivering services - and, more important, powering innovation. Our results suggest IT leaders should worry less about whether they're getting enough resources and more about the relationships they have with business unit peers.
What The Business Really Thinks Of IT: 3 Hard TruthsThey say perception is reality. If so, many in-house IT departments have reason to worry. InformationWeek's IT Perception Survey seeks to quantify how IT thinks it's doing versus how the business views IT's performance in delivering services - and, more important, powering innovation. The news isn't great.
InformationWeek Must Reads Oct. 21, 2014InformationWeek's new Must Reads is a compendium of our best recent coverage of digital strategy. Learn why you should learn to embrace DevOps, how to avoid roadblocks for digital projects, what the five steps to API management are, and more.