Let’s see if this situation sounds familiar. Your company is adopting a new-fangled enterprise software platform – announcements have gone out, the implementation team has been identified, had their proper kickoff, and some serious changes are in the works. Sure, the software is pricey, but just look at all those features! If even half of them work as well as the salesman said it would, it will be revolutionary.
But there’s a significant obstacle to overcome; there’s a legacy system to replace. Maybe it’s an ancient version of the new product, maybe it’s a perplexing labyrinth of home grown point solutions overgrowing the back forty, maybe it’s a little hamster running on a wheel duct taped to a file server. So yes, it’s occasionally slow, the one guy who knows how it all works is about to retire, and it blows up every second Tuesday. But apart from those minor inconveniences, the thing works. Not to mention people are really, really used to the old system because it’s been there forever. Forever.
Oh you mean, that button doesn’t work? It actually does, but the first click never works, you have to lean to the left and hold shift. Oh, and before running that workflow you need to verify that goats haven’t chewed through the data connection. We keep a couple of cabinets stocked with tactical goat repellant for those situations.
Despite of all of that, the old system hasn’t tanked the business, serves up some valuable functionality and has proven value. It does something effectively. Can’t argue that.
Meanwhile… at Wayne Manor, the implementation team is working diligently, and despite great progress there’s one hiccup. For one, a particular feature is really interesting but the way it works is too different from the old system. After an intense debate, it is determined that retraining requirements are just too high. The lead architect looks longingly out the window, briefly considers jumping out of it, and then solemnly states “We’ll need to heavily customize.” Sure it’s another 3 months in time and money on the schedule, but we need a smooth transition so business isn’t disrupted.
Two months later there’s another hiccup: one of the features the old system had doesn’t work quite right in the new, and a proper fix won’t be available until the next version. Because of complexity, there was no way to thoroughly test the feature in detail during the software selection process. Secondly, the program team for this one particular customer needs to stay on the old system until the program closes out to not impact their contract delivery schedule. Third, the customization work that was started two months ago is behind schedule and has caused some other features to misbehave, so some retesting is necessary and another schedule slip is certain. Another hard debate and again the lead architect looks longingly out the window, really starts to think he/she should have jumped the first time, and then solemnly states “We’ll need to adopt a coexistence plan.” Data will need to be replicated between the two systems, and that’s more time, money, and complexity, but hey business won’t be disrupted.
So the system is ultimately delivered, a year late and significantly over budget, but the old system remains in place, operating off replicated data with the same quirks it’s always had. The new system has some benefit, but some key features are not working right.
Before you had one complex system that needed improvement. Now, you have two complex systems that both need improvement. Congratulations! Cue S.R. Hadden:
“First rule in government spending. Why build one when you can have two for twice the price!”
This is a common trap. I have seen it time and time again. So why does this happen? I have a couple of thoughts:
- Accessible Enterprise configurability.
Right now enterprise software and their implementations mainly fall into one of two extremes, either Out of the Box (OOTB) or setups requiring significant codeful customization. OOTB is inflexible and may not meet the needs of the business as is, while customization can practically turn lead into gold, but often only after great time and expense. Often companies find themselves compelled to customize because OOTB falls short of primary objectives. An appropriate balance would be to provide user-accessible configuration in tactically significant capabilities, so the software can remain malleable, but at minimal time and expense. This is less important for the large enterprises, but a critical point for small business.
- Clearly Superior Experience.
Think about when you are buying a car, do you forgo the new one with adaptive cruise control because you are hell bent on a column shifter? Do you keep both cars around because the old one had 60/40 fold down seats in the back or if the sunglass holder on the new one is too small? Of course not. Because the new car is clearly better to you in overall experience, any shortcomings aren’t worth making a fuss about. That’s where enterprise software needs to go. Why? Users are paramount – creating a situation where the users pull on the solution of their own free will versus having to push something on them are two very different worlds. The new stuff has to be clearly better, not after an exhaustive analysis of comparative features, but from a human perspective. And that requires focusing attention not all on features, but rather user experience, performance, and software quality.