Lessons from Bryan Sivak’s Experience with Healthcare.gov
It was a unique opportunity hearing Bryan Sivak’s talk about his experience and impression with the Healthcare.gov initial colossal failure. Bryan was the Chief Technology Officer at the Department of Health and Human Services during the Healthcare.gov rollout. He participated in and witnessed firsthand the preparations for the launch of the website and unsuccessfully tried to warn from the impending failure.
Here’re some lessons I have from that talk:
(1) Speak up effectively — it is evident that Bryan is still struggling with the question “did I speak up the way I should have in order to prevent the launching failure?”. Two specific meetings were mentioned — an early private one with the boss and a later one with many participants. I don’t have specific advice for what exactly should he have done. This requires a better understanding of the workplace dynamics and power balances. Nevertheless, it is clear that his warnings didn’t have the desired effect. Being the CTO, being the only one who had real life experience with building and launching enterprise softwares and being one of the highest high ranking officers who saw the failure coming puts a heavy burden on his shoulders. I think he should have done more to convey the message effectively to higher ranks. This is easier said than done but coming from the Israeli culture where bluntness and impudence are appreciated, I’m sure there were other ways he could have tried to disrupt the unjustified calmness the preceded the launch. Having in mind the American people and the President of the USA and not his personal fate should have given him the courage needed to take further action.
(2) Appoint an appropriate accountable person in charge — seems to be obvious but in reality it is far from it. Healthcare.gov didn’t have a dedicated project manager. It is essential that projects so big will be led by a capable person that will be granted the right political and other backup needed. Putting high level government officials in charge of these kind of projects when they have so many more important responsibilities is a recipe for a failure.
(3) Stick to the basics — if the project is about a website used by the public you should test the progress accordingly. Demonstrating a website with printouts close to the rollout date is worthless and should actually be a sign of an impending failure. Don’t get confused by the technical buzzwords and excuses. If you are responsible for a million dollar worth of a digital project make sure you have it running and operating ahead and tested in real life environment.
These are but 3 main messages I got from the talk we had about Bryan Sivak’s experience with Healthcare.gov failure. Future challenges will have different and similar characteristics so make sure you manage your projects wisely and keep in mind that failure is always an option. Doubt yourself and others and challenge your basic assumptions. Make others comfortable to speak up and listen to them carefully. Following these advices and others might save you from failing.