By now, it should be apparent to everyone that the launch of HealthCare.gov was a colossal failure. Plenty of experts have weighed in on the incompetence of the contractors or what should be done to right the ship, so rather than slinging more mud, I’d like to uncover some of the lessons that we can learn from the rollout of HealthCare.gov.
Finding the Right People to do the Job, Not for Winning the Job
Anyone familiar with government procurement knows this, but it is important to understand that the best candidate for a government contract isn’t always the candidate awarded that contract. In fact, the best contractors are very often overlooked. While this is endemic throughout all levels of government procurement, it obviously has a huge effect on a piece of technology that many Americans will be forced to interact with.
An Op-Ed in the NY Times recently addressed why the government almost never gets tech right. The process of securing a contract requires a lot more than being capable of doing what’s required of the contract. At the end of the day, companies win contracts based more on their ability to navigate a convoluted regulatory system than on their fit for the job.
When it comes to a piece of technology like HealthCare.gov, the Federal Acquisition Regulation just isn’t equipped to select vendors that are capable of delivering a viable product within a limited timeframe. The regulatory landscape needs to change drastically, and quickly, if the government intends to right this wrong and get the best people for the job.
Failure to Launch
Failure is sure when leadership is non-existent. HealthCare.gov was built by 55 contractors – many moving parts, with no lead contractor. It should be common sense that without one person or group of persons having knowledge of all the moving parts, HealthCare.gov was destined for failure. For further proof of just how much confusion surrounded the project, the largest contractor, CGI Federal, has already skirted blame for the failed launch.
For any project to succeed, leadership must be established to manage expectations and hold people accountable.
If You Ain’t First, You’re Last
The software industry morphs at a frenetic pace. The industry constantly invests time and resources to improve the available technologies or simply find better ways of doing things by creating new technologies, which has helped a number of new development platforms rise to prominence in recent years.
For instance, 352 is currently transitioning from being a .NET shop to adopting the MEAN (Mongo, Express, Angular, Node) stack. We’ve developed solely in .NET for more than a decade, but we recognize that this industry requires us to be nimble and agile, and we understand that we have to adapt and adopt new technologies or die.
Unfortunately, it’s challenging for other industries to award a contract to a tech firm based on adoption of future-ready technologies; the safer choice is to select a firm with a proven track record of success, even with old technology. Again, the best contractors are not always likely to win the contract.
Adopting new technologies is a must in order remain competitive in the technological space, but just as important is the ability to compete based on your track record. Your reputation is everything. The 55 contractors on HealthCare.gov have taken a major blow to theirs. With the speed of this industry, all it takes is one bad experience – like HealthCare.gov – to be left behind, no matter what reputation you might have had.
Don’t Go Chasing (55) Waterfalls
There are plenty of reasons for the failure of HealthCare.gov, but I’m convinced that many of them could have been avoided. Prevention is far less costly than mitigation and damage control, and this project was sunk almost entirely by self-inflicted wounds.
Yes, HealthCare.gov is a massive and highly complex project, but red flags could have been raised earlier. Protecting your reputation means communicating early and clearly which expectations cannot be met in the time allotted. It is a tough conversation to have, but it’s better than the conversation we’re all having about a massive, public failure like HealthCare.gov has become.
We’ve spoken before about why we abandoned waterfall for an agile approach, and the development of HealthCare.gov represents the ultimate condemnation of waterfall development.
With 55 contractors all working on separate pieces of the project, there was never an opportunity to raise those red flags, or even to have a conversation about falling behind. It’s hard enough in a small shop where the right hand might not know what the left is doing. When you add 53 other hands into the mix, it’s no surprise the HealthCare.gov team dropped the ball in such a spectacular fashion.
Based on what we know of how HealthCare.gov was developed, I highly doubt that agile web development was employed. While that might sound obvious given the too-many-cooks approach on display here, there is at least one example of agile development working in a government project, and many people have begun to address the growth of agile in government.
In fact, the U.S. Government Accountability Office released a document outlining the challenges and best practices in applying agile methods, so there is evidence that agile development has been adopted to some degree by IT departments within the government. Unfortunately, that clearly doesn’t apply to the contractors the government uses on IT projects.
Policing an internal project certainly has its challenges, but it’s nearly impossible when working with a contractor, especially one using waterfall. To us, the clear lesson here is to work with firms that utilize agile methodologies. In addition to the collaborative approach it enforces, clients always know the exact disposition of a project at any time.
At 352, we’ve seen plenty of benefits from switching to agile, but most importantly we’ve been able to learn painful lessons and spot red flags sooner than later in the development process. There is simply no better way to undertake software development, regardless of the size or complexity of the project.
Managing the Human Factor
I do believe that we often let external pressures cause us to forget the human factor – that the law of diminishing return is always at play. We are limited in the amount of functionality we can deliver on deadline. If the goal is quality on a fixed deadline, the scope of work that needs to be done has to be variable. If the scope cannot be changed, the deadline has to be flexible.
We cannot expect to hold all 3 factors – scope, time (deadlines) and quality – constant and also expect the project to succeed. I left out another factor in the Project Management Triangle, but we’re dealing with a very expensive government project, here, so I made the assumption that budget wasn’t as limiting as the other factors.
Some might argue that HealthCare.gov was doomed to fail from the start, like most other really expensive projects, but I would argue that this failure could have been largely avoided – or at least mitigated – with a shift in thinking. But that’s a topic for another day. I will say that I hope both the software industry and those that partner with us will learn the lessons necessary to reduce the risk of failure of this magnitude in the future.