A common refrain we get when talking to organisations is "we really struggle to get anything done": this article explores this in more detail. 

There are plenty of reasons for organisational inertia: most people do not like change, for a start.  However, one that rarely gets the air time it deserves is the agency problem.  How so?  It is most visible in formal outsourcing arrangements, where two organisations are bound by a contract to do something.  Of course, to the client in this arrangement, that "something" is the achievement of an end goal for them: better client experience, cheaper administrative processing, etc.  For the outsourced supplier, however, the aim is the delivery of an agreed set of processes for a profit.  Of course, this dissonance is camouflaged at the time of signing by warm words ("think of us as your own team/partner/department, blah, blah"), soon to be drowned out by client howls of frustration as the operational teams take over.  As time moves on, achieving those same client aims require different means.  To the client, nothing has changed: to the supplier, everything has.  A bit like a rail passenger who, congratulating themselves on buying an advance saver ticket for a particular train, arrives breathlessly on the platform having missed their return journey due to sh*t happening, forking out for another whole ticket.

I think everybody understands this.  So, after all the evidence to the contrary, why do people keep opting for arrangements that exhibit a world-beating combination of inflexibility and expense?  This gets to a point less widely made: the agency problem exists within organisations too.  Consider the first question in this paragraph.  Why do people sign these things if they know they often fail?  "Yes, that is true if your marker of success is the winning long term prosecution of the organisation's aims and priorities", would say the aforementioned leader/politician signatory under the influence of a truth drug, "but it fulfils my aims perfectly, in the timescales that align to mine (two years).  Not only can I represent the awarding of a contract for X as solving X (ideally with a juicy £amount announced), but that the issues will only start once I'm safely gone - ideally to an advisory position at the same outsourcer". 

The agency issues exist throughout an organisation, and not just at the very top.  Consider the case of the lowly IT project manager - they are "one of us", right?  Well, it's best to think carefully how they are incentivised, and how they might be penalised: incentivised to deliver "on time, in budget", and penalised for any deviance in either.  What's wrong with that, I hear you ask?  Well, it's worth noting that there will be a reason for the project, something to deliver on the organisation's aims - a richer client experience, for instance.  Notice that does not sit anywhere in our dear project manager's view.  So what?  To the project manager, what's most important is the project and its conduct, not what the project is designed to fix.  It's also not their job to think like an owner: to them it's better that the project costs £100k and delivers only £10k over budget, than a £20k equivalent with the same £ overrun: 10% v 50%.

When we scratch our heads about why we can't move the productivity needle, this should be near the top.  How do you lessen the agency problem? I'll stick to our lane here, and concentrate on enterprise technology.  It's worthwhile noting why it's so difficult to solve.  The old orthodoxy had it that with greater degrees of specialisation, you generate greater efficiencies, as specialism brings optimisation: the law of comparative advantage.  Whilst that was undoubtedly true of the manufacturing world, it seems less bountiful for more knowledge-based activities.  Specialism in this context is more likely to lead to silos, obscure to those outside, where qualified insiders gold plate their demands of a business "just to be on the safe side".  The walls of these silos are built from the complexity of modern technology and the volatility of modern regulation - who from company management can challenge those who speak "druid" about the dark worlds of cyber and regulatory compliance?  We have lost count of the times we have encountered use of the battle cry "GDPR!" as a reason for not improving an organisation's grip on its (legitimate) data, just in case something goes wrong.  Read the legislation and you'll find it remarkably sensibly written. 

Back to the tech.  The cloud, as we keep banging on about, represents most of all a governance revolution: the chance for the business to interact with all the computing power they need directly, not through a silo.  Modern cloud apps offer all the lego bricks a business needs to store its data, power its processes and colour its reporting.  Our advice? Take one problem that currently sits in the murky silo and give it to a bright young thing to solve, just using the tools you might already have - Microsoft 365, Zoho, Salesforce etc.  You might be surprised.

