Opt-Out [Texto original en inglés. En los próximos días incluiré la traducción.]
The lessons from the Healthcare.gov rollout
Bryan Sivak’s visit to our class last Monday was very interesting, because he raised several important issues that I had not thought about before. Perhaps the most important is that, when rolling out an IT project, it is important to test the final output before it comes out. On the surface, this observation might seem obvious, and to some degree it is, but when dealing with something like healthcare.gov, this requires testing each page within the whole website, one by one. This also means testing how it handles increasing amounts of traffic. I was absolutely surprised with Bryan’s observation that the website had not been completely reviewed before launch, especially when it was expected to attract so much traffic. So, the first lesson from all of this is to think about scalability: An IT project that has not carefully addressed this question is more likely to run into trouble. If we need to test the website, that involves not only ensuring that it works properly, but also that it can adequately sustain high traffic. In the case of health care.gov, perhaps rolling out a ‘pilot’ of the website in a particular county could have worked better.
This leads to a second lesson, which is that being late is better than being sorry. In class we discussed how often the amount of time and effort required to complete an IT project is severely underestimated by stakeholders with little involvement in how IT actually works,
like myself. From Bryan’s explanation, it is clear that a lot of the problems with healthcare.gov stemmed from the fact that meeting the deadline took priority over getting some basic features right. This lack of flexibility creates incentives for half-baked solutions to issues that might be potentially significant down the road. Therefore, another sign that an IT project is running into trouble is the existence of hard deadlines that leave little room for discretion, specially if those deadlines have been set by non-IT people.
Finally, I would argue that IT projects are more likely to run intro trouble if key operational decisions, that is, decisions that are vital for implementing the basic features of the project, are made to dar up the chain of command. This speaks to the long-running theme in the course of the divide between the people designing policy and those in charge of its implementation, including CTOs and IT vendors. Ensuring that this type of decisions is in the hands of people in charge of implementations is essential. Bryan brought up the anecdote about having to change the name “marketplaces” to exchanges” and having to go up all the way to the president to get authorization. If changing some of the basic terminology of a website or application requires approval of those at the top, this means that the people involved in the actual construction of that website or application are not sufficiently empowered. This lack of relevant authority to make basic decisions seems to be a third sign of an IT project in danger of failure.
In closing, I want to share some thoughts that certainly apply to IT projects but that, I believe, are also relevant to policy implementation more broadly. I think that preventing “digital disaster” or policy disaster of any sort requires a lot of courage, and some of that was missing in the case of Healthcare.gov. In another class we discussed the importance of courage when carrying out policy, and Bryan’s case almost automatically came to my mind. He told us that he had seen a lot of the problems of Healthcare.gov’s rollout coming, but eventually stopped speaking up about them. To some degree, I do not blame him, because it is clear that many within the same team did not take those observations kindly. However, I think that we must speak up when problems arise, regardless of the consequences. Given that the policy and its successful rollout were important for so many people, I think that Bryan should have been more forceful and push back on the resistance that he encountered among his colleagues. I recognize that this is easier said than done, but it is true nonetheless.