Numerous other sites and media outlets can discuss the politics related to Healthcare.gov, but the design and build of the site has a more IT related project management issue. It seems that while the world relies on technology we still have yet to figure out that technology cannot be served half baked. To evoke a favorite phrase of mine: Proper Planning Prevents Piss Poor Performance.
Let’s start with leadership. In order to have an effective project, the leadership needs to have a vision, have that vision be forward thinking/reaching, and strong in their managerial skills. The major break down in the leadership structure is the former CTO of the Department of Health And Human Services (HHS) and current US Chief Technology Officer/Assistant to the President, Todd Park. Mr. Park’s…let’s be honest…Todd’s leadership has been described as born out of Silicon Valley. The idea of one of the most powerful IT people in the world running their department fueled on no-sleep, pizza, and Red Bull (Mountain Dew for the purists) is ludicrous. These types of antics are allowed for leaders of companies like Facebook, Twitter, or Instagram, but not someone who’s developing one of the United States’ most complicated and scrutinized web based services. A month after go-live we still have major IT related issues with no clearly communicated path for repair. At this level there’s just no room for agile leadership and all nighters.
The next target would be the major contractor, CGI Federal. Did no one do their homework on this company prior to hiring them? They have a litany of high dollar-government related site delays and failures. It’s the government’s prerogative to hire outside firms to build their sites and online services instead of using the large body of developers that already work for the fed. This decision is easily paralleled in today’s enterprise environment. Companies choose to go outside their walls to hire contractors to do work for them instead of relying on the full time people already in their employ. I cannot condemn this action as in some cases it makes sense. However, contractors need to be treated like a tool. A certain tool is chosen for a specific job, and if the tool has a history of not being able to complete the job properly a different tool should be chosen. The job cannot hinge on one tool. Perhaps the fed should have looked at CGI Federal’s Angie’s List reviews before hiring them.
There are arguments in the developer world as to how to design a product: Agile vs. Water Fall. In some instances going 100% in either direction make sense. If you’re working on a low-level project or a spin-off idea and you’re merely looking to see where the rabbit hole goes, agile development can work for you. If you’re working with a large project with a laundry list of stakeholders and a specific set of requirements, it’s best to approach the design via Water Fall development. It seems that the HHS and the federal contractors had the worst mix of both. A government department trying to act as an agile development firm working with enterprise contracted development companies that work on deadlines and firm goals. A glaring example of the development process breakdown is found in the amount of time it took the HHS to get the site specifications to the various contractors. They could have mixed the development ideas by simply coming up with an initial list of “must haves” and then editing that list as the development process went on and it would have been a more successful venture. I’ll save a rant on the development processes theory for another entry, but suffice to say that this is a glaring example of both processes crumbling.
The last issue to discuss is that of expectation. Thanks to the hard work of a number of developers over the past few years, technology has become easy and somewhat lazy. If you want to download a song or a movie and take it with you on the go it’s as simple as pulling up the media store on your mobile device which connects over a high bandwidth wireless connection and pay/download. The world has become so accustomed to instant service that we sometimes forget that the development of this type of transaction didn’t happen overnight. It really begins to show when people in positions of power can’t seem to grasp why the development of a large scale project can’t happen overnight. Everything else in their digital lives happens in an instant exactly when they want it to, so, why can’t the project they need done be accomplished in the same amount of time? Thanks to these types of expectations developers have been forced to turn in half completed work and claim the issues can be fixed in upgrades, service pack, patches, etc. When the product is the portal to something that’s going to be used by millions of people, we cannot allow the developer to follow in the footsteps of Apple and release a product before it meets the expectations of the users. This type of rushed work is what leads to disasters the likes NASA faced in Jan. of ’86.
The problems that plagued Healthcare.gov are not limited to government IT related projects, but instead are a reflection of how the world continues to treat technology, its creation, and its support. Some may say that I’m over simplifying the ideas of getting the right people to lead the project, find the right people to build it, and make sure it works before you give it away but I say that those people are over-complicating the issue. I know some of you out there have dealt with these issues whether as a developer/designer or as a product purchaser. Feel free to vent below.