We have recently completed a tender process for a client which threw up some interesting things.  The Client, a big national charity, engaged us last year in a survey project to update their old Case Management System, which resulted in our recommendation to spin up something in one of the world's two biggest modular cloud systems, Zoho and Microsoft.  We could of course go into the reasons for this, but that is not the point of this particular post (you can get some of the reasoning here): what was interesting (and what we weren't expecting), was the importance of culture in the process.

Both Zoho and Microsoft offer a wide-ranging set of apps, available over a simple browser that connect to each other to solve business problems.  Like any comparison, there are strengths and weaknesses in both sets, but we were expecting that the client would not have to worry about the technology, instead concentrating on the perceived "fit" of the applicants touting the technology to the client organisation.  However, it was fascinating how wrong we were: despite the fact that the licence costs of the underlying technologies were pretty similar, the quoted price of the project proposals from Microsoft vendors was roughly 3 (three!) times those of the Zoho partners.  Not only that, but the Microsoft proposals emphasised the estimated nature of the price, whereas the Zoho partners were happy to quote a fixed price.

As part of our initial engagement we had built a prototype of what the eventual application would be - we usually do this and it's a great advantage of a cloud-based app universe.  As part of the tender process we offered allcomers the chance to log into the prototype, not least to avoid the client having to pay twice for the same initial survey.  The Zoho vendors were all over it, but this offer was uniformly ignored by their Microsoft competitors.  When the proposals came in, Zoho said "here's how we would take the prototype forward to fix your problem", whereas Microsoft said "here's the rates for our senior (expensive) consultants, here's our typical process, let's list all your obligations, this is the baseline cost".  It was only due to an admirable attempt by one of the Microsoft vendors to get down and dirty like Zoho that we had any Microsoft representation on the pitch roster at all.  But how did we get to this?

One of the problems of modern technology procurement is the fact that almost all players are tied to one technology.  It's as if you were at home, wishing to build a conservatory, picking up a directory and being faced with all sorts of specialists for brickwork, joinery, RSJs etc.  Do I need them? How do they fit together?  Of course, you have a builder in the real world, somebody who can translate your need to exploit the excellent views over your back garden into the necessary bits.  In tech, not so much (unless you are a multinational and can afford the exorbitance of a big four consultancy).  Another consequence of this insularity is (evidently) an inability to learn from others.  Interestingly, the Microsoft cloud is really their product set from the old "on premise" days, configured for web delivery (you could recognise Sharepoint from 2000, for instance).  And, just as the Microsoft products are basically cloud immigrants, so are the people versed in them: most Microsoft vendor employees started in internal IT departments where everything was expressed as time and materials.  Zoho, by contrast, is a cloud native, with a vendor community that often started by implementing it as part of a business team.  So what? Zoho is streets ahead in productising not only the front end but all the admin functions, allowing non-technical people to run them, whereas Microsoft is a bag of spanners behind the scenes, offering something that only an IT team can make sense of.  If I were a Microsoft vendor, I’d look to mitigate that product disadvantage by pre-casting a set of Microsoft tools into something more definable and manageable, suitable for the 95% of business needs (somewhere to store stuff, a means to run processes and reports off the stuff, and a simple interface for people to interact with the stuff on multiple platforms).

But will they bother? Given the lack of independent tech consultants for all but plutocrat firms, maybe it does not matter that, code for code, Microsoft is massively more expensive than Zoho (or any other cloud-first offering), especially as Microsoft is often the only thing most businesses know about, as they contemplate their Outlook inbox.  However, you should be aware that there's a ton of good software out there, all available "as is, with a few tweaks" - i.e. a fraction of the cost of the traditional stuff, and with lower risk.  It’s not just about licence costs.

It is difficult to overestimate the revolution wrought on the world of freight by Malcolm McLean in the 1950s as he realised the benefits of a single, standardised container infrastructure for the movement of stuff (broadly) regardless of the nature of that stuff and the mode of transport. The world of information is ripe for a similar upheaval.  Of course,  critics can point out that this is precisely what the World Wide Web represents. Tim Berners-Lee's vision of standardised methods of display and connection prompted the memorable phrase, 'a massive one-off positive information supply shock'.  The Dot Com Boom was born, and a succession of companies were launched on stock markets with heroic valuations.  Of course the boom turned to bust - it did not herald the new age as advertised.  Why not?

