To centralise or not – that is the question…

(…with all due apologies to Shakespeare and Hamlet)

Have been involved in a few of these discussions lately and many people seem to present the opinion that centralisation is the best, if not only, way to achieve order, efficiency and effectiveness. Consequently, if you are against centralisation you must by definition (almost at least…) be an anarchist or even a saboteur – because who else would be against efficiency and effectiveness?

However, in my experience (and at least at the process level where I do most of my work) the truth isn’t quite so black and white. My theory is that there is a rough normal distribution of a company’s processes, where both tails should definitely be either central or decentral, but also the majority is somewhere in the middle. In this middle band, you can pursue both strategies with almost equal chance of success, as long as you actually follow through on the decision. By ‘follow through’ I mean that you deal with the inevitable downsides of your decision, meaning:

  • Want to do central data creation and maintenance with a CoE-type setup? Well, you get central knowledge and you get the opportunity to leverage scale and over time build a real center of excellence to improve your business,. However, do your current processes support getting information from the people ‘on the coal face’ to the central team that executes changes – and do people feel a sense of shared responsibility and urgency? If you haven’t specifically addressed this and taken steps to analyse, influence and monitor, then the answer is likely to be a no.
  • Want to do decentral invoice approval? Great, you get a chance to promote accountability in the organisation and a very good chance to influence unfortunate spending habits where it really makes a difference (with the individual and/or department) – but you need to deal with training, turnover, more training, continuous policy enforcement, even more training for new joiners and so on.

So, the discussion on centralisation is now a strategy vs. execution discussion, where it isn’t what you decide that wins, but instead what you actually act on afterwards that matters. And, as Peter Drucker observed; “Culture eats strategy for breakfast!”, meaning that to strategise is comparatively easy, whereas influencing habits is usually very hard.

So, the next time you are in a room with someone discussing the benefits of centralisation, start probing them on whether they are aware of the consequences of the decision and if they are ready to follow through when it matters…

The power of negative…

No, I don’t mean a negative attitude because although that feels great sometimes, I don’t think it is a particularly powerful way of accomplishing anything :). What I mean is “negative questions”, i.e. “what can you do without?”, “what should this not do?” etc.

Usually when developing requirements, the business stakeholder/sponsor has no incentive to remove any requirements, which either means you get a bloated list that isn’t realistic or you get to play the bad guy when you have to explain why the pitiful budget that was allocated does not cover the whole list of requirements. And sometimes both…

Even with an unlimited budget, asking what the requester can do without force thoughts about real needs and priorities, thus helping drive the really important discussions and tease out valuable information. In many of these situations you can “opt-in” on everything without any real cost and involvement, but you can’t “opt-out” of anything without considering the consequences first and that’s what the architect needs to take advantage of.

People are normally a bit taken aback when you ask them what a certain system/process should not do, but the answers are usually worth it – especially if they are open about their rationale for saying no. Try this technique and you may be surprised at the results as well.