The news seemed numbingly familiar. "State delays $150 million computer project," read a headline in the April 12 Wisconsin State Journal. Reporter Jason Stein put it in the context of an ongoing series of botched state computer projects that have cost taxpayers nearly $200 million in canceled or over-budget projects.
In fact, delaying the project - the Department of Administration's Integrated Business Information System, or IBIS - may have been the smartest thing to do.
True, the department had already spent $11 million on the project to replace aging systems for accounting, payroll and other services. But the delay is merely a "mid-course correction," says Oskar Anderson, the department's chief information officer.
"We were at a point where we were ready to start spending money" - i.e., the rest of the project's budget. "It was the right point to make that decision." Work on the project will wait until at least July of next year.
In short, the IBIS project is late, but not yet a catastrophe, as was the $26 million email system the state abandoned two years ago. That speaks well for the reforms introduced by Anderson, who in an October 2007 report outlined ways the state can better manage its software projects, including standardized planning, better documentation and close monitoring.
Still, recent delays and overruns in computer projects involving the UW System and various state agencies - motor vehicles, corrections, revenue, workforce development and health, among others - reflect a dirty little truth of information technology:
Computer projects bomb all the time.
Indeed, the Legislative Audit Bureau found that, among 103 recently completed state software projects, 24 were over budget and 45 were late.
"There are many horror stories in the IT industry," says Rafael Lazimy, a professor of operations and information management at the UW's business school. "[They involve] failures, cost overruns, not meeting schedules, not meeting expectations, in both private industry and government."
The good news is that, on the whole, more software projects are succeeding, according to the Standish Group, a research firm that tracks the technology industry. The bad news? Even with this improvement, 19% of software-development projects fail outright.
Frank Albi also has seen software projects veer off course, as did IBIS. When this happens, the president and chief operating officer of Inacom Information Systems, a Madison IT consulting firm, heeds a simple rule.
"Call a time-out," he says. "Stop, pause, analyze. What is it we failed to see? We're under way, so retreating may not be an option. Holy cow, we missed something that's big."
The better developers plan their projects, says Albi, the more likely they will avoid time-outs: "When you don't take the time on the front end, it becomes chaos."
Albi adds that, when it comes to IT, government operates differently than private industry. The UW's Lazimy agrees.
"In government, many projects suffer from lack of good project management," says Lazimy, speaking in general terms and not with regard to the specific problems of Wisconsin.
Government workers, he explains, sometimes do not follow proper IT practices, like setting milestones and scheduling formal reviews. And government developers may be less likely to identify problems when they arise: "Nobody takes charge because nobody wants to be labeled as having failed."
Also, "Sometimes, there isn't a clearly defined leader who takes charge and eventually makes decisions. Sometimes in state agencies you have a system development team, and they use management by consensus. That can lead to many problems."
That's why Anderson of DOA recommends that for any given project, the government should identify a project manager. "It's more likely, in private industry, to have executive sponsors with wide-ranging authority," he says.
Lazimy puts it another way: "System development is not a democracy."
If it is completed, IBIS will replace as many as 100 government systems, some of which date back to the 1970s. A so-called enterprise resource project, it will consolidate administrative systems dealing with finance, accounting, payroll and order entry.
These existing systems are now working. So why replace them?
For one thing, says Anderson, systems like IBIS are increasingly seen as "a cost of doing business," in both the private and public sector.
For another, there are fewer and fewer IT workers who understand the old systems. The state's payroll software is a mainframe application written in COBOL, a nearly 50-year-old language that, like Latin, is taught less.
Also, modern applications are easier to change, which is especially helpful to government. "As statutes change, systems change," says Anderson.
Above all, a single system is more readily managed than the hodgepodge of programs IBIS will replace. These include small spreadsheet applications, which are among the hardest programs for IT staffs to manage.
All that complexity makes for difficult planning, and developers, whether private or public, can't anticipate every wrinkle. Anderson compares his work to that of road builders.
"Road construction contracts anticipate you can't control everything, like the weather," he says. "But we have this expectation that [in IT planning] we have done a perfect job of speccing out the work, that things aren't going to change."
Anderson suggests that's simply not realistic: "Big projects run into problems, period."
The difference with state IT projects, says Lazimy, is that the public is watching: "You don't hear of all the failures that happen in the private sector, but failures happen a lot in IT."