15 Questions Congress Should Ask Obamacare Healthcare.gov Website Contractors
What Congress Should Ask to Find Out Why Healthcare.gov
Failed After $600 Million Invested in 3 Years
In the wake of the Epic Fail of the government health care website healthcare.gov, the House Energy & Commerce Committee of United States Congress will conduct a hearing on Capitol Hill today with the website contractor on deck to testify in an attempt to determine what what went wrong with the website with a budget of over $600 million dollars and approximately three years to build.
As a veteran in the web industry, having led the creation of a highly complex $1 million dollar budget website in the 1990’s that integrated creation of user accounts, real-time inventory, complex image databases, a Flash ‘room planner’ with accurate representation of items in savable “rooms” for customers – in less than 6 months (and many websites since), I believe the emphasis on mere “testing” is misplaced. By the time you get to testing, the cake is baked, so to speak.
What Really Caused the Epic Fail of Healthcare.gov ?
An Epic Fail of this magnitude appears to be victim to a myriad of problems, the least of which is failing to meet the demand of an influx of visitors – illustrated by reports that traffic has reportedly dropped 88% since launch, and successful enrollment of a mere 1% of visitors.
If healthcare.gov , the public website, as the “face” of the complex Affordable Care Act has failed, a careful look should probably also be taken at the infrastructure of the overall program.
Failure in Quality Testing Usually Represents Failure in Planning
As any professional website producer will tell you, planning is website key. Without clear requirements, resources and direction from the client (internal or external), the vendor is left to interpret and guess. The ownership of the vision and key performance objectives must come from the party the website was built for – whose success depends upon the performance of the website.
Website requirements should be clearly articulated as a list of features, data sources to be included, personification of website audiences and how they will use the website, a site map (even if rudimentary) which would evolve to schemas, identification of ‘hooks’ to and from various other data sources, and clearly defined KPI’s (key performance indicators) that will be used to measure performance of the website. Website planning should include compensation for infrastructure of hardware, bandwidth and customer support to serve the highest-possible influx of visitors, queries, accounts generated and successful account access by registered members.
Last, but not least, the one person on the Client ultimately responsible for managing the Vendor (the project manager) must be accountable to insure both parties are communicating clearly, meeting benchmarks and on track for on-time, on-budget delivery – without exception.
KPI’s for Healthcare.gov could (or should) have looked something like this:
- Goal: Serve “__x__” (number) of estimated website visitors (must exceed maximum expected to serve).
- Goal: Facilitate “__x__” (number) unique visitor.
- Goal: Provide redundancy and co-location to serve “__x__” (number) visitors across U.S. at one time.
- Goal: Facilitate creation of “__x__” (number) of accounts generated.
- Goal: Allow plan comparison.
- Goal: Facilitate surges of traffic as high as “__x__” visitors per hour.
- Goal: “__x__” (number) of completed applications (by defined timelines).
- Goal: “__x__” (number) of successful enrollments (by defined timelines).
The 15 Questions Congress Should Ask:
1. Who provided website requirements?
2. How were website requirements communicated by the Client?
3. When was the website plan/schedule/budget approved by Vendor and Client?
Changes Impact Delivery
Some level of changes can be expected. A website can take months to create. Anything over twelve months should raise a flag. First, because the technology has likely improved, offering more efficient or effective methods to achieve project objectives; Second, a website should never take more than a year, even when complex databases, custom applications and testing are involved. If modifications to the requirements occur, a ‘Change Order’ must be issued, and could (but does not always) impact budget and timeline.
What Should Congress the Website Vendor?
4. What was the original timeline for the initial scope for the website?
5. What was the budget for that initial scope?
6. Was a ‘Change Order’ issued, and if so – when?
QA (Quality Assurance) is Vital to Success
Every website must go through a period of testing. Professional web developers have teams dedicated to testing and attempting to “break” the website well in advance of launch to identify “glitches” that must be addressed, and insure delivery of a quality website to the client.
The Questions Congress Should Ask:
6. How much time was allotted for QA testing?
7. Did any action or decision by Client or Vendor impact quality control?
A Website is Not a Fete of Technology – It is a Vehicle for Interaction With Humans
The website is not a conglomeration of computers and code. Website architecture, user-path, security, UX, design, content, database integration, user accounts and communications should always be guided by the desire to provide a quality user experience to website users. Yes, even when the website comes from the government.
The ultimate goal of a website is to convert visitors to “customers” (in this case healthcare plan participants). Without specific focus on the entire life cycle of the user experience, the website will become obsolete, or worse yet – completely fail to deliver its reason for being.
The Questions Congress Should Ask:
8. How were the Client’s website “mission” and stated goals for the website, including benchmarks communicated – who was the project manager responsible for related communications between Client and Vendor.
9. Outline all planned customer user paths on the website – including account verification, data security, communications (email/snail mail, etc.), and integration between healthcare.gov and how the role the website plays in the overall administration of the Affordable Care Act.
Analytics and Monitoring
A website is truly never “finished”. Technology changes, user expectations evolve, KPI’s may advance, scope may grow, and/or any number of factors may improve the website over time. Website decisions are best made using data. These include urgent performance issues. Website data comes in real-time (such as server alerts for traffic overflow or potential hacking), collected over time (reports designed to measure KPI’s), secure creation and management of user databases (including private and sensitive data of U.S. citizens) and ongoing monitoring of other mission-critical data sets that demonstrate success of the website.
The Questions Congress Should Ask:
10. What monitoring systems are in place for Healthcare.gov?
11. Who is responsible for monitoring website performance?
12. Is there an escalation plan to address urgent issues? (If so, please define)
13. Who has, or will have access to user (U.S. taxpayer information) databases and who is ultimately responsible for integrity of that data?
14. Who on the client side (U.S. Government) has taken responsible for assessing performance according to KPI’s specific to protecting their interests and insuring delivery of the website specified?
15. Please define the 6 month, 1 year and 5 year plan on how the healthcare.gov website will be managed and maintained (content, database back-ups, security checks, hardware and software upgrades, application development, etc.).
If Congress asked these questions, I suspect we would have a much better understanding of what must be done to insure creation of a quality website and accurate specification and deployment of the infrastructure supporting it. This topic does not even address the outrageous $600 million dollar healthcare.gov website budget, or what would happen to the vendor and project manager if an Epic Fail of this magnitude occurred in the private sector.
