6 Tech Takeaways From Sebelius' Tenure

Joe McKendrick
Insurance Experts' Forum, April 14, 2014

Health and Human Services Secretary Kathleen Sebelius took the fall for the near-disastrous rollout of the Affordable Care Act program and portal. While the program has reported some results as of late – to the tune of 7.5 million insurance registrants – and last week Sebelius announced her resignation, the program is a lesson in how not to introduce a new set of technology-enabled services.

While the program has a range of issues, from customer sticker shock to difficulty tracking applicants, Sebelius' role and responsibility is comparable to that of a CIO within an insurance company. If any company had rolled out a customer portal with the miserable performance of the first ACA offerings, the CIO would likely have been bounced out in relatively short order.   

Also see A Tough Road Ahead for Sylvia Mathews Burwell 

From this chaos, confusion and politicking, CIOs can draw some important lessons from Secretary Sebelius' troubled tenure:

1. Never, ever, stake the fate of your project on version 1.0. Technologists and enterprise software users have known this for years, but the Obama administration had some egg on its face with the ACA health insurance exchange portal rollouts. The portals were buggy, insecure and were missing links to back-end data repositories. The act of rolling out game-changing enterprise systems should ascribe to agile principles — meaning working closely with end-users on small, staged, incremental rollouts. The federal ACA designers broke every rule in the book, deploying a massive health insurance exchange system all at once.

2. Make things as simple as possible, especially in version 1.0. As USA Today's Ross Baker observes the ACA program and portal, had “such daunting complexity that 'navigators' were needed to steer perplexed consumers through the maze." Could you image if your insurance company rolled out a program that completely confused even your most savvy customers? Service designers need to take a cue from the mobile app space and strive to keep things as simple and straightforward as possible, even if it means hiding some features.

3. Align the business vision with the technical realities. IT leaders need to make their case forcefully to the business architects of programs if they see an implementation is not technically feasible. As Ross explained it, "The architects of policy are in the White House and the schools of public policy. The people in the agencies are the carpenters and electricians who do the framing and wiring and when the ceiling falls in or the lights go out, they get the calls from the irate homeowners."  When things go wrong, the IT department will be taking the blame, so it's up to IT leaders to manage expectations.

4. Don't over-promise. This is particularly the case with IT-enabled services. IT leaders need to be conservative with what their services will offer end-users. If the business is promising too much, it's IT's responsibility to tone these promises down and keep things grounded. For example, sales and marketing leaders may not understand the limitations of a certain technology, or the care and planning that needs to go into an execution.

5. Make use of existing resources from across the enterprise, don't try to build everything from

scratch. It's not as if this was the first time the federal government attempted to create and build a portal. Agencies of the federal government now offer hundreds of portals, from the IRS to the National Park Service to NASA to all branches of the military.  Where was all this expertise and resources during the creation of the ACA portals? An effective digital enterprise is built on the sharing and reuse of resources that have already been created and tested. 

6. Keep vendors and contractors close and involved. There appeared to be a lack of oversight over the activities of the portal vendors. There needs to be continuing quality assurance and testing at every phase of the process. End-users and project managers alike should not be surprised by glitches encountered by end-users that could have easily been fixed earlier in the process.

Joe McKendrick is an author, consultant, blogger and frequent INN contributor specializing in information technology.

Readers are encouraged to respond to Joe using the “Add Your Comments” box below. He can also be reached at

This blog was exclusively written for Insurance Networking News. It may not be reposted or reused without permission from Insurance Networking News.

The opinions of bloggers on do not necessarily reflect those of Insurance Networking News.

Comments (0)

Be the first to comment on this post using the section below.

Add Your Comments...

Already Registered?

If you have already registered to Insurance Networking News, please use the form below to login. When completed you will immeditely be directed to post a comment.

Forgot your password?

Not Registered?

You must be registered to post a comment. Click here to register.

Blog Archive

The Good, The Bad and The Ugly Of Enterprise BI

When IT can't deliver, business users build their own applications focusing on agility, flexibility and reaction times.

The IT-Savvy 10%

IBM survey reveals best practices of IT leaders.

The Software-Defined Health Insurer: Radical But Realistic?

Can a tech startup digitally assemble the pieces of a comprehensive, employer-provided health plan?

Data Governance in Insurance Carriers

As the insurance industry moves into a more data-centric world, data governance becomes more critical for ensuring the data is consistent, reliable and usable for analysis.

Fear This

Just days before this Issue, which contains our security cover story, went to press, we got some interesting news: 1.2 billion unique usernames and passwords and 542 million email addresses were reportedly stolen from 420,000 websites, according to The New York Times. The websites ranged from Fortune 500 companies down to small online retailers.

Should You Back Up Enterprise Data to the Cloud?

Six questions that need to be asked before signing on with an outside service.