First, all maniacal investment booms turn to bust eventually, regardless of the nature of the assets underneath.  A Dutch tulip bulb has its worth, just not equivalent to a country estate.  Second, technology is not a business model: hype does not equal revenue let alone profits, and too many Dot Com darlings did not make any money.  Third, and most relevant to this blog, the dreams of a frictionless, standardised computing environment were just that.  As any web developer worth their salt will tell you, developing anything other than an online brochure requires a complex code dance to cope with the different browsers out there.  And, it's all very well to talk about the display layer (i.e. The browser), but what about the picture underneath?  It's still a jumble of competing technologies to store the data, and serve it into the browser for the user to interact with.  Thus businesses are saddled with an accumulated cludge of tech that was commissioned at one time for the management of information, perhaps better known as stuff: different types of stuff, granted, but still stuff.

Historically, there was an excuse for this.  Technology was in its infancy and even commercialised products were largely built in a vacuum, where each piece was chosen on its merits for that project, and not to fit into a wider set of standards, as those standards did not exist beyond the establishment of popular coding languages.  However, from the rubble of the Dot Com Boom came a few survivors who managed to grasp the need for a compelling product that generated revenue that might exceed the costs.  They also got around the discordant nature of all the subterranean bits of technology by bundling everything inside a website, allowing end users a simple way both to see their stuff, but also to configure what stuff was stored and how it could be displayed.  Thus Application Service Provision (ASP) was born, allowing businesses to manage standardised buckets of their stuff (client relationship management, for instance) through a website without recourse to code.  Largely through one such ASP purveyor, Salesforce.com, the geeky ASP became SaaS - Software as a Service.

Great, problem solved, I hear you say.  Well, a casual glance into any organisation with its legion of spreadsheets will tell you that there is a need to manage stuff not met by the use of the big SaaS apps.  This is partly down to the way organisations view these apps.  Salesforce is typically brought in by the marketing/client service department to manage their sales and service channels.  Actually, it is a cleverly designed extensible relational database that can be used to manage any number of business processes, any type of stuff: we have used their excellent Charity version to power all manner of things, not just donor management (see the Case Study here).  Second, its wide use in non-charitable contexts is difficult for a business to stomach due to its spicy per head licence cost.

Things are moving on.  From the provision of clearly-defined apps for particularly verticals, typically stated as abbreviations (CRM, ERP), we have progressed to more universal systems that offer all the building blocks (or containers) to assemble your own bespoke SaaS app.  Perhaps because of a lack of catchy name or defined purpose, these universal systems have had less traction: how many organisations use Microsoft 365 simply because they need to provide their users with Microsoft Word and Excel, and continue to see each other's calendars? Subject to the exact licence, all sorts of goodies are lying around already paid for, just waiting to  be assembled into, say, a mobile app that contains stuff that is usually sent round in a spreadsheet on a Monday (or was it the one sent round last Friday?  Who knows?).  As difficult as it is for IT pros to accept, information is just stuff to power processes and decisions, and in the same way that you would be happy for the firm's stationery and bottled water to be delivered in the same van, so other elements of its stuff can be delivered with the same standardisation.

With the bruhaha around the status of the government's WhatsApp messages to the Covid Inquiry, we thought it would be good to write another piece about the way organisations manage their information and come to decisions.  Whilst the Government is in the spotlight here, in our experience the blight of the little green icon has reached epidemic proportions everywhere: it is shocking how many organisations are run off a series of breathless messaging threads.

