The first lesson is that when an IT project is under a firm deadline, project delays can cause failures because they may not allow a sufficient amount of time to be spent developing and testing the product.
Politicians shoulder most of the responsibility of this problem. Because the Obamacare rollouts were pushed back for political reasons (i.e., 2012 election), the CMS didn’t have enough time to adequately develop and test the software before the implementation date (which was set in the actual legislation). However, I do think that implementers have to bear some of the blame because they knew that this was a problem. Chao mentioned how Congress and the President were not familiar with the reality of tech and didn’t check whether the implementation deadline could be met. This reality makes it all the more important that implementers then raise this concern to Congress or the President.
The second lesson is that you should express your concerns if you have them. People shouldn’t be worried about being perceived as incompetent or as the person who panics. If you have legitimate concerns about the project, then you should either address them or run away from them. Chao mentioned that he was concerned about getting shut out of the process, but even if he were then at least he wouldn’t be responsible for the failure of the project.
In Hannah Riley Bowles’ leadership class, we discussed the perception of being associated with failure if you point out a potential failure in the process. Yes, this reputation can be created if you point out a lot of problems. However, if you focus on two or three main concerns and frame it in a way that is not accusatory, then this feedback is usually well received.
The responsibility for this problem has to be on Chao and any other person who saw these failures but didn’t express their concerns.
The third lesson is that lack of guidance or direction on a project signals that an IT failure is likely. Chao mentioned that a major contributor to the software development failure was that they were not given requirements for the project. However, they were stuck trying to create something that would live up to the White House’s promise of a “world-class experience.”
This lack of direction and clarity violates the principles outlined in the Power and Influence course I took last semester. The idea is that for a leader to run a successful organization, then they need to set clear expectations. Although the clarity principle was given in the context of running a successful organizations, I believe it can also be applied to running a successful IT project (or any project in general). If you want to have success in a project, then you need to communicate clear expectations.
I believe policymakers and implementers are equally responsible for this problem. Policymakers should have clearly and quickly identified the requirements for the implementers. Although policy appointees wanted to ensure they had bulletproof regulations before releasing them, they should have done a better job at getting these over to the implementers in a timely manner. However, implementers knew that they lacked the requirements they needed, but tried pressing on without them. If they knew this was going to hinder the project’s development, they should have done more to get them sooner or change the rollout deadline.
If I were part of the development team, I would first develop a persuasive outline of failures and the likely consequences of each failure. Then I would alert Bryan Sivak (HHS CTO) about these failures, and if that didn’t get anywhere, then I would talk to Todd Park (White House CTO). Although Chao said that he “tried sounding the alarm” to Todd Park, I question how loud this alarm was.