Lab Notes

Lessons learned from Healthcare.gov

Why we should stop focusing on who’s to blame and learn to love the software development game.

 

Following the infamous launch of Healthcare.gov, I heard every digital project manager’s nightmares pouring out across all media – all day long. Every day.

People who have no idea what it means to design, build, or manage a project of this nature saying things like “computer bugs” and “glitches” and wanting to know who was to blame.

With the news of the official in charge of creating HealthCare.gov stepping down, let’s move past ‘who’s to blame’ and discuss what can be learned about project managing software.

The game of software development

Think of software development as a game, and every move that every player makes influences the outcome.

To win any game, there must be a shared understanding of how to win.

Chess: get the king; win. Monopoly: buy all the things and make your opponents bankrupt; win. Life: get the car and the good job and have a million kids and retire; win. Candyland: giggle with your kids and say funny candy words; win.

In software development, the project managers, developers, and stakeholders: These are players in the game. Designers, QA engineers, system architects: all players, each with individual roles to play.

The budget, the timeline, and the scope of work are inputs to help the players develop a shared understanding of how to win.

Project management must set a context for success. Right players. Right times. Right strategies for getting from concept to working execution.

Waterfall vs Agile Strategy

Some claim Healthcare.gov was built using “waterfall methods” and some say “agile methods” were used.

Either way, we don’t recommend playing the software development game with a waterfall strategy unless you can predict the future. Because in waterfall, the initial phase of definition is like pushing all your chips to the middle. It’s expensive if you get it wrong.

But if you know exactly what you’re building, and uncertainty is minimal, that’s a good time for waterfall.

We prefer to play the game with an agile strategy, which is to say we prefer betting small and having many small victories that add up to big ones.

Especially when complexity is high, we believe in an agile process with small, cross-functional teams sprinting to clarity through time-boxed iterations. We release more frequently, delivering small batches of working software only after they pass functional requirements we call ‘user stories’. These stories are written to meet the needs of real end users, and to have testable criteria that either pass or fail during QA.

If a batch fails testing, we keep working and do not release.

Healthcare.gov failed tests and decided to launch anyway. The results have been well-documented, but if success in the game you’re playing requires serving 50,000 simultaneous users, you absolutely don’t push live when you fail a test of 300.

“That’s all great, but who’s to blame?”

Stop it.

It’s the project manager’s job to recognize and communicate when unplanned obstacles or shifting requirements threaten the established timeline, the budget, or the scope of features, because you can’t have a shift in just one without affecting all three.

But if a project does go off the rails and someone asks who’s to blame, every hand should go up. Clients, developers, project managers, EVERYONE. And then you put your hands down and put your heads together and figure out how to WIN.

At GoKart Labs, we specialize in Invention & Business Strategy, User Experience & Design, Web & Mobile Software Development, and Digital Marketing. To find out more about becoming a client, call 612.454.4012.

Elli Rader creates, shoots (photos), curates, mentors, motivates—and she's a crackerjack strategist to boot. Her keen insight fine-tunes for our teams and clients alike. Along for the ride: kids, Dobby the dog and her All-City bike.

  1. Also, agile does not mean cheaper or faster. That’s probably not even an issue here, but I hear prospective clients say often, “How much can we cut the budget if we use agile?”

    p.s. Yes, Elli is smart.

    1. Anyone focusing primarily on cost savings is missing the point. Moving to agile is as much a psychological change as a tactical one, and it could be an expensive transition where you stumble before you really sprint. It takes buy-in to say, we don’t know all the answers, we can’t predict the future, so we need to plan to reachable points. But at the same time, we have to constantly be learning, adjusting, and bringing the foggy horizon into focus. Not easy to do on the fly. Requires buy-in to a consistent process. But business and product owners should consider agile because it allows you to apply the most current knowledge about business and user needs. This results in smarter, more efficient spending of development dollars. But less spending? Ideally, the business grows faster because you’re adding more value and you end up spending more dollars on development because your customer base is growing so fast.