5 Things to Learn from the HealthCare.gov Website Problems

Channel surfing the other night I came upon the C-SPAN video replay of the congressional testimony regarding the Healthcare.gov website.  Thinking about all the testimony and the political partisan points I was amazed at the project planning comments, lack of understanding of the technological problems, and number of issues that were discussed.  As a consultant fixing architecture, aligning strategies, and fixing performance problems, I thought of the ten things that we all might learn from this website situation or any problem project that has these types of issues. Here are the first five:

1. Projects need a leader/responsible party.  The first thing that hit me during the testimony was that the website didn’t seem to have a single vision of how it was to work, a leader to champion that vision, or central responsible firm to make sure that vision was translated into reality.  While big projects can take on a life of their own, having a central vision, corporate sponsor, and prime leader for any project is vital.  While you may say the project leaders, database administrators, and developers should have known their project objective, leadership needs to communicate it very clearly and delegate explicitly the responsibilities for getting each piece to work.  If everyone points to the person to their left as the responsible party, no one is responsible.  Someone or some firm needs to be supreme leader or visionary with the clear statements of the objectives, technology, and methodology for success.
2. Too many chefs in the kitchen.  Complexity kills projects. Having to interface with all the states, all the health care providers, and various complex health care coverage options, it seems that there were too many chefs and not enough cooks.  The number of contractor firms involved with the project alone as documented shows an extra management layer, adding to the structure of complexity. A project with a variety of interfaces and types of processing for each of the different levels of management, a number of levels of processing, project creep, too many managers, and not enough testers and developers will always end badly.  Proper strategy and architecture with correct ratios of management, DBAs, testers and developers is always vital to success.
3. Too many technologies result in confusion.  According to auditors of the Healthcare.gov project and some news reports estimates are that there might be 500 million lines of code.  While this is probably an over-estimation, it shows that too much code or bloated code is bad.  I would venture to guess that different states aren’t on even the same versions of some of the basic packages or programming languages that they are using.  Also, the different states are said to be using Java, but there are hundreds, if not thousands, of paid software packages along with all the open source packages available, that the states are probably leveraging.  Mixing and matching all types of technology leads to compatibility issues that need to be tested so the system can be normalized to a single version and software release. Having a single simple technology strategy, architecture and development environment is critical for success.
4. Integration is hard.  According to news reports, Healthcare.gov is interfacing with many other government agencies.  Integrating even a single interface is difficult. When the number and different types of interfaces, and different levels of data types increase, the integration efforts and difficulties expand exponentially.  Keeping the integration points to a minimum or standardizing them into a services oriented architecture is part of the current industry best practices.  This situation is further testimony and proof to everyone why following best practices and a simplified architecture should always be your starting point and central goal for all projects and development efforts.
5. Testing needs to start early and often.  Projects are always in a rush and there is never enough time.  Also, generating good test data is always difficult. With the number of states, the number of interfaces, the number of companies, and their number of different variables the difficulty increases.  It’s understandable why testing started late.  Data modeling, data validation, data lineage, and data quality will continue to be critical for development of a successful test plan. Starting testing early is always the best plan for getting it right.
   As the project involves more developers, more issues to be resolved, or more interfaces, these points become more important for success.

Next week I’ll talk about five things that we all might learn from this website situation or any problem project that has these types of issues.