Can the government sue over Obamacare disaster?
An organization's costly, ballyhooed strategic plan crashes and burns when its new computer systems fail. Service outages and other mishaps lead to seething customers, overwhelmed employees and gloating competitors. In the meantime, a CEO is under siege as his hoped-for signature achievement becomes a technology nightmare.
Barack Obama, meet corporate America. With the disastrous rollout of the Affordable Care Act, President Obama has joined the ranks of the many chief executives whose turn-around plans have been stymied — or, in some cases, smashed to bits — by a failed software implementation.
Numerous firms and their CEOs have been buffeted by difficult — or, as with Obamacare, catastrophic — software projects. Touted as sure-fire revenue boosters and cost savers, IT projects often fail to deliver the return on investment that lead companies to pay consulting firms tens of billions of dollars to roll out new software. The promises of increased efficiencies, reduced headcount and improved customer service are frequently unfulfilled. Projects are not completed on time or on budget, draining capital and morale as the expensive new computer system turns out to be scarcely better than the old warhorse it replaced.
Far worse are the situations where new IT rollouts bring a company to its knees as coding and interface defects make a hash of ordering, shipping, accounting, procurement and inventory. This is the IT nightmare scenario that the White House is now confronting, in real time, with the Obamacare debacle.
(Read more: Obamacare website down again)
Like many a CEO before him, President Obama needs to get to the heart of the problem — and fast. In my experience, having successfully represented companies and public entities for the last 15 years in litigation over failed software projects, there is a reason why these projects go off the rails. IT projects often become train wrecks because of critical errors made by the very vendors paid huge fees to put the systems together.
Indeed, some of the leading IT players — SAP, IBM, Accenture and Deloitte Consulting — have been sued over failed software projects. Such suits typically allege that to land these lucrative engagements, vendors misrepresent their consultants' skills. The project is then allegedly doomed when inexperienced consultants make design, coding and testing errors. The software firms respond by blaming the client, alleging it was the client's responsibility to manage the project, test the system, decide when to go-live, etc. Sound familiar? Almost all of these cases settle before trial.
As the administration and congressional investigators look for culprits, they should focus their attention on the following issues, which can place software projects at serious risk.
Deficient project management. Consulting firms pocket huge fees for these projects, deploying armies of workers who sometimes spend years on-site. When projects fail, dreadful project management is often why. On the Obamacare project, was an appropriate implementation methodology deployed and adhered to? Were the proper protocols in place to track, guide and evaluate the process as it moved through the design, configuration, coding and testing phases? For its part, did the administration ride shotgun on the vendors — or was it an episode of "Consultants Gone Wild?"
Deficient staffing. Did the administration get the A-Team the rollout required? For $600 million in fees, did the vendors supply skilled consultants who understood the claims- processing industry and the corresponding business processes? Were they competent to not only write the functional specs and code, but also to build the web of interfaces linking together system components? Or did a consulting firm attempt to leverage a handful of skilled consultants over busloads of "newbies" tasked with building the system?
(Read more: EHealth CEO: Let us fix Obamacare website)
Deficient testing. The fail-safe of any software project is the testing phase. Appropriate testing can, and must, flush out coding and other defects before the go live. Was robust testing performed prior to the Obamacare go-live? Or, as is often the case on failed projects, did the vendors cut corners, or deliberately under-test the system, to ensure artificially positive results in an effort to conceal problems? Did the administration accede to truncated testing to hit a carved-in-stone go-live date?
Deficient quality control. Consulting firms are hired to be on the lookout for project risk — to identify, manage and mitigate it. Did the Obamacare vendors identify project risks? If so, who in the government did they warn? Or, as we often see on failed implementations, did the consultants sugarcoat or conceal project risk? Did they recommend a risk-mitigation plan, such as beefing up the team or adjusting the timeline? Did the administration, intent on going live as scheduled, ignore show-stopping risks?
At this early stage, it's difficult to know where the blame lies. But one thing is certain: This implementation fiasco was badly managed. Knowing what questions to ask, and where to look for answers, will be the first step in determining not only how to proceed with an effective remediation plan, but also whether the government can seek recovery from consulting firms that reaped big fees on another failed IT project.
— By Mark P. Ressler
Mark P. Ressler, a former federal prosecutor, is a partner at Kasowitz, Benson, Torres & Friedman LLP in New York who specializes in software litigation.