Strategic CIO // Executive Insights & Innovation
Commentary
12/12/2013
09:50 AM
Bill Hurley
Bill Hurley
Commentary
50%
50%

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.
The Business of Going Digital
The Business of Going Digital
Digital business isn't about changing code; it's about changing what legacy sales, distribution, customer service, and product groups do in the new digital age. It's about bringing big data analytics, mobile, social, marketing automation, cloud computing, and the app economy together to launch new products and services. We're seeing new titles in this digital revolution, new responsibilities, new business models, and major shifts in technology spending.
Register for InformationWeek Newsletters
White Papers
Current Issue
InformationWeek Tech Digest, Nov. 10, 2014
Just 30% of respondents to our new survey say their companies are very or extremely effective at identifying critical data and analyzing it to make decisions, down from 42% in 2013. What gives?
Video
Slideshows
Twitter Feed
InformationWeek Radio
Archived InformationWeek Radio
Join us for a roundup of the top stories on InformationWeek.com for the week of November 16, 2014.
Sponsored Live Streaming Video
Everything You've Been Told About Mobility Is Wrong
Attend this video symposium with Sean Wisdom, Global Director of Mobility Solutions, and learn about how you can harness powerful new products to mobilize your business potential.