Strategic CIO // Executive Insights & Innovation
Commentary
12/12/2013
09:50 AM
Bill Hurley
Bill Hurley
Commentary
Connect Directly
RSS
E-Mail
50%
50%
Repost This

HealthCare.gov Leaders Play IT Blame Game

It's not fair to just point the finger at technology or its implementers when IT projects go bad. Let's talk about the business team that originally defined the project vision.

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.)

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
JimPG
50%
50%
JimPG,
User Rank: Apprentice
12/13/2013 | 10:24:31 AM
Agree that IT is generally the "scape goat" department
As a former senior officer of a health care company and an old-time tech User, I could not agree more with the opinion that IT is generally used as the scape goat department by incompetent Users who generally ill define their requirements and/or constantly change their requests. What I always found amazing was how often the IT Department was willing to fall on their own sword to protect what they considered their "customers" (i.e. other departments within the same company). As Mr. Hurley indicated as appropriate, I generally tried holding the User responsible. Oddly enough, I often got more push back from the IT department than the User's themselves since, I believe, in addition to possibly trying to protect their "customers", IT managers often wanted to take ownership (and ultimately credit) for the project itself. The main problem I had with IT was their general unwillingness to assign and identify specific resources behind a project. My position was always that I would prefer to have 5 to 10 people with names and faces than 500 "FTE's" (i.e. Full-Time Equivalents). Without a full court press, I was generally assured that hundreds or even thousands of hours were being spent on my projects but they were provided in a black-box environment with the general reasoning that IT management needed the flexibility to move resources around from project to project based on specific skill sets needed. That approach always drove me crazy and never seemed to produce results. Both sides of the project fence (i.e. IT and User) need names and faces from management to spec writers to program coders. This would seem to be even more essential when an IT project like healthcare.gov was being farmed out to 35 different organizations.
Laurianne
50%
50%
Laurianne,
User Rank: Author
12/12/2013 | 4:16:45 PM
Governance Startegy
Bill, regarding your questions on governance of the project, that was one complicated governance exercise, considering the 35+ subcontractors working on the project. Most private enterprise CIOs would not easily agree to using such as high number of subcontractors, for the governance reasons alone. Can you imagine Google approaching the project in that way? Yet that is a way of life for government IT. This will be a project management and governance case study for years to come.
InformationWeek Elite 100
InformationWeek Elite 100
Our data shows these innovators using digital technology in two key areas: providing better products and cutting costs. Almost half of them expect to introduce a new IT-led product this year, and 46% are using technology to make business processes more efficient.
Register for InformationWeek Newsletters
White Papers
Current Issue
InformationWeek Elite 100 - 2014
Our InformationWeek Elite 100 issue -- our 26th ranking of technology innovators -- shines a spotlight on businesses that are succeeding because of their digital strategies. We take a close at look at the top five companies in this year's ranking and the eight winners of our Business Innovation awards, and offer 20 great ideas that you can use in your company. We also provide a ranked list of our Elite 100 innovators.
Video
Slideshows
Twitter Feed
Audio Interviews
Archived Audio Interviews
GE is a leader in combining connected devices and advanced analytics in pursuit of practical goals like less downtime, lower operating costs, and higher throughput. At GIO Power & Water, CIO Jim Fowler is part of the team exploring how to apply these techniques to some of the world's essential infrastructure, from power plants to water treatment systems. Join us, and bring your questions, as we talk about what's ahead.