In almost every conversation I have about a product with an organisation with more than one title, there is a conversation about how much should be centralised or localised. Most organisations will want some kind of centralisation to make the most of economies of scale. It makes sense on both cost saving and ongoing ease of management. There are many factors of consideration — such as grouping these systems by brand alignment or by function/feature, as well as how much is centralised.

However, that’s not the debate I want to highlight here. I want to look at the approach taken to centralisation. 

If we start with a simple premise that it makes sense to build in a reusable way — which is what product is all about — what does that actually mean when it comes to centralising functions? 

If you’re starting a new product from scratch, the conversation and decision-making can follow a traditional product development process. However in most circumstances, centralisation is either coming from legacy structures that need modernising or by acquisitions that need integrating. Assuming there is some flexibility in choosing a system, let’s look at two ways to approach this. 

Option 1: Replatforming

Effectively this starts off in the same way as a new product: speaking with relevant stakeholders, going through a needs analysis, understanding the needs and the problems that need to be solved. 

Sometimes it is clear a fresh approach is needed and thus the traditional product development process can be used for selection. However invariably you will find some stakeholders love their system, others will loathe it, and there will be many opinions in between. The bigger the portfolio, the more diversity you will find in these needs.

After a lengthy process, you may get to a one-size-fits-all. But there are often so many different demands that during time it takes to get to a consensus, most people will have to make compromises somewhere along the line. 

Anyone who has been through it can tell you that migrating systems is no mean feat — both from a technology perspective and from a stakeholder/people perspective. With these factors in mind, we often find the replatforming process is long ... with many bumps in introducing a large change to workflows making it tough to make everyone happy. Unless, of course, the legacy systems were so in need of an upgrade that a change is welcome. We’ve seen this at some companies such as The Dallas Morning News (check out the Webinar here). 

Option 2: Using existing solutions

As identified above, through discovery you often find that there are systems people love or are so integrated into workflows that users don’t want to let go. 

Rather than scrap the entire system, could it be adapted and rolled out to the entire organisation?  This can be one large migration, which some companies have been able to pull off. Just look at Gannett’s acquisition of  GateHouse Media. They have integrated many back-end systems and are now reaping the benefits.  

An alternative approach is to migrate the system to a small subset of the organisation that is facing similar challenges: other subscription based titles or weeklies. If you’re lucky, one of these groups may even volunteer to be the guinea pig for migration. This doesn’t need to be a major project involving the whole organisation; it could be a relatively small project. If it’s successful, you can share the win and encourage other departments or units to follow suit, give them a carrot so to speak.

If needed, you can also follow with a stick: Let people continue with their current systems at their own cost or centralise to the preferred system where the costs will be absorbed elsewhere. 

And if it hasn’t been successful, you’ve saved yourself a lot of time and energy. 

This may seem more long winded and even counterproductive to the theme of centralisation. But by getting people to adopt systems that are already tried and tested — on their terms — you may be able to move faster overall. And, perhaps more importantly, you may create more desire to be part of a success story. 

To sum up: This is your friendly reminder that we don’t always need to go for the big wins. Sometimes starting small and building on successes — learning as we go — can work just as well, if not better, than attempting big change. 

If you’d like to subscribe to my bi-weekly newsletter, INMA members can do so here. 

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .