\n
Watching the bumpy rollout of online healthcare exchanges around the country\u2014in particular Healthcare.gov\u2014has provided a myriad of case studies to dissect. Tackling a large-scale systems development project\u2014particularly a consumer-facing product\u2014is 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.<\/p>\n
Put someone in charge that knows what they\u2019re doing<\/strong> Throwing more money at a project alone isn\u2019t a fix<\/strong> Learn best practices from the new wave of software consumer products<\/strong> If you\u2019re going to compress a timeline, things will get missed<\/strong> Prioritize features, then plan for phased rollouts<\/strong> 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.<\/p>\n
\nThis 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<\/a>\u00a0and 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\u2019t have technological leadership in-house, designate a partner to be the lead, as the State of Colorado did for their system\u2019s implementation<\/a>. 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.<\/p>\n
\nEven with a reported $170+ million budget<\/a>, things didn\u2019t go right with the Healthcare.gov rollout. Or maybe because of the $170+ million dollar budget things didn\u2019t 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\u2019s 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.<\/p>\n
\nThere 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\u2019t let these lessons go to waste\u2014many are readily available online.<\/p>\n
\nIt\u2019s not unusual to have stakeholders on a project push for a \u201ccompressed timeline\u201d. 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 \u201cshortcuts\u201d. And when you\u2019re 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<\/a>. 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.<\/p>\n
\nEveryone 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\u2019s approach was to release only a limited amount of functionality on October 1st<\/a>, 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.<\/p>\n