Opinion: Whose Roadmap is it anyway?
By Danny Rappaport, PMC Director of Consulting
The average Retail CIO has a tenure of less than three years (average CIO tenure is 4.6 years) and a budget of around 2% of turnover if they’re lucky (Banking is 7.9%). This means the pressure to deliver value and make a difference, all while balancing the needs of the retail business with upgrading the technology estate, is harder than ever.
Any retail IT department and retail CIO must balance the retail business demands, with managing the often-complex partner IT landscape and contracts needed to deliver the Service to keep the business going.
Balancing the needs and priorities of the business with the imperatives and limitations of the technology estate can sometimes make it feel like the roadmap is being dictated by the technology itself, or the partners that provide it. The cycle of major upgrades, compliance patches, security fixes, minor upgrades, repeat... makes it feel rather like the ‘Keep calm and carry on’ slogan that was so popular a few years ago. I’ve also heard it referred to as the “treadmill” roadmap, which is understandable when the next upgrade is due moments after the last one finally settles down.
While it’s an easy sell to get the business to buy into some sexy new functionality or feature, a technical upgrade that gives the business nothing new is a hard sell; yet often this is vital to keep the show on the road. So how do we balance the needs of the business with the needs of the tech that delivers it? Historically system’s maintenance has been the largest single cost of ownership in IT during a system’s lifetime. The analogy of business-critical maintenance being like changing a wheel while the car is in motion is often pretty accurate, although it never really gets the recognition it deserves.
The art of the in-motion wheel-change
This isn’t as crazy as it sounds. In fact, not only is it possible but it’s been done! It takes balance, practice, teamwork courage and a complete disregard for how things are usually done that allows “run” and “change” to co-exist and even enable each other. A quick Google will show plenty of videos of the literal version i.e. some nut (I mean talented stunt driver) actually driving a car on two wheels while he/she or a very agile partner in crime (and it probably is) changes the wheel in mid journey.
The IT version, I’m sure you will not be surprised to hear is less exciting than the motoring analogy, even in retail. It’s called Devops and while it’s been around for a while as an idea, the practice is well established and is every bit as impressive in the results it delivers if done properly. There perhaps is the rub. Like all complex changes in ways of working it’s got to be done well, and there are as many definitions of Devops as there are practitioners. However, this wonder of process improvement is not as difficult as it sounds, and entails (or some might say enforces) the negotiation and balance of technical and business priorities.
I’m sure the Formula 1 motor racing fans amongst you will recognise the impressive process improvement lessons given to the world by the race teams that transformed the pit stop wheel change process.
In the 60’s (go on admit it you remember!) You must have seen the (black and white) films of teams of four or five frantic pit stop F1 mechanics changing wheels on the race cars, in what was then a ballet of around a minute. This was a pretty impressive feat with the tools, process and available resources at the time.
Pan forward to the present day (colour close up) and this happens in around two seconds. A team of 23 replaces a team of 4, powerful automation replaces hand tools, and an agonised over, deconstructed, and much analysed move-by-move process replaces the manual efforts of years gone by. The result is what would scarcely have been believed many years ago. The better car jack, and the faster and more powerful wheel brace may not have been the most popular spend at the time, but they all help in their own way.
I like the car analogy, but it’s not exact, and the 4 to 23 increase in staffing levels isn’t a good parallel, but the specialist skillsets vs generalist certainly is. If I had to predict the next phase of process innovation in this process it would be to eliminate the weakest link (humans) in this and automate it.
This of course won’t happen until the tools to automate the functions of the 23 people are developed and reliable.
So, coming back to our Roadmap. As we can improve processes over time, and tools will allow further improvement and automation, shouldn’t we plan to improve?
So many roadmaps just appear to keep things as they are. The reality is that the technical path and milestones on our roadmap enable the business to improve its performance, and just like the speeded up deconstructed tasks in the pit stop, they are important objectives along the way that contribute to the overall objective of a faster pitstop for the car.
So, while it may appear that some milestones don’t directly help the business when a roadmap is developed, with the business in an Agile environment and with a Devops process behind it, it is one roadmap and one overall objective.
Danny joined PMC as Director of Consulting in October 2021. He joins from Capgemini, where he was a Vice President in the UK, operating across verticals including Finance and Retail. Danny brings a wealth of experience in providing technology and business services to the retail, finance and CPG sectors, having worked in senior executive level positions in the UK, the Netherlands and India.
Danny has worked in a variety of roles in Retail, CPG and Financial Services in sales, delivery and consulting. Danny is extremely passionate about our markets and the opportunities that exist for our customers in today’s global digital economy.