Contact

News

Feb 06, 2020

Iowa Caucus Debacle Repeated 3 Healthcare.gov Mistakes… and Added 4 New Ones

Jason Goth

Jason Goth

Iowa Caucus Debacle Repeated 3 Healthcare.gov Mistakes… and Added 4 New Ones

This week, a small mobile application brought the democratic process in Iowa to a standstill. There have been countless articles detailing what happened. But having been called in to rescue many failed implementations (Healthcare.gov, American Airlines, Blockbuster, just to name a few), it is amazing to see the same mistakes made over and over again.

A quick Google search outlines three of the obvious things that went wrong:

  1. Inadequate time for testing – the application was delivered just days before the primary, without time for testing across all phones or with appropriate validation of calculations

  2. Lack of performance testing to understand how the application would perform at scale and under load (when everyone uses the application at once)

  3. Lack of focus on security

Four Lessons Learned from the Iowa Caucus Debacle

So, I won’t write more explaining the importance of these things. Instead, as a company that develops mission-critical applications, I wanted to highlight four lessons learned that may not be as obvious:

1. Was an App Even Needed?

When launching any new technology, the first question that companies need to address is “Should we do this at all?”. Peter Drucker famously said, “There is nothing so useless as doing efficiently that which should not be done at all.”

So how do you know if you should do it? Some key things to consider:

  • What are the goals of introducing technology (improved revenue, reduced cost, faster response to customer inquiries, etc.) and how will we measure those results?

  • What will it take to build correctly, including appropriate testing, security implementations, documentation, support teams, etc. (Making software production ready can often exceed 3x-5x the actual development cost.)

  • Will the expected improvements justify the technology investment?

  • How can we introduce and validate these metrics without putting the implementation at risk?

  • At what point do we determine this isn’t viable and move on?

For more details, check out my colleague Jake Carter‘s excellent blog on Structured Innovation.

2. People Are an Incredibly Important Factor In Any Technology Deployment

Change management is a critical component of any successful new technology implementation. An easy-to-remember acronym is to ensure that new programs realize their goals is: SUP

  • Speed of Adoption: making sure everyone adopts the technology according to schedule

  • User Adoption: making sure everyone is using the tool

  • Proficiency: everyone feels confident on how to properly use the tool

In the case of Iowa, many caucus chairs opted not to use the app, others did not how to use it properly because they skipped the training, and some users tried to call support lines, but were reporting put on hold for hours.

To see more practical tips on change management, check out Raul Cervallos‘s whitepaper here.

3. The Goal of Any Application Is to Run in Production, So It Must Be “Production Ready”

Production ready applications do much more than just work correctly, they must:

  • Scale to production demands without sacrificing performance

  • Provide visibility into operations for problem detection and resolution

  • Provide reliable data and prove integrity of this data

  • Have well planned out failure and recovery scenarios

  • Be able to recover from failures

Mobile applications have even a higher bar to be made “Production Ready.” For example, they must be:

  • Designed with accessibility as a key feature (e.g. usable by those who are colorblind, use screen readers, require dynamic text sizing, etc.)

  • Resilient and able to perform on many device types, network conditions and phone states (i.e. when rotated or interrupted by a call) without sacrificing performance or functionality

  • Observable in that they incorporate analytics, crash reporting, and performance monitors to proactively alert operations teams of issues (because they are distributed to users)

  • Remotely configurable so troubled features can be updated, disabled or degraded without impacting the overall functionality of the application

  • Contain an internal audit log of key actions that can be replayed offline to facilitate recovery scenarios

Do you have these capabilities designed into your production and mobile applications? Often these are put on the back burner (along with testing and security validation) to save time and reduce cost. But the long-term impact is usually far greater than any short-term savings. As Benjamin Franklin said, “The bitterness of poor quality remains long after the sweetness of low price is forgotten.”

4. Don’t Ignore the Warning Signs

Many had warned about the potential issues with this new application over a month before the caucuses. There is almost always a tendency for delivery teams to downplay issues. “Sure, we are behind and have these problems, but we can catch up” is a common refrain. Likewise, managers and business units often demand dates be met regardless of warnings that are raised. Both sides must make an honest assessment of risks and issues and take appropriate corrective actions to make implementations successful.

What’s Your Technology Challenge?

Is your new product truly ready for prime time? Credera can help ensure the success of your digital transformation efforts across all aspects of technology, user experience, security, performance, and user/stakeholder readiness.

Reach out to findoutmore@credera.com to see how we can help.

Conversation Icon

Contact Us

Ready to achieve your vision? We're here to help.

We'd love to start a conversation. Fill out the form and we'll connect you with the right person.

Searching for a new career?

View job openings