19 Oct The fallacy of big change
I was always taught in school to think big. Let’s face it, growing up in America you would never contemplate thinking small, would you? It’s counter to the DNA. Anything is possible if you work hard. The sky is the limit. Big: Good. Small: Bad.
Let’s start with Big. If I mentioned “COTS” and you know what I mean by it, then skip this paragraph. Back in the good old days, when people talked to each other on the train, when there wasn’t a web and when software was developed on mainframes (IBM) and mini-computers (DEC), we had to build systems using software products (Commercial Off The Shelf software) and hundreds of thousands of lines of code to knit them all together. Some software companies seemed to have it all… but it still took nearly half a dog year to get things up and running, by which time the original requirements were always outpaced by business change.
Those systems were the foundation of modern enterprise, and many are still in operation today. They are inflexible and cannot keep up with change without undertaking very costly and time consuming projects.
So the obvious answer would seem to be to replace them. Think of a hundred year old oak tree with roots that are tangled, very deep, and nigh on impossible to uproot.
Enter the IT Transformation Programme. Untangling the mess takes very careful planning, often over years and lots of clever people to envisage how to go from where you are today, to where you want to be. And it must be called Transformation because that word drags in the big budgets, as companies must work out how to digitise every aspect of their business.
It all makes perfect sense.
Except when the expectation is that it all needs to happen at once. Basically, like saying that I won’t leave my house to drive to Heathrow until I know that every light between here and there has turned green.
Fast-forwarding to my point. In this day and age, with modern software architectures in the Cloud enabling services that can be easily configured to meet evolving business requirements, and integration methods and middleware that allow for very simple data integration, do you really need to wait until all the lights have turned green?
Or can you make small incremental changes where it is needed most (with an end-state in mind), and start realising business benefit immediately? If you are particularly canny about where you start, you can actually fund the entire Transformation Programme on the ROI that you bank with that small project that went live in the 4th week.
And what if you got it wrong? Well, at least you will know it, and you’ll know it fast. It’s better to have made 10 small wrong decisions than no decision at all, because at the very least you will know what not to do again (cue the Fail Faster ethos).
So small is actually beautiful, safe and smart, and sometimes being the biggest ain’t being the smartest. Ask the dinosaurs.