Thursday, May 12, 2016

Stopping Self Harm in Corporate IT

If you've worked in any corporation for a time then you will have come to realise that it's not the Darwinian, survival of the fittest, lean and mean chess playing machine that exists in the fantasy land of Harvard Business Revenue (ed. sounds more apt than Review)

Your average organisation is full of

  • duplication. Examples of 100+ projects doing exactly the same thing in an organisation are not uncommon
  • bias.  Lots of custom building that which is already a commodity
  • miscommunication and alignment issues
  • strategies which are a tyranny of action (how, what and when) with little to no strategic reasoning (why here over there) but instead endless meme copying from others
  • constant restructuring to bolt on new capabilities followed by further restructuring to remove it
  • constant missed opportunities where obvious changes are not taken advantage of.

The list goes on and on. As one chief exec told me not so long ago, "We survive because the other guys suck more". It's not so much survival of the fittest (which gives a positive image) but instead survival of the least sucky.

In this post, I'll talk about one relatively simple method to stop the worst excesses of self harm through the use of spend control. This is not about gaining some advantage over others but to solve a particular problem highlighted by another executive - "I've a hundred CIOs running around spending millions. They're like new born infants out of control. My first problem is not they keep burning the cash but that I need to stop them causing self harm. In other words, how do I stop them from wiping their faces in shit?"

Wiping their faces in shit? Sounds a bit excessive. But lets look at the problem. You've a 100 CIOs each operating IT within a business unit. That means you've probably got at least 100 different ERP, CRM, Order processing, Account receivable, Payroll, Storage and other systems. I say at least because it's actually common for a single business unit to have multiple of these things on its own. 

As a naive youth, I used to think 380 customised ERP systems built by 380 different teams was a lot of duplication for a single company but in my more gnarled experience, I realise that a lot is when we get into the thousands. In my naive days of youth, I used to think that 80% of IT spending being wasteful was an outrageous and rare figure. These days, I assume that when I walk into a company that 95% of IT spend is being wasted on duplication, bias and no hope projects. 

When people talk to me about enterprise content management (ECM), I know that in all probability we've got 200 to 300 different ECMs spread among those 100 business units along with at least 2 or 3 global ECM efforts being built by teams who don't know the others exist or only discover each other by accident. The old "We're building a global single sign on solution" followed by the "Oh, but that's what we're doing" followed by the "really? Same here" is an not an uncommon conversation when IT folk from a single corporation get to meet at conferences.

Of course when we talk about popular topics like IoT or big data then there'll be a few hundred business unit efforts, many more hundred skunk works along with a dozen or more global efforts buried under the portfolios of executives looking to be in charge of the next big thing. In a topic like this, you can easily get many hundreds and in the worst cases thousands of people involved in rebuilding the wheel again and again. I know of one global corporate that has 170 different teams building the same cloud projects. 

On top of all this, you'll get projects trying to create interfaces between all the other projects. If you've got 80 different ERP systems and you want inventory list then you'll probably have half a dozen different projects either building interfaces or data warehouses or some other mechanism trying to get all the data together, translated and transformed into a single view. I say half a dozen because why build one when we have such a glorious history of doing the same thing many times at the same time.

Into the mix some CIO will be planning to spend another $10M or so on a data lake, oblivious to the 10 or 20 other data lakes we already have and the further 5 under construction. Naturally, a highly expensive consultancy report being commissioned will probably recommend a lake of lakes - to be home built of course - and is doomed to fail because everyone argues that their lake is special.

This is what most corporate IT is like. If you don't recognise it then you're either very lucky or you need to open your eyes more. For most of you, take your annual IT budget - in the above case say $3 billion. Now double it to $6 billion because a lot of IT costs get buried in other budgets (including basics like power, buildings or contracted out projects). Now multiply by 10% i.e. $600M. This is what you probably should be aiming to spend in total if you're a typical company. In the process of saving huge pots of cash, you'll be making users a hell of a lot happier. Except, you won't actually save anything as you'll end up doing more stuff. This is really all about efficiency.

However, you won't make the efficiency savings. Not because it's impossible but because you lack transparency, challenge and any common mechanism of describing the problem space and removing waste.  Unfortunately, chances are you won't fix this problem. 

Instead you'll probably hire a consultancy firm which will recommend several floors of consultants (surprise, surprise) and a death star project which involves massive cost overruns and never fixes the problem. If you're lucky, a strong CEO or CIO will go "bugger this" and force the entire company down the route of single cloud services. All hell will break lose as business units (egged on by local IT) claim that using Google mail (for example) doesn't fit their needs or the regulators say we can't or it'll impact differentiation or God or some random bloke on the street or the aforementioned consultants (out of fear of not gaining another floor) said it was a really bad idea or isn't "Enterprise Ready" or legal says the contracts aren't "right" for them or "we want to but we don't have time to migrate as we have to sign the new 10 year extension tomorrow" ... blah, blah, blah, blah. Using the axe is a good thing at times like this. 


