When IT Attacks: Disasters of the Technology Kind
February 14, 2011 Alex Woodie
|
There are nature-made disasters, such as hurricanes and earthquakes, and there are man-made disasters, such as revolutions and war. In either case, an IT department will go into disaster recovery mode to get its organization back up and running as quickly as possible. But what happens when the disaster is of IT’s own making, such as the debacle unfolding in California, where a decade-old project to install a case management system has spiraled out of control, and now carries a $2 billion price tag? In such cases, the pain goes on and on. So California is in the news again for screwing itself up and putting taxpayers on the hook for billions of dollars. You can laugh if you want (or cry if you’re from here). But for anybody in the IT profession, there is a lesson to be learned from the ongoing implementation of the California Court Case Management System, which was the subject of a scathing 143-page report released last week by state auditor Elaine Howle’s office. The report takes the state’s Judicial Council to task for the CCSM project, which began in 2001 with the aim of uniting California courthouses onto a single system. The project uses a wide variety of components, including database and presentation servers based on Unix and Windows; WebSphere and WebLogic application servers; a TIBCO messaging layer; and various connections to email servers, directory servers, and other components. The CCSM is huge IT undertaking, with sprawling modules intended to serve millions of judges, clerks, lawyers, plaintiffs, defendants, and witnesses who use the state court system every year. It is supposed to drastically reduce the reliance on paper-based documents and the manual-intensive work that goes into filing and indexing all that paper. This ambitious project was originally slated to cost $260 million, and be complete in 2009. However, based on the project spending to date ($460 million) and the lack of progress (only a handful of courthouses are using the new system), Howle’s office predicts that it will take at least another five years, at a total cost of $1.9 billion, to complete the project. Howle wants to put CCSM on hold until third-party consultants can conduct a cost-benefit analysis and figure out how to salvage the project. Not surprisingly, the Judicial Council contests these findings, says the project is on track, and will be completed for a mere $1.3 billion (or a paltry $1 billion over budget). The causes of the difficulties with the CCSM will sound familiar to industry consultants who have struggled through nightmarish ERP implementations. The number one culprit, of course, is poor planning. The lack of foresight manifested itself in several ways, including misunderstanding the needs of the constituents, the courts; not conducting thorough cost-benefit analysis; not following consultant recommendations; and a lack of buy-in by the users. If the courts in California are anything like those in other states, some them are running old AS/400-based case management systems. Some of the courts in California have expressed their disdain for the CCSM, saying their old legacy systems work just fine, thank you very much, and they don’t have a need for a new integrated system. Without the support of these courts, the CCSM project will never achieve one of its main objectives, which is better sharing of information among the different constituencies. Anybody involved in a long and painful ERP implementation can take solace with the plight of the California CCSM. While bungling, overpaid bureaucrats are infamous for botching big IT projects, enterprise software installs in other sectors can also go haywire. Take for example the case of Sutter Health, a non-profit chain of hospitals serving Northern California (yes, we are picking on the Golden State today). In 2007, the chain of 26 hospitals put the brakes on an implementation of a new electronic health record (EHR) system from Epic Systems after it had already spent about $500 million on the project. The organization, which adopted the IBM i-based MedSeriesIV healthcare information system (HIS) from Siemens in the mid 1990s, announced last year that it would put an additional $400 million into the Epic project, with expectations of a full-roll out by 2015. The longer-than-anticipated Epic implementation at Sutter–as well as the Epic implementation at Kaiser Permanente, which is reported to have cost $6 billion–caught the eyes of other hospital IT executives across the country. One of those who were unsettled with the big numbers and questionable payback was Gene Grochala, the CIO of Capital Health, a small hospital network in New Jersey. Grochala offered his opinion on Sutter’s EHR transition in a 2009 interview with the HealthCare Informatics publication. “There’s no way we’re going to do that,” said Grochala, who became a big supporter of the System i server and its no-frills, fiscally practical nature following the 2007 transition of Capital Health to an i5/OS-based HIS from Keane. “Quite honestly, there’s no way you could ever get any ROI on something so massive. I agree you need an EMR, but at what price, $10 million, $50 million, $100 million, when it’s just not there? You’d be better off to hire 1,000 clerks and buy 1,000 PCs and type everything in,” Grochala said. Just as the CCSM implementation is supposed to improve the legal system, the Epic installations at Sutter, Kaiser, and other hospital networks are supposed to improve the medical system for patients. Epic, which is considered the gold standard of EHR systems, touts its capability to increase efficiency, lower costs, reduce medical errors and administrative overhead, and make information available more quickly. In a perfectly “green field” world, it’s probably fairly straightforward to implement Epic. But when integration with legacy systems come into play, the number of variables starts to go up dramatically, and the “gotchas” start multiplying. Large governmental institutions (like the court system) and pseudo-governmental organizations (like hospital networks) are less nimble than their private industry counterparts, more isolated from market forces, and more prone to just slog their way through a difficult and expensive project. Cost overruns are covered by taxpayers. No private company could take this unlimited-budget approach without a revolt from shareholders. Companies in the private sector try to avoid IT disasters by doing everything they can to minimize risk. They scale back the size of IT projects, starting small and growing slowly; the “big bang” implementation is practically dead. They modify existing systems to get more functionality out of older investments, and emphasize those old IBM i traits of practicality and efficiency above the glitz and glamor of shiny new objects. And last but not least, they adopt agile computing methods, which keeps open a continuous line of communication between developers and users. As long as there are computers, there will be IT disasters. IBM i shops would seem especially prone to IT disasters of the migration kind, considering all the companies and governmental groups that are looking to move off the platform. These organizations may be in for a rude shock when they find that their shiny new applications require a lot more upkeep and hand-holding than the “old” system they were hoping to replace. Hopefully, the pain doesn’t last as long for them as it will for California.
|
