Watching the bumpy rollout of online healthcare exchanges around the country—in particular Healthcare.gov—has provided a myriad of case studies to dissect. Tackling a large-scale systems development project—particularly a consumer-facing product—is never easy, and I feel for the development teams that are caught in the middle of this. There are some key lessons so far to be taken from this.

Put someone in charge that knows what they’re doing
This might seem like the most obvious one, but it is also one of the toughest to fulfill when dealing with institutional or governmental bureaucracies. In the case of Healthcare.gov, the Centers for Medicare and Medicaid Services retained leadership over the project, and it turns out they had no technological expertise in-house and so had no business running a complex software development project. This resulted in 55 separate contractors working on the project without clear leadership. If you don’t have technological leadership in-house, designate a partner to be the lead, as the State of Colorado did for their system’s implementation. Yes, it will probably increase your cost to have a partner designated as project lead, but consider it an insurance policy against your own ineptitude.

Throwing more money at a project alone isn’t a fix
Even with a reported $170+ million budget, things didn’t go right with the Healthcare.gov rollout. Or maybe because of the $170+ million dollar budget things didn’t go right. In software development, lean design usually forces stakeholders and team members to make critical decisions along the way, adjusting scope and timelines to fit what’s possible, given the available budget. The risk of having too much money is that it creates the false impression that scope and timeline issues can be fixed by throwing more resources at them, when adding more resources usually only creates incremental efficiencies in software development.

Learn best practices from the new wave of software consumer products
There are hundreds of tales of tech start-ups that have launched consumer-facing web-based software products in the last few years and have struggled through exponential growth phases. These startups had to deal with unexpected website traffic, application design challenges, and constricting 3rd party involvement, similar to issues that affected the launch of Healthcare.gov. Don’t let these lessons go to waste—many are readily available online.

If you’re going to compress a timeline, things will get missed
It’s not unusual to have stakeholders on a project push for a “compressed timeline”. While on most projects there probably are some efficiencies that can be implemented, the unfortunate truth is that a lot of the time savings would originate from so-called “shortcuts”. And when you’re taking a shortcut, you are bypassing part of the planned route that would ensure a properly executed project. Quite often the quality assurance phases are affected by this as well. This was the case at Healthcare.gov, where due to the compressed timeline there was only room for two weeks of quality assurance. The best thing you can do is to be honest to yourself and your stakeholders upfront about the quality impacts a shortcut might have on the project.

Prioritize features, then plan for phased rollouts
Everyone wants a perfect product right out of the gate, right? Unfortunately the more you pack into your day 1 launch, the more things that can and will go wrong. Soft-launches are your friend! Oregon’s approach was to release only a limited amount of functionality on October 1st, and phase in additional features over the coming weeks. The result was initial reports of 34 issues, only two of which were critical. The team could focus on the two critical issues right away, without being overwhelmed by media scrutiny and visitor traffic.

Even better: plan for a limited audience release. If you can limit your initial launch to 1-5% of the target audience (depending on how many users you expect to have in the end) this gives you time to flesh out issues with a smaller group of users, limiting negative exposure and providing a more controlled environment to release rapid updates. This is one reason that states which decided to manage their own exchanges have, for the most part, been more successful than Healthcare.gov.