The Healthcare.gov Story Continues

Healthcare ScreamJust about every Agile expert on the web is decrying the use of a Waterfall development methodology as the downfall of the Healthcare.gov open enrollment website. But based on one knowledgeable account, it appears that the development team was using Scrum, however badly. Government Computer News published an article by Michael Daconta, the VP of Advanced Technology at InCadence Strategic Solutions and the former Metadata Program Manager for the Homeland Security Department, that largely skewers the Agile-would-have-prevented-this meme. The article drew a comment by Agile Manifesto signatory Bob Martin, who assures us that “a project that fails to allow users to log in on the first day of launch was not developed under the auspices of an agile process.”  Unless they really sucked at it, or it was inappropriate for the problem at hand.

I’ve read a bit about the system, and it appears that many of the underlying problems are a result of the complexity and sheer number of the integrations between the various insurance companies, state and government agencies, and the central hub behind the excellent, highly reliable user interface. Paul Smith’s account is particularly enlightening. Note that the hub and UX were developed separately, by different contractors.

Lawyers, Programmers, and Money

The people who did the content management  for the front end were a 12-person shop in Washington DC, Development Seed. They were brought in by someone with White House influence, who liked their Open Systems approach, on what sounds like a sole-source contract. The Health and Human Services (HHS) CTO, Bryan Sivak, spoke about their technical approach at South by Southwest.  Even Bob Martin would admit that they’re Agile. Their CEO said that they declined to bid on the rest, because they don’t have the legal staff to handle a federal competitive procurement.

I suspect that when the final analysis is available (assuming the government and their contractors don’t classify it top secret), we’ll see that the technical challenges were exacerbated by the federal government’s procurement system.  The work on the hub was bid on by several companies with dedicated federal government sales organizations, which allowed them to respond to a government solicitation. The bidder’s list was limited to a small number of firms with federal government software development experience, rather than experience developing open enrollment websites.  I’d guess that the long delay inserted by the contracting process, plus the fact that requirements were being driven by state and federal legislation that kept changing, plus delays and uncertainty driven by the participation by attorneys who had to analyze every aspect of implementing the new law, plus the continuous changes in what the insurance companies were offering, plus the extensive integration work and widely distributed business logic, made timely development and thorough testing impossible. But that’s strictly my guess, as an outside observer.

Observations From a Practicing IT Project Manager

Of course, the apparently inadequate risk management jumps right out at the experienced project manager. You have a big bang delivery, on a fixed go-live date, and no contingency plans? No provision for  paper forms or intake by some call center? Or a way to let tire-kickers window-shop without entering the personal data that has to be validated by the Social Security Administration, Homeland Security, and so on? Or a way to bypass certain synchronous edits, for follow-up in case provided information is found to be invalid?  It’s all do-or-die? So, how do you like death?

I’ve implemented benefits open enrollment administration systems for about a dozen companies using several technologies, including PeopleSoft and Workday. Even with one employer, a limited number of choices, a small number of integrations, and a configurable, mature product with lots of previously successful installations, it’s not a trivial exercise. This project appears to be three or four orders of magnitude more complicated. I don’t think any software development methodology could have made a difference, absent a highly skilled architecture team with lots of application-relevant experience preparing a design that would accommodate all of the potential integrations and logical combinations, and a product management team with absolute authority to make decisions and enforce them. But, only Congress was allowed to make the key decisions. And as product owners, they have a well-deserved bad reputation.

This entry was posted in PM In the News and tagged , , , , by Dave Gordon. Bookmark the permalink.

About Dave Gordon

Dave Gordon is a project manager with over twenty years of experience in implementing human capital management and payroll systems, including premises-based ERP solutions, like PeopleSoft and ADP Enterprise, and SaaS solutions, like Workday. He has an MS in IT with a concentration in project management, and a BS in Business. He also holds the project management professional (PMP) designation, as well as professional designations in human resources (GPHR and SPHR) and in benefits administration (CEBS). In addition to his articles and blog posts, he curates a weekly roundup of articles on project management, and he has authored or contributed to several books on project management.

One thought on “The Healthcare.gov Story Continues

  1. Its sad, that this is the case for a lot of Large Govt IT projects. Well written Dave, I agree with you 110%

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>