The Anchorage payroll project, now in its seventh year and with costs ballooning from a projected $10 million to over $80 million provides a solid example of how to guarantee an enterprise project failure.
We need to prepare for a world where people might not access GOV.UK through their computer or smartphone, but could be using Alexa, Google Assistant or some technology that hasn’t even been created yet. We need to make GOV.UK understandable by humans and machines.
This was originally published as the lead article in my weekly email newsletter. If you’d like to get more of this sort of thing on a regular basis, sign up!
Most of the stories about what organisations are doing on digital transformation tend to get published in the form of case studies, and most of those case studies are written and published by vendors of either technology products or services.
That’s fine, but I do tend to get slightly grumpy with them as they focus so much on the purchase of the technology and what it might deliver in terms of better and cheaper services. “Council X to save £300m by investing in the Norpita customer experience platform” – that sort of thing.
Partly the issue is the jumping ahead nature – none of those savings have been realised yet, no software implemented, no services redesigned. All that’s happened is that a purchase order has been approved.
But mostly, it’s because it leaves the impression that the technology is the panacea, that buying the tools delivers the outcomes. Also that this is a quick process, which it isn’t.
First, implementing new systems is hard and takes much longer than anybody cares to admit. Second, the real benefits can only come when radically redesigning the way a service runs, and that takes even longer – particularly as you’ll likely need several stabs at it. Thirdly, those much trumpeted savings? Don’t forget where they are coming from, which is mostly what the organisation spends on people. That means restructures, which will mean more time, and more pain.
This isn’t a reason not to do this stuff – of course not! But sometimes it’s easy to get stuck into the mindset that if we just buy this thing, everything will be ok. You might need to buy that thing to ensure everything’s ok, but you’ll also have a do a load of other stuff, which the case studies never seem to mention.
Remember – you can get things like this every Monday by email if you sign up to Digital Digest.
Doing things better is hard because it presupposes you know what you are doing and why you are doing it. You have to understand and be clear on your goals and your vision, and the outcomes you want your projects, programmes and organisation to meet. And you have to have the trust and explicit support of everyone around you.
It’s time to reconsider the SaaS model in a modern context, integrating developments of the last nearly two decades so that enterprise software can reach its full potential. More specifically, we need to consider the impact of IaaS and “cloud-native computing” on enterprise software, and how they’re blurring the lines between SaaS and on-premises applications. As the world around enterprise software shifts and the tools for building it advance, do we really need such stark distinctions about what can run where?
Right now, there is growing interest in the role that learning can play in organisational change, but we are starting from a place where learning is seen as separate to the practice of work, and also something different from more operationally focused knowledge sharing.
The digital commons has become a common problem, clogged by disinformation, stripped of privacy and squeezed by insatiable shareholders. Online propagandists stoke violence, data brokers sway elections, and our most intimate personal information is for sale to the highest bidder. Faced with these difficulties, big tech is increasingly turning to Wikipedia for support.
I’ve been prompted by some discussions on LinkedIn to write briefly here about CRM – or customer relationship management to give it its unabbreviated title. The idea behind CRM is that an organisation can record every interaction it has with its customers, so that anyone picking up a future call can be instantly caught up with what is going on, and analysis of the data can yield clues as to where services are breaking down and need improving (“3,000 calls this morning about missed bins? Maybe we have a problem…” – ok, not that, but you get the idea).
This sounds like an eminently sensible thing to do, only in most cases it turns out that it isn’t in practice. Firstly, over the years, getting CRM systems used beyond the contact centre (whether directly or through integration with back office software) has proved very difficult, so this complete record rarely is actually complete, thus defeating the purpose. Secondly, the supposed goal of a single record for every customer is invariably brought down by data uncleanliness, the habit of creating additional records for the same customer, and a general sprawl of records where customers don’t fit into neat holes (eg issues around services delivered to households, and those to individuals that often result in a mess of customer data).
So CRM for CRM’s sake seems like a non-starter. But in the last few years I have been involved in projects that have involved implementing CRM and CRM-like systems. How can this be justified?
For me it comes down to a fairly simple process. First identify the outcome you are trying to achieve, whether as part of an individual service delivered to customers (or residents, or users, or citizens: pick your favourite) or a corporate wide thing. Then assess what capabilities are needed to make that happen (booking, reporting, case management, assessment, payments, document management etc) and then work out which of those capabilities you already possess in a reusable way, and which you need to buy. Now, if those you need to buy can be delivered in the way you need by implementing a system that calls itself a CRM, then fine, buy and implement the CRM system. But there is no capability called ‘CRM’ and no service outcome called ‘CRM implemented’.
Hence, no CRM for CRM’s sake, but by all means buy a CRM if it delivers the capabilities you need to transform your services.
This is our first Salesforce integration, and it was made possible through the use of an API, developed by Rutland’s own tech team. At our end, all we had to do was write the code to integrate with it, and boom, two-way communication.
Transformation is a world away from simply polishing the way things are currently done (the “lipstick on pigs” approach – the tired web- and form-based service design ethos of the past few decades, stuck Groundhog Day-like inside the broken silos and reference frames of existing organisational services). Improving our public services relies on the ability to step back and rethink and redesign current public policy by focusing relentlessly and selflessly on improved outcomes, with a profoundly beneficial and positive impact on people and their experience of delivering or receiving public services.