This week I’ve sat in another couple of meetings with frustrated senior execs bemoaning the lack of progress with their new ‘re-platforming’ project.
This used to be a common phenomenon. The re-platforming, or even quainter-sounding ‘platform transition’, usually involved a technology vendor selling an enterprise-level software suite to a company with deep pockets and low technical self-esteem as a silver bullet to solve all of their current problems. 'It’ll enable us to do everything we can’t do today' echoed around boardrooms week in week out, swiftly followed by the slide with the big number on it. This was the age in which the Big CMS was born, swiftly followed by the end of many a career when the projects to implement them became money pits and political disasters.
Worryingly, multi-million pound/dollar investments in platforms that promise years of technological stability are popping up more regularly again. They share two common characteristics: they always happen in organizations with a technology legacy and they’re always positioned as a strategic programme of enormous importance. The underlying inference is always: 'we need to do this or we’ll die'.
In 25 years of designing digital services, I’ve yet to see one of these grand technology ventures become successful. Not a single one, in a quarter of a century.
Bizarrely, many are undertaking them when they have seen them fail before. I regularly hear a version of,’it’ll be different now because everything has moved on so much’, or ‘the technologies are so much better than last time’, or “we simply made the wrong technology choice before”.
They’re all missing the point. It has nothing to do with the technology platform itself, what version it is (most inevitably launch on an outdated version) or even how well it’s implemented. It’s not about how well planned the programme is, how well defined the requirements are, or what methodology is used to deliver it. It’s not even how good the people are that are doing it.
These programmes go wrong because they are fundamentally misaligned with the one requirement that is common to everything digital: change.
I think even the most regressive thinkers would agree that the imperative to adapt to shifts in fortune and market are more pressing now than they have been at any time in history. Put simply, you need to change to survive, and when you do, you need to change as quickly as you can. And in all likelihood, you’ll need to change again in a few months, and there’s every chance that change could be a substantial one. Change is the one constant in every organization’s future.
How can the need for flexibility and agility align with a big, multi-year re-platforming project? In most cases, the level of investment attached to the project alone demands strict governance and a high degree of predictability. Even those programmes run to agile principles inevitably get weighed down with politics and pressure. They’re scrutinised exactly as they’ve been positioned: critically.
Inevitably, they become a huge distraction. People stop focusing on what’s important (customers, competitors, new ideas) and instead focus on what is perceived to be important – i.e. the commitment to deliver that multi-million project.
They’re not only doomed to fail in their own right, they often suck time and attention from other aspects of the business, leading to lost opportunities and missed competitive threats whose impact reaches far beyond the platform project itself.
This is thinking from a bygone age, when organizations could afford to invest strategically in long-term security. Today, that level of stability simply does not exist. To deliver the kind of flexibility that organizations need today successfully, they need to think very differently.
Light and fast is the new solid and stable. Technology implementations that can be achieved in weeks and months should always be given the nod over those that take months and years. Multiple, purpose-optimised technology components will always beat one big integrated platform.
Think from a customer and commercial perspective, then build with the technologies that deliver on those needs as quickly and effectively as possible. Keep as much as possible separate from dependencies on other components and you’ll achieve the flexibility you need to act when you need to. In particular, keep data and content ‘clean’, and you can pretty much do anything you like with it.
Basically, stay away from dependencies on vendor platforms. 'We have to wait for version X to launch next year before we can do that' translates very quickly into 'we just lost our customers and gave our competitors a big leg-up'.
Don’t be afraid to be granular: use specialised technology implementations to service specific needs. A great CMS for managing an editorial workflow will probably be destroyed for performance to the end-customer by the latest lightweight front-end application framework, so use both.
Few brilliant technology executions these days are in any way ‘pure’: they compile the best components for each element of the experience, and those components are changed frequently over time. Continuous re-engineering and adaptation of multiple components are the new big platform solution.
So, if you’re one of those people sitting in the boardroom listening to the pitch for the big re-platforming project, don’t sign on the dotted line. There’s a better way.