CIOs Uncensored: How Do You Calculate The Success Of An IT Project?
One way, according to the feds, is to redraw the rules. Is any IT project really successful according to its original goals?
How do you calculate success in relation to big IT projects? Two recent developments caused me to ponder that imponderable. The first is the Oregon state data center consolidation project that has been a heated topic of conversation in the pages of InformationWeek and on our Web site for the last several weeks (see "Data Center Project Scrutinized" ).
The second is two reports from the Government Accountability Office on the poor status of many federal IT projects, and a related Senate subcommittee hearing late last month. "Many agencies in the federal government are allowed to spend billions of taxpayer dollars on [IT] investments that are duplicative, lack clear goals, and are managed by unqualified staff," said Sen. Tom Carper, D-Del., head of the Subcommittee on Federal Financial Management, Government Information, Federal Services, and International Security, in a statement after the hearing.
In remarks to the subcommittee, David Powner, the GAO's director of IT management issues, said the Office of Management and Budget and federal agencies "have identified approximately 413 IT projects--totaling approximately $25.2 billion in expenditures for fiscal year 2008--as being poorly planned, poorly performing, or both." According to a recent GAO report, almost half (48%) of current major federal IT projects have been "rebaselined"--that is, their success metrics have been recalculated--and of those, 11% have been rebaselined four times or more.
As the report points out, rebaselining can be used to mask cost overruns and missed deadlines. Of course, there are legitimate reasons for rebaselining: inaccurate original information, inflation, change in funding, scope creep. Which of those apply to the Oregon data center project is the nature of the debate. What's clear is that the project is taking longer, and the cost savings aren't materializing as fast, as people thought. So, does that make it a failure--or a typical IT project?
According to one commentator to our Web site, known as DN: "Consolidation projects almost always fail if their goal is to save money. I work for a large company made up of several mergers and even after nearly a decade, it's still run like a bunch of smaller companies with separate systems." An explanation is provided by Nightshade_PA: "With any large, multidepartment consolidation, you will normally run into tension that can stall or even [cause the project to] fail if everyone that needs to have a vested interest in it does not fully participate." This is especially true when various departments have vested interests, instead, in prolonging their systems--like in Oregon, or any number of federal agencies.
Sen. Carper has introduced the Information Technology Investment Oversight Enhancement and Waste Prevention Act of 2008, which, among other things, would create an "IT Strike Force" with "the skills and background to help troubled agencies make better decisions," according to a statement from Carper's office.
Oregon might benefit from that Strike Force, as would more than a few private-sector organizations.
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.