In the aftermath of the healthcare.gov disaster in 2013, armchair quarterbacks from all corners offered their reasons for the failure. Some thought the Centers for Medicare and Medicaid Services (CMS) had spent its budget too slowly. Others said the problem was that CMS had tried to be its own “systems integrator” and should have charged CGI Federal — the lead company on healthcare.gov, the website that administered the health insurance exchanges mandated by the Affordable Care Act — with pulling all the pieces together. Still others thought that CGI and the dozens of other vendors involved were the real problem. (Indeed, the absence of truly basic functionality like site monitoring software suggests some serious deficiencies on their part.)
A report by the Office of Inspector General offers ten key reasons for the disaster, spanning everything from lack of clear leadership and an overly bureaucratic culture to failures of integration, communication, execution, and oversight. The report is thorough, but that’s a broad diagnosis. If I had to pick just one thing that maybe, just maybe, would have made a difference, it would be this: the site had a lot of project managers but no product manager.
With all the dysfunction cataloged by the inspector general swirling around, what could a product manager have done for healthcare.gov? In a word, less.
Healthcare.gov was a truly massive undertaking. It didn’t just let people shop for and choose insurance plans. It had to communicate with dozens of other government databases to verify the person’s income, Social Security number, citizenship status, and whether the person was enrolled in any other health care programs; it had to make sure the enrollee was charged the right amount for coverage; and it had to transmit enrollee data to hundreds of different insurers. Not only did the site need to scale to handle enormous traffic but dozens of connections had to work just right for any given transaction to go through.
In any service like this, you will find a core of users whose circumstances are the most common and a long tail of increasingly rare “edge cases.” For instance, the Affordable Care Act generally extends coverage only to applicants who are U.S. citizens. But there are 17 unique immigration statuses that are exceptions to that rule, and the people those exceptions cover represent a tiny fraction of users. Programming in the logic and database connections to automatically verify all 17 exceptions makes the software orders of magnitude more complex than what would be required to support the most common type of user. The people with edge cases could have initially been helped through other channels, including call centers and various agents and assisters who could meet clients in person. Mike Byrne, the guy who built the broadband map for the Federal Communications Commission (FCC), estimates that most government tech projects could cost 10% of what they do and still provide 85% of the functionality. I hereby dub this “Byrne’s Law.”
Because CMS tried to build something very complex that worked for everyone right from launch, healthcare.gov worked for no one.
It’s not that that final 15% of the functionality shouldn’t ever be built — the software can and should eventually support edge cases. It’s just that trying to have it all done by launch, before you’ve had the chance to work out the kinks with the core workings of the project, will often tank the operation of the other 85%. Mike’s modern-day estimate resonates with a 1975 observation known as Gall’s Law, named for pediatrician and systems design theorist John Gall. “A complex system that works is invariably found to have evolved from a simple system that worked,” Gall wrote. “A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.” Because CMS tried to build something very complex that worked for everyone right from launch, healthcare.gov worked for no one. Everyone swamped the call center and the in-person assisters. Those high-touch channels should have been reserved primarily for the people with unusual cases, those without internet access, and others who needed extra help, but instead they were jammed up with the cases that software could have easily handled.
Theoretically, CMS could have heeded Gall’s Law: limited the functionality of the site for launch, planned for call-center support for people whose circumstances the site couldn’t handle, and, as resources allowed, incrementally added online support for the edge cases after launch. In practice, however, Congress had ordered a fully functioning website, so a fully functioning website was what CMS had to deliver. Project managers had all their requirements to check off. The idea that some choices could be made, and in fact would very much need to be made, was unspeakable, perhaps unthinkable. Many considered anything but the whole nine yards illegal. Clay Shirky describes being at the Harvard Kennedy School, one of the country’s top public policy institutions, a month after healthcare.gov launched and being told that the site simply could not have been built and tested iteratively over time because that’s not how government works. “It is hard for policy people to imagine that HealthCare.gov could have had a phased rollout, even while it is having one,” he wrote at the time. Incremental fixes is exactly what the agency got, just in the worst possible way.
In this article
"follow" - Google News
July 05, 2023 at 09:30PM
https://ift.tt/z49KMPI
Follow Gall's law to stop your complex project from failing - Big Think
"follow" - Google News
https://ift.tt/zrv8d3S
https://ift.tt/Yv843gj
Bagikan Berita Ini
0 Response to "Follow Gall's law to stop your complex project from failing - Big Think"
Post a Comment