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.