Anyhow, lets assume you want to fix this and I mean permanently going forward. Well, this has to be iterative and so you can't do a big bang approach.  You can't also just take the CIOs budget away from them. Instead what you want to do is encourage transparency and challenge. Spend control to the rescue!

First, create a spend control group staffed with a a dozen or so people from inside the organisation who have elements of engineering, business and architecture skills. The job of the group is simple - to create transparency and understanding about the IT landscape, to introduce challenge into the process of spending, to advise and support the CIOs on making better decisions and overtime to help the organisation learn and devise strategy. The latter parts are for another day, for the time being our only strategy is to "try and suck less".

The job of spend control is easy to explain. Before a CIO spends any sum of money above a specific limit (use $100K to begin with) then they need to submit a form to spend control, outlining the amount, who with, the user needs being met, the customer journey and a map. This is information the CIO should have and if they don't can be created in a day or so. The spend control group should help here by providing support on how to write a customer journey and a map.

A Wardley Map


Once spend control has this, they should look at the map and check does it focus on user needs? Focusing on user needs should be a core doctrine of the company and something that everyone does.


Now compare the map with other maps. To begin with, you start with no maps to compare or just a few but over time you have many and can create a profile of common components reappearing on different maps. What you're looking for is bias and duplication along with building a common lexicon and you can do this because the maps provide a common language and you have some transparency because people are sharing them.


Once you've identified duplication and bias in your map, you can challenge it.


Some of the components you'll have no other reference to in your other maps but you can still use a cheat sheet to challenge by looking at the properties.


You can also often find unmet needs i.e. those covered in other maps but should be in this one.


You can also look for more industrialised and common components that are suitable for shared services or cloud or common components (the green dots). Later on, you can use this to find new opportunities but that's not the focus of this post.


So, spend control, after a couple of hours work can go back to the CIO and say 

---

Thanks for the info. 

Around 80% of your project is currently being built by Team [XYZ]. By using those components you should be able to reduce your project cost from $10M to $2M.
The parking system you're thinking of building is likely to be available in the market as a product and doesn't have to be built from scratch. We've had a look and found this project [DEF] which might be suitable.
You're missing a bunch of user needs we think it might be useful for you to include [ABC].

---

The more maps you collect, the better your understanding of the entire landscape and the more you can challenge. This is an iterative process, you don't try to boil the ocean with floors of mega bucks consultants designing a death star but instead every time a system is designed or comes up for re-compete then it loops through spend control. Bit by bit you clean up the mess building common components as you go.

Now, sometimes spend control has to say No because a CIO wants to do something anyway. Hence it's important that spend control is involved early as some will try and railroad i.e. we have to sign this contract now or else .... blah, blah, blah. The key is, Spend Control doesn't take away the budget but instead introduces challenge and can (in the worst cases) force a CIO to find a better way.

Spend control fulfils the essential corporate roles of understanding the landscape, teaching others how to do this, introducing challenge to project and where necessary enforcing basic doctrine (focus on user needs etc).



Before someone says, we do this already - ask them how many ECMs they have in their organisation and how do they determine duplication and bias. In over 99% of cases, they don't.

Overtime, you can increase the doctrine i.e. you can ensure appropriate methods are applied ...


... or you ensure projects are broken down into sensible contract size and FIST (Fast, Inexpensive, Simple and Tiny) principles are applied.


... or you ensure a sane organisational structure is applied (use small teams).


... or you can ensure that the organisation is designed for constant evolution by considering attitude.


After quite a long time, once you're on the path to getting rid of much of the waste then you can start to look towards more strategic play and at this point then spend control grows into your strategic arm of the company. You can start learning about common economic patterns, start anticipating change in your market through weak signal detection, find opportunities through common services and discover context specific gameplay which you can then use in iterative strategies. However, that's way beyond this post. 



To begin with, we're focused on simply stopping self harm.

Oh and be warned ... lots of people don't like the idea of challenge or transparency especially vendors and consultancy firms. Keep a close eye on those who try and derail it. You're going to get some and whilst the overwhelming majority will simply be innocent inertia, I'm afraid there's a more seedy side. You might well find a few who are "influenced" by your own suppliers - conference events, jollies, gifts etc etc. The problem is that by reducing waste you'll be hitting the bonuses of others. The same approach can also be used in finance, marketing, operations and the business but I'll leave that to another day.