Obamacare HealthCare.gov Issues Serve as a Reminder to Embrace Best Practices in Software Development and Integration Projects

Posted
By

October 1st marked the beginning of open enrollment for the federal and state health care exchanges (“Exchanges”) created to comply with the Affordable Care Act (“ACA”) of 2010, commonly referred to as Obamacare. The creation of the state and federal exchanges was and is a massive undertaking, involving the “unprecedented task of linking databases maintained by insurance companies, [and] states and federal agencies, including the Internal Revenue Service.” (“Obamacare Web sites see much interest, some glitches”, The Washington Post, October 2, 2013).

As anyone who has been involved in large scale IT projects knows, these types of projects invariably encounter glitches before they work smoothly, and the health insurance Exchanges are no exception. Many users of these Web sites encountered error messages or experienced significant delays when they tried to access the Exchanges to research their health insurance options.

Federal and state health officials initially blamed the delays on higher-than expected site traffic, and pointed out that any new technology is going to have errors at first that need to be corrected. But the Exchanges have been up and running for over three weeks now and issues remain, particularly with the federal exchange HealthCare.gov. Some specialists have suggested that extensive changes are required before the site will operate properly and that the repairs could take months. (“Contractors See Weeks of Work on Health Site“, The New York Times, October 20, 2013) The problems have created mounting pressure on the current administration, including plans for a congressional hearing later this month and calls for senior administration officials to lose their jobs. (“HealthCare.gov launched despite warning signs”, The Washington Post, October 22, 2013).

Indications at this point are that a number of missteps contributed to the problems with HealthCare.gov. During the 10 months prior to the October launch, the government changed the software and hardware requirements for the project at least seven times. (“Contractors See Weeks of Work on Health Site“, The New York Times, October 20, 2013) As of September, the government was still debating whether consumers should be required to register before shopping for insurance. (“From the Start, Signs of Trouble at Health Portal“, The New York Times, October 12, 2013) As late as September 26th, the system had not been tested from the end-to-end perspective of an individual trying to buy insurance on the site. (“HealthCare.gov launched despite warning signs”, The Washington Post, October 22, 2013). The federal government appears not to have followed a disciplined process in completing this project, which is a critical mistake that is all too common in these kinds of projects.

We outlined some of the elements of a more disciplined approach in our prior post [Obamacare: Meeting Implementation Challenges with Contracting Best Practices], including (1) a robust Implementation Project Plan to clarify the responsibilities of the parties engaged on the project, (2) the use of Critical Milestones to ensure that the contractor is delivering value during the course of the project and as a bright line test of whether the customer is entitled to exercise termination and other remedies, (3) requiring the contractor to pay Critical Milestone Credits as an incentive to stay on schedule, and (4) defining clear Acceptance Criteria to signify when a milestone has been met. For instance, if the federal government and its 55 contractors had adopted an Implementation Project Plan and strictly adhered to it, the government would have been forced to provide requirements earlier in the process, which would have permitted more time for developing and testing the code and may have mitigated some of the current issues.

The roll-out of HealthCare.gov is a good reminder of the types of things that can go wrong with large software development and integration projects. Although it is not clear whether contracting deficiencies contributed to the Exchange-related issues, below are some additional tools that a customer that is about to embark on such a project may use to prevent similar problems.

    • Clear Statement of Accountability – It’s critical that the contract accurately reflect the level of accountability that the customer expects from the supplier. In this type of transaction, this includes whether the supplier is being asked to be the system integrator for the project, responsible for making sure that all the parts of the system (some of which may have previously existed and others of which may have been developed by one or more suppliers) functions properly as a whole. Our experience is that many companies enter into contracts in which they erroneously believe that the supplier has taken on a broad level of responsibility (such as having overall accountability for a deliverable or system), when in reality the contract is not clear on this point. Customers should ensure that the contract reflects the level of accountability that they seek from their suppliers.
    • Testing – Complex integration projects require a robust testing regime, and this must be reflected in the contracts, project timelines and project resources. Testing will often occur in several stages, including unit testing, integration testing, system testing, acceptance testing, and performance testing. Although the details of testing plans and “use cases” can often be developed after contract execution, the types of testing to be performed should be set forth in the contract. The contract should also clearly define the testing responsibilities of each party at each stage of testing. The project plan should reflect the testing periods as well as time to correct deviations from the specifications (non-conformities) identified by the testing. Tying payment milestones to the successful completion of testing stages can help ensure that testing requirements are given proper attention.
    • Warranties – Customers should ensure that the contract contains a meaningful set of warranties so that the customer has recourse if problems arise. These warranties are part of documenting the desired level of supplier accountability discussed above. The warranties should include:
  • General Warranty – Software developers and contractors generally propose to warrant that the software system will operate in accordance with all material aspects of the requirements and specifications (or documentation). This is not sufficient. The warranty should state that the software system will operate in accordance with the requirements and specifications in all material respects. The difference is subtle yet important, as the software should meet all the requirements and specifications, not just those that are material. Presumably the customer believes all of the requirements and specifications are material, or they would not have included them in the first place.
  • Duration of the Warranty: Implementation and Post Production – It is important that the warranty be in effect not only after the implementation is complete, but during the implementation itself. This is because the customer will be expending valuable resources operating the software in development and test environments during implementation, so the software needs to operate properly during that time in order for the work to be productive. It is also important that the warranty be in effect for some period of time after commencement of production operations, so that the system is tested in “live” circumstances with actual loads, so that all problems will have a chance to surface and the customer have an opportunity to have them fixed under the warranty.
  • Scope of the Warranty – If a customer wants its supplier to take full accountability for the success of a project, the supplier must have control over the full implementation. That is, a warranty can only be as broad as the scope of responsibility that the supplier is given. This may require that the customer give up control over aspects of the project in order to obtain the warranty that the system will perform in accordance with its requirements and specifications.
  • Other warranties – The customer may also wish to include other warranties regarding the system, such as a warranty that the system is scalable to some level of users, or that, assuming a certain hardware and operating system configuration, the response time will not be greater than X.
  • Post Acceptance Obligations – It is important to note that the supplier’s obligations do not end with acceptance of the system by the customer. Although meeting the acceptance criteria may obligate the customer to accept the system and trigger payment obligations, such acceptance should not relieve the supplier of correcting any remaining non-conformities. For example, the acceptance criteria may require that the system be free of programming errors that create a Priority 1 or Priority 2 incident. At such time that the system satisfies such requirement, the customer may be obligated to accept the system, but the supplier should remain obligated to correct any Priority 3 and Priority 4 non-conformities. Typically these would be documented and a schedule created for the supplier to fix them. Or the minor issues may be left to be resolved in the next update of the software.

The issues arising in connection with the roll-out of HealthCare.gov demonstrate the need for companies to be careful when entering into contracts for large scale development and implementation projects, and the foregoing tools will help to provide the type of protection needed for these transactions.