Consumer companies such as Google and Apple have adopted increasingly rapid release cycles, and now corporate IT departments are faced with similar expectations. Here's how to adapt.
Once upon a time, serious IT leaders could sit in a conference room with their business and executive peers, and discuss software development and implementation cycles that stretched across a number of years. A major ERP implementation that spanned half a decade could be proposed without anyone raising an eyebrow, and timeframes in the 18-36 month range might even be considered quick implementations. Walk into a boardroom now and propose a five-year software project, and you'll likely be laughed out of the building.
The Google and Apple benchmarks
One of the defining technologies of the past decade was the consumerization of the smartphone and the associated rapid development and release cycles of smartphone hardware and software. Each year brings a parade of new and different devices, combined with OS revisions that present dramatic visual changes and hundreds of functional changes.
It may be an argument that makes technologists cringe, but we're increasingly hearing "If Google can develop three new hardware platforms and launch a completely revised mobile OS in eight months, why can't I get my CRM in a similar timeline?" Whether these comparisons are legitimate might make for an interesting discussion during happy hour, but the fact remains that corporate IT departments that propose massive, multi-year timelines are going to be compared with consumer development cycles.
One of the silver linings of more rapid development cycles in the consumer space is that most internal "consumers" of corporate IT are growing more accustomed to rapid, iterative development. Every employee who has owned a popular smartphone has seen a favorite function or a favorite app that's arrived on the scene with limited functionality or a collection of bugs, which then quickly evolves and improves. Some suggest this is a license to deliver poor quality software and fix it later, a tactic that should only be employed in the most dire situation. Rather than excusing quality, rapid innovation should allow you to take a "minimum viable product" approach to delivering functions.
In the past, huge implementations would take on large chunks of functionality and deliver a complete system over a long timeline. Due to changing expectations around time and functionality, it's now possible to deliver partial "chunks" of functionality that evolve and integrate over time.
While your users will accept a minimum viable product, they'll still demand a full-featured one, and it is incumbent on IT to carefully manage scope. All the careful work you've done shifting thinking from long, feature-rich releases to rapid releases with minimum functionality will be quickly undone once you start accepting additional scope.
Becoming Agile (carefully)
Agile, or one of the many similar rapid development approaches, is frequently cited as the panacea to demands for a more responsive IT organization, and it's certainly a component of the overall objective. Being successful with Agile requires far more than a few new tools and fancy words like scrum, and in the worst case Agile is the excuse for shoddy documentation and testing and an enabler for a poor end product. Even the best methodology will never save a poorly managed development organization, so if you're expected to produce quality code on a rapid cycle, ensure your people and vendors are all up to the task.
One interesting and often viable approach to the increased expectations on internal IT is to opt out of the implementation business entirely, and transition all your IT to cloud-based services and external organizations. This approach is not possible for every organization, but increasingly even fairly large businesses have IT staff in the single digits and nary a data center or developer anywhere in the company. You may have decades-old custom code that can be transitioned to a cloud platform, or even transitioned to a vendor. Just ensure that the company absorbing your burdens is capable of delivering to your expectations, and has financial incentives and penalties in place to keep them honest.
Many in IT may miss the days of multi-year development and implementation projects, where massive infrastructure and functionality were built and eventually deployed to great fanfare. While these projects do still exist, most of IT's work is transitioning to rapid, iterative development. This transition is not new, but the increased prevalence of consumer devices that have major releases on a biannual or even quarterly basis has set the bar, and as IT leaders we need to adapt, or be forced to do so.