F*ck it, ship it: 1 simple rule to always ship on time

The software industry is notoriously bad at shipping on time. It’s not rare to hear about projects being delayed by several months, if not years, and that’s when they aren’t canceled altogether.

There are many reasons to that. On the contrary of building construction, software is malleable and always changing. When constructing a building, you can make the plan in advance and it’s usually followed pretty strictly, given how buildings stand the test of time. When building a bridge, you’re not asked to rotate it by 45° halfway during the construction process. And your workforce can benefit from standardized tools that aren’t changing every week, which means they had the opportunity to master them and can therefore focus on doing great work. Building construction is also a science that has been perfected since the dawn of time, while software construction is only several dozens of years old.

Don’t let the “high tech” moniker fool you. Software construction has not yet passed the toddler stage!

And that’s great news!

The great news however is that, by being such a young discipline, software construction opens nearly infinite wonderful opportunities to contribute to building the new digital world. But as trying to seize them can be very challenging as explained above, this provides an almost endless supply of excuses to delay the shipping date.

A small delay can't do much harm… right?

The problem with delays, no matter how big or small, is that it’s exactly like skipping school or trying meth: you never do it just once. As a consequence, the software industry is full of delay addicts where “one-time shots” have gone totally out of control. Time for rehab!

Delays: not even once!

The solution is therefore pretty obvious: never delay the shipping date.

Sounds crazy? Yet that’s how we worked at McKinsey Solutions, the digital division of McKinsey & Company, where we have shipped many software products for clients such as the Fortune 500. On time. Never compromise on the shipping date, compromise on feature scope instead! Software teams were expected to anticipate what couldn’t be completed by the target date and come up with creative ways to implement what the client needed most, such as an 80/20 Pareto implementation followed by a quick release a few days later with the missing but less important features.

You can’t always do miracles and that’s ok. Do your best, be transparent with the client, agree on a solution and ship on time. What clients do you think are happier? Those who always get what they asked for on time, albeit a few small compromises, or those who are still waiting for months or years? And same for software teams: those who feel they are moving forward or those who have come to believe their work might never see the light of the day?

Oh, and by the way…

…here’s another very important rule: ship often! When you don’t, going live becomes a highly stressful, all-hands-on-deck, alarm-ringing situation where the magnitude of what can go wrong explodes. You don’t want that!

Conclusion

Shipping often and on time are essential components of a healthy software development process. Unless you’re building software for planes or nuclear plants, make sure to include them in your own!