Back to articles
Search for:
2 Ways to Avoid HealthCare.gov’s Custom Software Mistakes

clipart-red-flag-6654In many ways HealthCare.gov was different than software projects most companies undertake; however, there were two common mistakes that can occur when companies develop custom software systems of any size.  If the project managers had identified and handled these red flags, we might not be writing about the problems with HealthCare.gov’s launch.

1. Coding started too late because they waited for “complete” requirements.

The original HealthCare.gov project was awarded in 2007 without complete requirements, and it sounds like requirements were continuing to be defined up until the month before the initial launch date.  Ongoing changes and additions to requirements are typical and can be managed.   What made requirements for HealthCare.gov a problem is that an “old school” software project approach was used.

In the old days of software development, the complete requirements (and a lot of other things) had to be “finalized” before coding could begin.   Because this approach resulted in many over budget, late projects, things changed.

Now we know that requirements are never 100% complete.  As people use a system, they figure out more about how it needs to work (or how it should not work), and so we’re realized that the key to a successful software project is to get working code into the hands of the stakeholders as early as possible.

This means that successful software projects start coding well before requirements are fully defined.

Here’s how it works.  Based on a high level overview, the system is broken into modules that can be defined and coded in a maximum of 3 months each.   As soon as the first draft of module one’s requirements are ready, the developers begin coding.  As each part of the module is coded and tested, it is deployed for stakeholder testing.  Using the system early in the process allows stakeholders to make better decisions about what works and what doesn’t, and their feedback is incorporated into future work.

To avoid one of the problems HeatlhCare.org faced, break your system into modules, and start coding as soon as the first module is at least 80% defined.

2. The primary vendor had a mixed track record for similar projects.

To avoid the time and cost of finding, hiring, and managing expensive software development team members for one project, many companies take the approach used with HealthCare.gov and hire an experienced software partner.  If you do your homework, this can be an excellent business decision; if you don’t fully research each potential vendor, you can end up with a system that is delivered late, exceeds your budget, and doesn’t meet your needs.

According to the Washington Post article “Meet CGI Federal, the company behind the botched launch of HealthCare.gov” (October 16, 2013), the primary contractor (CGI) had completed some successful software projects; however, the Post reported that CGI had done such an unsatisfactory job on an Ontario health care software system that the $45+ million project was scrapped after three years of poor performance including missed deadlines.  (http://www.washingtonpost.com/blogs/wonkblog/wp/2013/10/16/meet-cgi-federal-the-company-behind-the-botched-launch-of-healthcare-gov/).

When you’re choosing a software partner, look carefully at the partner’s past projects.  Interview the vendor’s software project managers who will be working on your project.  Invest time in talking to the vendor’s references, especially those whose projects were managed by the same people who’ll be working on your system.  If there are red flags, investigate them in detail, but if the vendor has 100 successful projects and one that failed, the failure may have been due to circumstances outside the vendor’s control.

Buyer Beware:  it’s really, really important to talk with the people who will actually be working on your project.  After an extensive bidding process, the parent company for one of our clients selected a large well known company (who will not be named) to implement a very large, expensive ERP system throughout its operations in the US.  The decision was heavily influenced by the A team that did the presentation, but the people who were actually assigned to the project in our client’s office were from the Z team (not even the B or C team), and the project was a disaster.  Don’t let that happen to you!

When to worry – or not

If your company needs custom business software, don’t stay awake at night worrying that your project will turn out like HealthCare.gov.  To improve your chance of success, break your software system into manageable modules and carefully evaluate your alternatives for a software partner.

Your custom software project CAN be successful if you learn from HeatlhCare.gov’s mistakes.