6 Tech Takeaways From Sebelius' Tenure

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 joe@mckendrickresearch.com.

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 www.insurancenetworking.com do not necessarily reflect those of Insurance Networking News.

For reprint and licensing requests for this article, click here.
Policy adminstration
MORE FROM DIGITAL INSURANCE