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
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?”
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.