The failure of the HealthCare.gov launch has been well documented. Problems with user registration, general site availability (downtime), and site functionality in general lead the hit parade. Our 21st Century IT community discussed it during last week's live chat. How can you avoid the same issues with your company's site launch?
Primary contractors, currently under great scrutiny, provided the bulk of the integration base for the healthcare registration and pricing tool known as HealthCare.gov. Breaking a large project into pieces (to allow for rapid development) is a tried and true method for launching applications. Before launch, a key misstep was made in failing to ensure all the components worked together well. Providing basic information for tool functionality is a product of emulating a good known (usually paper-based) process.
Catching the holes in pre-project scope, streamlining functions, and ensuring primary data gathered covers all needed variables for execution are not simple tricks. After many projects, with varying degrees of success, I have avoided functionality issues by hand picking a group of beta users -- thought leaders who are engaged in the process to be replaced.
While gathering initial information from users, HealthCare.gov initially failed to ask for the registrant's date of birth, a primary field needed for pricing. This screams at the lack of pre-launch testing. Programmatically, a workaround was used. Taking all pricing from a 20-year span and averaging the costs associated with coverage is not only an inelegant solution, but it also provided drastically low cost estimates for a large segment of site users. This tragic foible would have been caught with even a minimal amount of experienced user testing.
Site availability -- the ability to scale on demand for user registration -- always presents a specific set of challenges. As my business partner often says, "This is a high-grade problem." In the business world, a flooded site means a tsunami of clients and prospects have visited your new site or application. Providing an on-demand scalable solution for a toolset such as HealthCare.gov should have been a no brainer. The same goes for calculating initial and peak use metrics -- a simple calculation based on the number of underinsured and uninsured Americans. Load testing to prevent server stress is commonplace.
What do you think? How avoidable could most of these mistakes have been? What other areas could the contractors have foreseen as critical tasks and made sure they worked before launch? Tomorrow, I'll give you my take.
Primary contractors, currently under great scrutiny, provided the bulk of the integration base for the healthcare registration and pricing tool known as HealthCare.gov. Breaking a large project into pieces (to allow for rapid development) is a tried and true method for launching applications. Before launch, a key misstep was made in failing to ensure all the components worked together well. Providing basic information for tool functionality is a product of emulating a good known (usually paper-based) process.
Catching the holes in pre-project scope, streamlining functions, and ensuring primary data gathered covers all needed variables for execution are not simple tricks. After many projects, with varying degrees of success, I have avoided functionality issues by hand picking a group of beta users -- thought leaders who are engaged in the process to be replaced.
While gathering initial information from users, HealthCare.gov initially failed to ask for the registrant's date of birth, a primary field needed for pricing. This screams at the lack of pre-launch testing. Programmatically, a workaround was used. Taking all pricing from a 20-year span and averaging the costs associated with coverage is not only an inelegant solution, but it also provided drastically low cost estimates for a large segment of site users. This tragic foible would have been caught with even a minimal amount of experienced user testing.
Site availability -- the ability to scale on demand for user registration -- always presents a specific set of challenges. As my business partner often says, "This is a high-grade problem." In the business world, a flooded site means a tsunami of clients and prospects have visited your new site or application. Providing an on-demand scalable solution for a toolset such as HealthCare.gov should have been a no brainer. The same goes for calculating initial and peak use metrics -- a simple calculation based on the number of underinsured and uninsured Americans. Load testing to prevent server stress is commonplace.
What do you think? How avoidable could most of these mistakes have been? What other areas could the contractors have foreseen as critical tasks and made sure they worked before launch? Tomorrow, I'll give you my take.
No comments:
Post a Comment