HealthCare.gov: Your Reminder Not To Skimp on Quality Assurance You might be tempted to cut time for QA, but it could doom your next project. We explore the site's sober takeaways for any digital entrepreneur.
Opinions expressed by Entrepreneur contributors are their own.
With millions of Americans still unable to access the troubled Obamacare sign-up site, HealthCare.gov, it was no surprise when the man who oversaw the rollout, Tony Trenkle, announced on Nov. 6 that he would be stepping down. The site was overwhelmed with traffic when it went live on Oct. 1, and only six people were able to sign up for health insurance there on that day, according to documents released by the U.S. House of Representatives. The White House won't say how many sign-ups have happened since then, but the site is still so buggy the President himself has advised people to enroll by phone instead.
Experts in the information technology industry say the flawed HealthCare.gov debut can be summed up with two words: quality assurance (QA). Or rather, lack thereof. QA, once a staple of software development, if often given short-shrift when projects have limited funding, short deadlines, or both, as was the case with HealthCare.gov. But many observers say the industry can learn valuable lessons from the site's debut about the importance of prioritizing QA.
In its simplest terms, QA is a systematic process of monitoring a technology project while it's being completed, to ensure at every step along the way that all the stakeholders—most importantly the final users—will get the product they're expecting. It's often more involved than it sounds, however. "First you have to be able to communicate the customers' needs to the members of the development team, then the project manager needs to monitor the team on an ongoing basis to ensure it's delivering what the customer wants," says Dan Katz, vice president of technology for McClean, Va.-based INADEV, a provider of mobile technology.
One key to making QA work, Katz says, is effective communication—a challenge on projects like HealthCare.gov, which involved stitching together information from multiple stakeholders, including state health agencies, insurance companies, and the federal government. "With such a massive project, the overall architecture of the application needs to be really well planned out up front," says Katz, who spent the early part of his career as a web developer for CareFirst BlueCross BlueShield. Then there needs to be a continuous hand-off of information among all of the parties that are contributing to the site. "You need a lot of opportunity for peer review and for catching problems before something is packaged up and delivered," Katz says.
Successful QA teams should include not only software experts, but people with a deep understanding of the industry the site will be serving, says Bill Curtis, chief scientist at CAST, a New York-based software quality analysis firm, and the director of the Consortium for IT Software Quality, which is working to develop QA standards. "If you know healthcare, you know all the different weird things that can happen when people sign up for accounts, and you can be prepared for those," Curtis says. "Part of functionality is understanding all the possible different conditions that the site has to be ready to handle."
QA often goes by the wayside when there's a tight deadline for delivering the final site—most definitely an issue with HealthCare.gov. But experts watching the botched rollout from the sidelines believe the problems could have been averted if the White House had staged the project rather than putting up the full site all at once. For example, they could have put up a bare bones site on Oct. 1, perhaps allowing visitors to set up accounts but not to sign up for particular plans yet. Then more sophisticated capabilities could have been layered on to the site over time, giving the QA team more time to test them before unleashing millions of consumers onto the site.
"This was such a huge project that I do think they should have had checkpoints along the way that said "Phase 1 will include this, Phase 2 will add this, and Phase 3 will be complete,'" says Brenda Hall, CEO of Bridge360, an Austin, Texas-based software developer. "One good risk mitigator is to start with lesser functionality."
Hall was so disturbed by the HealthCare.gov rollout she blogged about it on Oct. 30, urging software developers to learn from the fiasco and never crimp on QA. "The way of the world today is quick, quick, quick because we're so connected," Hall says. "I don't think pushing quality aside is the answer. Plan for it on Day One. There's really no excuse to not integrate quality into the overall process."
