HealthCare.gov Leaders Play IT Blame Game

As a CIO watching the HealthCare.gov firestorm on the nightly news, I sometimes feel like I'm back in the office. The project is late or incomplete. It's all the IT department's fault. Let's send in more support, more hardware, and more software. Bring in the outside experts to save the day!

If you've been in IT management for any length of time, this fire drill should sound familiar. Putting aside the political and hypermedia aspects of Obamacare, the reality is that the failure of HealthCare.gov is simply one more IT project gone bad. The fact that it's a highly publicized government initiative doesn't change the underlying issue. Nor does it change the basic approach organizations should take when putting big IT projects back on track.

Looking at the Affordable Care Act website, there's no cutting-edge technology at play. It's a website with commerce capabilities. Period. With that as background, I have to assume the issue is one of the following: Either a failure in the requirements definition, or a problem of business ownership and involvement (i.e., governance). Add the fact that it's a high-profile initiative with a range of opinions and even fewer solutions, and what you've got is a classic "Dilbert" situation.

[ Read our complete coverage of the HealthCare.gov launch here. ]

My Monday morning quarterbacking from afar: It appears there were both poorly defined requirements for HealthCare.gov and last-minute changes in project scope. In other words, significant modifications were made at the architecture level, with the major issue centered on registration flow.
 
For any big website project, changes to the registration system are more than simple code tweaks. They're a fundamental departure from the entire architecture of the application, both systems and data.
 
Normally, application modules expect the environment, especially data, to be in a certain state at each moment during process flow. But when you change underlying flow -- and thereby, the site architecture – there's more state changes than the modules originally tested. This means that procedures to gracefully handle issues aren't in place. The system is immediately exposed -- and things devolve into chaos.
 
A significant last-minute change in registration process suggests business flows and definitions were poorly documented. Otherwise, requirements would have been identified either in a prototyping, scrum session, or early iteration. Usually, the solution is to restart from that point, working your way forward on design development and deployment. This approach takes a lot of time and patience.

Alternatively, perhaps HealthCare.gov requirements were defined clearly -- whether correctly or incorrectly -- but project governance was poor. In any enterprise, IT is a service provider, one that must be managed. Non-IT business owners must participate in the project on a regular basis. My sense is governance failed on this project. Otherwise, a system this poorly designed would never have progressed this far.

Proper governance includes setting up "tollgates" that the business owns and manages. (Enterprises that excel at IT stopped saying, "I don't understand what those guys are saying" back in the '70s.) Both project team and governance body must understand the purpose of tollgates and measure successful project passage from one to the next.

Having senior government officials stand in front of the American public and imply that the HealthCare.gov problem is technical just isn't right. This is the classic cop-out companies use when IT projects go bad, and it demonstrates lack of ownership and accountability. Quite simply, the wrong leadership was in place from the beginning.
 
The key to any successful business project is threefold: ownership, accountability, and an ability to execute. The IT group certainly must take ownership of mistakes during design and development. The same group must also maintain control during testing, deployment, and ongoing management.
 
However, equally important is the business leader or team that originally defined the project vision. This group must be willing to take full responsibility, at any stage. Whether we're talking about a finance, marketing, legal, or any other business unit lead requesting a technology solution, each must be willing to step up and share blame if the project stalls.
 
Although the IT department surely can carry out requirements, a project can fall apart if its champions haven't constructed effective definitions. This process involves not only designing a viable business and technology model up front, but also mapping goals and monitoring benchmarks along the way.
 
It just isn't fair to always point the finger at technology or its implementers. Unfortunately, IT is often the odd man out in the blame game.
 
Bill Hurley is CIO of Westcon Group, a value-added distributor of unified communications, network infrastructure, datacenter, and security products. Before joining Westcon in 2008, he was a managing director with Marsh & McLennan, where he acted as global CIO for the Americas.

There's no such thing as perfection when it comes to software applications, but organizations should make every effort to ensure that their developers do everything in their power to get as close as possible. This Dark Reading report, Integrating Vulnerability Management Into The Application Development Process, examines the challenges of finding and remediating bugs in applications that are growing in complexity and number, and recommends tools and best practices for weaving vulnerability management into the development process from the very beginning. (Free registration required.)