“The Basics”

I was a part of a fascinating thread of conversation on Twitter last night about the challenges of delivering technology within organisations, particularly those with legacy and those that are big and/or organisationally complex.

Tom is in charge of the technology at the Ministry of Justice, and so has legacy, size and complexity in large bucketfuls.

Matt Edgar from NHS Digital made a very interesting point about the use of the term “Basics”…

And I’ve been mulling on that overnight.

Now I might be “seeing nails everywhere I look”, but I do think that my Play Matrix might help to unpack this a bit – to get a better understanding of the concepts of foundations, fundamentals, or specifics when it comes to managing technology.

First of all, a quick reminder of the model…

The world in this simple set of quadrants is divided up into known or unknown problems (or opportunities) and known or unknown solutions to those problems or opportunities. (More…)

My general observation is that industrialised organisations are best when they are focused on the top right “Plan” quadrant, delivering known solutions to known problems at scale, in repetition. It’s the core of the Taylorist/Fordist production line model that permeates so deeply into large scale organisations, and which is probably responsible for most of the things that surround you in the space in which you are currently reading this article.

When people talk about “getting the basics right”, my hunch is that they are mostly talking about things that exist in this quadrant. Products or services that can be bought, fully built, “off the shelf”. Networks, security, devices, operating systems, storage, ERP, CRM, collaboration tools and so on.

There is two sorts of value in this kind of stuff: its utility to make other things work, and its utility to reduce costs – either from buying a product rather than building it yourself or through reducing other operating costs within an organisation.

Now terms like “commodity” can get bandied around here, but ultimately in all but the simplest scenarios, the combination of all of these known solutions to known problems becomes of itself a bespoke overall answer to an organisation’s overall underlying technology needs. Even if you decided to go all-in with one supplier (most likely Microsoft these days), you’ll do it differently to any another organisation.

Some of that, given context, is inevitable. Some of it, however, should be avoided.

My favourite example of avoidable “messing around” (as I like to technically refer to it) was with the infrastructure I inherited at one of my former employers.

The organisation was a professional services business. It depended on people submitting timesheets each week. It was noticed that people liked using the Internet. So a hack was made in the Internet proxy server (an open-source product called Squid that provided a level of security to how people accessed the Internet) that stopped you accessing the Internet if you hadn’t completed the requisite number of timesheets.

This was very effective. It was also a deeply wrong way to go about it technically, which became immediately apparent when we moved the business to a Cloud-based calendar tool. People would be locked out of the Internet just at the point at which they needed to look at the Internet to check their calendar to be able to successfully complete their timesheet.

Messing around. Don’t do it, kids.

The problem facing organisations that have lots of old stuff in that top right segment is twofold. Firstly, it breaks and therefore stops other things that might actually provide greater business value (particularly stuff in the Adapt quadrant) from working. And secondly, replacing it generally costs money with vague benefits that aren’t particularly financially attractive because generally the costs of what exists today has been long since amortised so it’s essentially “free”.

This is then further exacerbated with a bias towards “sexy” new projects in management culture, and the risk that you can spend an awful lot of money and time to, in the end, be providing the same crap systems with slightly less interruption.

Here’s where the art of scheduling comes in, in my experience. Taking risks that enable you to do a bit of both the new Adapt stuff and the dull but vital Plan stuff at the same time. Again, back to the Imagination example:

• We introduced Google Apps (as was) into the organisation in advance of the introduction of a new network because I had enough data to tell us that it probably wouldn’t totally break the old network
• There were enough workarounds if we needed them in case of a catastrophe (public or 4G wifi)
• and that we would gain good favour from the organisation from the functional improvements from introducing the new services that would give us the political will to invest in the dull but expensive new network.

(Introducing a Cloud-based productivity suite today wouldn’t be quite as an “Adapt” project as it was back in 2009/2010).

What do I take from all of this? Well, that sequencing and prioritisation of work is a subtle mix of technical need, management need, financial need, user need and crucially building good political will across an organisation.

Oh, and once in situ, there’s probably no such thing as commodity IT. Certainly not in the way that, say, a kitchen can consume commodity cabbages.

Nobody said it would be easy…