Why so shocking, I hear you shout?  Well, for a start the Government's own defence of its unwillingness to release the full trove highlights one of the big shortcomings: the messages mix the personal with the professional.  There would be a danger of divulging something deeply personal alongside something of national importance.  WhatsApp's pervasion is indicative of a "casualisation" of so much of our modern lives, where (perceived) tedious process has given way to (supposed) greater efficiency of an informal network of a coalition of the willing (or a cabal of the favourites).  It is a symptom of a drive to blur the distinction between the office (the formal job title) with the officer (the person filling that role).  Thus Tony Blair saw nothing wrong with "sofa rule" and Donald Trump can apparently declassify highly sensitive government papers "by thinking about it".  This is not an exclusive Political disease: there are plenty of this in other sectors.

Why is this dangerous?  I'm sure there will be plenty of people who say that they cannot do without WhatsApp - but that is the point: as we have said before, a series of messages does not constitute an information network.  In this, we find ourselves in awkward agreement with Dominic Cummins, who wanted more "data-driven decisions", instead of the gossipy nonsense that passed for a process in government.  And we haven't even got to the security bit: when someone leaves office, who is deprovisioning their access to a channel?  Of course, building a proper set of information and managing the enterprise according to it is not easy, and requires two principle mountains to climb.

The first is to build a reliable set of information in the first place.  The biggest cop out in the world is for businesses to settle on a series of "KPIs", in itself seemingly sensible, but really a way to narrow the information set so far that the hard yards of normalising data sets so as to combine them programmatically is magically avoided and dear old Maureen from Accounts can continue to work her alchemy on the handful of numbers that the management group "needs".

As hard as that first mountain is, it is nothing compared to the second: an acceptance that the enterprise and its information is bigger than anybody in it, especially the boss.  Data-driven decisions will, of course, open up the possibility of data-driven shortcomings: we all love to berate the Bank of England for its "failure" to predict the rise in inflation, whilst labouring mightily to avoid any such independent scrutiny of our own work.  In this WhatsApp is really only the symptom and not the cause: we are struck when moving new organisations onto systems like Teams, which offer public channels for each business subject, how many new users scurry for the safety of the little bit of the app that allows personal chats. Plenty of our senior clients will complain that "it would be inappropriate for me to write x in a subject channel" - of course HR is a legitimate concern, but most of the angst comes from the fact that public channels do not allow for the selective patronage of private sub groups in an organisation, where advancement comes at the price of uncritical support and acclaim, regardless of what the data said.  Leadership is a responsibility, not a privilege.

Let us be clear: there are plenty of times when experience is vital, and valuable.  No matter how much theory is digested, there is often no substitute for having actually done something for a while to optimise an outcome.  Or at least make sure that complete disaster is averted: looking up at the summit of Snowdon on a bright warm morning can lead the newbie to potter off in a pair of flipflops, unaware of what can happen.  In the enterprise, key processes rarely flow exactly as the manual states they should (even if there is a manual, which is a rarity).  The departure of so many 50-somethings into early retirement has contributed to much grinding of corporate cogs as their combined nous disappeared off to the golf course.

