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.”