There is,  however, another way of looking at all of this, particularly from where we sit.  First (and it's a theme we keep coming back to), firms rely far too much on an informal network of experienced people and a bundle of spreadsheets , and far too little on building a coherent information set that can be queried independently and flexibly.  Maureen, the amazing management accountant, can always be relied on to produce those sales figures for each month's management meeting.  How does she reconcile the figures from the Hungarian subsidiary, and normalise those from the recent acquisition?  No one is completely sure, but everyone is super grateful.  They have same report each month that is consistent and looks good.  Sitting in a meeting and wondering whether there is a corelation between an ad campaign and a product's sales, split by territory? Let's look at that at the next meeting.  In a month's time.  If Maureen is around.

Second, given the speed of the technology revolution, experience can be positively unhelpful.  Even if the aforementioned firm has a Damascene conversion and asks the IT department to build a properly organised information store that is accessible by all that need it (including channel partners), those they ask are often burdened by their experience, not buoyed by it.  Having been brought up on a diet of servers, a Network (with a capital N), firewalls and IP addresses, they go about buying and/or building an asset that can be added to the balance sheet, much like you might a building.  If they get the approval to spend the ferocious amount (the reason why Maureen still exists), forests will be felled in a desire to appear all over it, approaching the issues from first principles, as if there had never been quite this problem in the history of the world.  The solution will appear (eventually), over budget and solving last year's problems.  The huge capex will gently be depreciated away, with a whole bunch of future liabilities added to the P&L: servers to be patched, outsourced configurators of firewalls paid handsomely to maintain the rules for all the channel partners to access data, of course with fixed IP addresses to ensure "top" security into the Network.  Meanwhile, Maureen steams on unperturbed. 

To use the easily accessible modern world of cloud technology you don't need an experienced individual as the technology was only released recently, so nobody in the world has that experience. The paradigm we all grew up with regarding the recruitment of experienced people is no longer applicable... Indeed you could argue that the opposite is true; to utilise these incredibly powerful modern services you need to be super curious and hungry to experiment with services that were only released last week, last month, this year... nobody has the experience, yet millions of people are adopting those services right now and solving their business needs in minutes for pennies.  

Unmarked by experience, Miriam joins the Accounting Team as a grad.  At University she read English, and was used to logging into a web page to interact with her tutors, and used Microsoft Lists to maintain the details of the College hockey group she was secretary to - everyone had access, and could update their details for availability etc.  She wondered why it was so difficult in the "sophisticated" world of the adult enterprise - why not spin up an instance of Power BI management reporting (which the firm already licenced, but was lying around) and use it to bring the flat spreadsheets to life?  Why, after a couple of days with youtube, can't we pull those data into a few simple database tables (again, using stuff already licenced and lying around) and spin up an app for all those (internal and external) who legitimately need it?  Why not indeed.

Experience counts as a blocker on a number of levels.  First, it prevents the storied IT professional from getting beyond the asset -perimeter-Network paradigm to the service - user world that is so compelling now.  Second, it prevents the business understanding that such web services can be procured and managed without recourse to people trained in ASP.net.  Lastly, dear old Miriam is unlikely to exist in real life as she sees herself as thoughtful and sensitive, not a geek.  We all need to reinvent ourselves.

A few things have caught my eye over the past few weeks.  First, the publication of The Big Con by Mariana Mazzucato, where she makes the point that public authorities have become infantilised by dependence on consultants, leaving them unable to innovate (or even operate) on their own.  Second, some of the more thoughtful analyses of the Ukraine conflict have highlighted the extent to which the ability to manage and exploit information is the critical difference, and not just in the ethereal realm of cyber warfare, but also in the world of blood, earth and iron.  Third, the much heralded launch of ChatGPT, the first tech truly to give white collar workers the heebie-geebies.

In my world of enterprise IT, I am struck by how blighted my clients are with a particular form of this dependency so colourfully described by Mazzucato: they believe that they cannot survive without the constant support of another type of external specialist, the IT department.  As a soldier (years ago!), I started in the world of paper files.  There was a file for everything important and common across the unit, and a settled (internal) group responsible for their upkeep.  Thus, continuity and the ability to find things I wasn't looking for: as a newbie Operations Officer, I could unearth not only the documents relating to previous operations, but all the messages sent and received by my predecessors. 

Fast forward to the "improvements" brought by personal email inboxes, where the shared reality of the filing cabinet was replaced with an atomised shambles of point to point messages. Not only is this new tech worse that what it replaced (although it felt whizzy and modern), it was so flaky that it needed a specialist team to manage.  Soon not only the tools, but the information itself gets put in the hands of people who, whilst being able to write code, have neither the skills nor the mandate to exploit this lifeblood of the organisation.  And, instead of thinking strategically about their information, organisations descended into a language of "project deliverables", "tech packages", thinking that the action of apportioning a budget to something is the same as addressing a problem.

The interesting thing is that tech has evolved to a point where it no longer needs the constant intermediation of people for whom Star Wars is the last word in culture.  Whisper it quietly, but the WFH revolution showed how employees could have a direct relationship with their organisation's information, often using their own kit.  The much-feared avalanche of cyber intrusions did not transpire in this scandalously unfettered world: quite the reverse, where the damage was actually in systems that remained on premise, under the loving care of the network guys.  So what?  With the tech taken care of (“as a service”, as they say), then perhaps organisations can regain control of their own information, understanding their digital heartbeat so that they can respond as it changes.

And how important is that in Ukraine. I have worked with many Ukrainian organisations before the war, and was impressed by how they got it:  sort the disparate data, store it in proper relation to each other, and exploit the insights. Works just as well interdicting a column of Russian tanks as it did analysing bank transaction flows. Sadly leveraging native UK skills would result in what The Hitchhiker’s Guide to the Galaxy retold: it would be fine if a perm or a meeting was needed, but bugger all else.

 …which brings us to ChatGPT.  If all you do is have meetings and write narrative messages, or perhaps really push the boat out and use excel to list things, then look out. AI will always do this sort of thing better. To survive, (or at least to earn a human wage), you’ll need to do more than express a few nice words: you need to be able to inspire, to disagree with courage and tact, to build alliances and actually do something. Oh, and speak digital, the language of the machines. Sort, store, exploit. 

Recent news that we have, simultaneously, both high numbers of workforce vacancies and low workforce participation reminded me of what is going on in my little corner of the world.  Clearly there are many reasons for this combination outside the world of enterprise cloud computing.  The sharp snap back for hospitality after the pandemic, the reduction in the available European workforce, and a high number of older workers who never returned post Covid have all contributed to this.

But there are other factors at play.  We live in a world of uncomfortably rising prices and new analysis of the Seventies (which is so in vogue now) suggests that a powerful driver of those (stag)inflationary pressures was the world economy re-tooling for a new era - too little of what the world needed, too much of what it didn't.  And you can see this in today's world of goods: want a diesel Land Rover sir?  We have hundreds for you to choose from, all at a keen price.  Want a hybrid model?  That'll be nine months.  Want an electric version? 2024.

So, where does the Cloud come into this?  As for goods, so for skills.  Want people to manage their inboxes efficiently, capable of building a simple spreadsheet for managing a marketing campaign, and writing a powerpoint to show at the latest management meeting?  There are quite a few of those.  Even in the supposedly avantgarde world of web design, there are enough candidates if you are looking for page design, search engine optimisation, even management of google analytics to tell you how your pages are doing.  Surely the IT dept is at the cutting edge of what's required?  Actually, rarely.  Building expensive and bespoke technology stacks "on the network", glorifying in programming code and running endless projects is yesterday's game, and loads of people are conversant with that one.  The problem is that organisations have enough spreadsheets, emails, bespoke software and powerpoints, and there's only so many times you need to rebrand your brochure website.  It's no surprise that average earnings stagnate in this environment - company margins are doing the same thing.

What does the next generation organisation look like if it isn't office docs and brochure sites?  For a start, it needs to have its truth stored in something better than a series of spreadsheets.  Do you have a single view of clients?  Can you cross reference that with all your sales to drive margin optimisation and greater repeat business? What did we say to them six months ago?  Can we conceive of a better collaborative environment than shutting everyone away in their own little email inbox, and expect them to be on the same page?  How about having a web estate that actually does something, connecting directly to your suppliers and clients, instead of fretting about whether you're on the network or not, and thinking that setting up an FTP connection qualifies as integration?

What are the skills necessary for such a transformation?  An understanding of how a firm's information fits together, recognising that some bits benefit from super careful stratification, whilst others prosper when users are given some flexibility in how they're configured.  It's understanding how to protect and share at the same time, eschewing the nonsense of a "network" perimeter.  It's about using both the right and left brain - logic with emotional IQ.  The company equivalent of an electric Land Rover is the Information Manager: conversant with technology and its capabilities, able to sustain meaningful relationships both with those users of information and with a panoply of partners that supply the supporting software.  Quite rare, I think you'll agree.