Buying new software won’t save you money

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.

Photo by Taduuda on Unsplash

Do you need to buy a CRM?

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!


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.

Photo by Štefan Štefančík on Unsplash,

Two pieces on low code

The low code debate seems to have really kicked off.

Matt Skinner off of FutureGov blogs a critical piece:

The low code platforms we’ve tried place a big emphasis on making the lives of developers simpler (or redundant). Unfortunately, we notice this is at the expense of user experience. Low code makes it harder to take a user-centred, design-led approach.

When creating, you have to follow the platforms’ chosen UI components and design out of a prescribed box. Once completed, you can then tweak to meet your users needs. As the platform uses its own functionality, you are also restricted by what’s been created so far. It’s a world of functionality first and user needs later, which never ever ends well.

Paul Brewer from Adur & Worthing blogged himself in response:

After careful consideration, we went for what I think was a good, pragmatic compromise. Our chosen open standards platform (this is a must), providing a “low code” development environment, has a fixed enterprise licence fee that means we can not only build unlimited apps for ourselves, but can build apps for any public sector body operating in our geography at no additional cost. Development time is much faster than it would otherwise be, and the skills required are significant, but lower than other development environments.

Worth reading both in full to help you decide if low code fits into your strategy.

There are no digital silver bullets

In a fairly complex world, everyone yearns for a simple solution. The one thing they should do to make things better. The single solution to all their problems. Digital transformation is no different, and many of the marketers working in this space know it – that’s why they usually claim that their ‘platforms’ will deliver everything an organisation needs to change itself for the digital age.

Sometime people read a single solution into things when it isn’t there. A good example would be my post the other day talking about the uses of low code platforms. Several people got in touch questioning my assertion that it was the answer to all of local government’s problems. I replied pointing out that it wasn’t my assertion, and low code won’t fix everything. It might help for quite a few things though.

Overall, I am always very nervous of transformation programmes that have a single view of the operating model of an organisation, particularly when we are talking local government, which delivers such a bewildering array of services that it would surely be impossible to have just one way of changing and organising them all. Are there really that many similarities between running a theatre and processing benefits? Or picking up waste and community development?

Instead, part of laying the foundations of an approach to digital transformation should be developing an openness to trying new tools, techniques and technology, and an awareness of all the possibilities that are out there.

On the tools and techniques side, this means having a really good knowledge of ways of doing human centred design, innovation and delivery. Check out IDEO’s resources on this, along with the 100% Open toolkit, and of course the GDS service manual.

For technology, really consider the capabilities needed to deliver the outcome your users and your organisation want to achieve. See if you can match those to what you already have, but don’t shoe-horn them in. Think about the maturity of the capability you need: if it is really cutting edge, you may need to build it yourself (whether in-house or outsourced); for everything else there ought to be something on the market to suit. Whatever you do, don’t get bogged down trying to build silver bullets – a universal case management system for everything, or some kind of middleware utopia that makes everything talk to everything else. You’ll end up tying yourself into knots and running a huge IT programme, which is nobody’s idea of fun.

As I said, by all means re-use capabilities wherever you can. It might be that you do end up using one case management system for everything, because it works. Great! But find your way there by iteratively re-designing your way through services, matching capabilities to outcomes, and not through the implementation of a grand technology project.

So is there an operating model that can be applied to everything an organisation does? Probably not.

Is there a change process that can be applied to every service you deliver? Probably not.

Is there a technology platform that will enable you to replace every other system currently in use? Probably not.

Should you try things out, find some alignment between the outcome you want to achieve and the stuff you use to get there? Probably, yes.

Photo by Jens Lelie on Unsplash

How low (code) can you go?

There’s an increasing amount of talk in digital circles about low code. These are systems for building systems: ways of using simple drag and drop interfaces to build out workflows and databases to deliver business processes. Some low code platforms of note include Matssoft, Mendix and Outsystems amongst many. There are also a number of more traditional forms and workflow packages that market themselves as low code – whether they are or not I’m never entirely sure. Perhaps it doesn’t matter.

At Adur & Worthing, Paul introduced Matssoft. The team there has built a range of apps, including ones handling HR processes, waste services, asset management, FOI and complaints handling, and a range of housing services. There’s details on Paul’s blog, and it is a great example of how a corporate commitment to a new way of building software to deliver services can see real improvements and innovation.

One of the marketing messages many low code vendors like to trot out is that around the idea of being able to do away with developers. Having managed a rollout of low code and attempted various projects myself, I am not convinced of that. I’m reasonably tech savvy, and yet have never personally been able to build a functioning bit of software with a low  code platform. My brain just isn’t wired in the right way. Largely this is because, at a fundamental level, most low code is a front end to a database, and designing databases well is a skill, if not an art.

So I don’t think low code is a way for organisations to dispense with developers. Instead, it can change what developers do, and speed up the process of getting ideas made into working software. They are especially useful, I think, at the beginning of a transformation programme, perhaps when one is looking for some pilot projects to prototype approaches and methods. Buying handful of licences for a low code platform and churning out a few apps saves a lot of bother compared to procuring some heavy IT designed for some future model that may or may not ever happen.

Low code, in my view, is best suited as a way of quickly building out bespoke workflows that don’t fit easily into an existing line of business system or platform.

For example, most organisations are chock full of spreadsheets and databases (whether made in Access, or a Visual Basic/SQL server concoction) doing small but vital pieces of work. These are often stored in network drives and digital or IT teams may not even be aware of their existence. They also don’t have the advantage of being cloud native apps, with reduced capability when it comes to mobility, usability on a range of devices and can have a high maintenance overhead.

So overall I am a supporter of low code and encourage organisations to explore how it can help consolidate that morass of unknown Excel and Access based workflows into a more modern, usable and less risky platform. But don’t expect necessarily to be replacing big line of business systems overnight, nor saving money by reducing your developer headcount.

Photo by Helloquence on Unsplash

Implementing digital civic infrastructure

troy-jarrell-57863-unsplash

I’ve banged on about this before, but then that’s because I think it is pretty important. To quickly recap – digital civic infrastructure is an idea I have been thinking about for some time as a means through which local councils (am thinking mostly about those at the district or borough tier, although it may be relevant for others too) can redesign their operating model and help to rewire local public service delivery to better meet the needs of local people, communities and businesses – and indeed to prevent those needs arising in the first place.

The starting point for me was when thinking about technology provision in local councils and how that might best work. Heavily influenced by platform based thinking as described by Mark Foden in this video and also in various bits of writing by Mark Thompson (and of course the original idea by Tim O’Reilly). The idea of reducing the number of siloed back office systems to being able to reuse common components such as reporting, booking, assessment, calculation, payments, case management etc answers many of the problems of delivering IT to multiple different services areas.

Much of this platform based thinking has gone in the direction of platforms for government, rather than government as a platform, in that components could be shared between bits of government delivering the same or very similar services. Why should a council delivering bins in one area need to buy a different system to the one next door, or indeed on the other side of the country? This is the approach taken by the GDS government as a platform team, which is developing shared components such as Pay, Notify and Platform as a Service.

While this is a very attractive proposition, with potentially eye watering sums of savings possible, it misses the mark for me in that it takes the focus away from meeting local people’s needs and instead looks to making things easier and more efficient for the organisations. In other words, the effort of sharing and collaborating on these components will likely result in them being less able to meet a local person’s need due to the increased levels of genericism needed.

Instead, and this is where we get to digital civic infrastructure, the real area of sharing and collaboration to focus on is within the local system itself. Instead of opening up platforms and components to other councils, these shared capabilities should be usable by all the actors within a local system. So, the borough council, the county, the local DWP office, the NHS and CCG, housing associations, community and voluntary groups, and even private sector providers of public services.

All of these organisations are working with the same users that the council is. Equally, they are involved in activities that use similar technology components – the bookings, reportings, case managings etc. Indeed, quite a lot of these organisations also lack strong technology capability and either don’t use digital tools to deliver their services at all, or use poor options that are badly supported. The community and voluntary sector would probably be a good example of this (to be clear, there is a lot of great digital practice in that sector, but many of the players are too small and poorly funded to have fit for purpose technology).

By having a shared platform in a local area, these components and capabilities become available to all the organisations that are working towards a common aim – meeting the social needs of the local populace. What it also enables is a fascinating data set of demand within a place. As services are requested and delivered by a range of organisations on a shared platform, the information on what demand exists and how it is currently being met will become available and usable to plot where the right interventions need to happen, how and by whom.

The council can play a role as the steward of this platform, and the data it produces. They are perfectly placed to do so because of the USP of councils: local democracy. Much of the angst about digital age organisations such as AirBnB, Uber, Amazon, Google, Facebook and the like is their seeming omnipotence and lack of accountability. Councils can fill the gap here by ensuring that stewardship of the shared local digital civic infrastructure and its data is governed by directly elected community representatives, accountable and answerable to the people who elect them.

To do this, the council must start to build the platform separate from it’s own existing IT estate. This will require a bi-modal approach to technology, which I know that some are not keen on. However from my experience of trying to manage legacy systems at the same time as building the new world, it’s incredibly hard to keep the two in sync. Exactly how to go about this is down to the council to decide – it could simply use existing off the shelf cloud components, stitched together with some kind of Mulesoft style middleware, or go down the low code route with Matssoft, Outsystems or similar, or perhaps the Salesforce ecosystem could be used. Alternatively, for a council with a strong development team, it could be written from the ground up, or built on top of a PaaS such as Cloud Foundry. It doesn’t really matter, so long as it is easy for other organisations to consume these components to build out their own services without overburdening the host council with support requirements. This is not about a council becoming a software development shop.

However, just because the new platform is built separately from existing tech within the organisation doesn’t mean that it can’t be used to build council-only services. Indeed, this is where the idea of becoming your own best customer comes in. With the key components of the shared platform in place, the council can start consuming them to design and deliver its own services on – just as any other organisation can do. In this way, the platform can be stress tested and ensured that it is fit for purpose, because if the council can run its services on it, then it ought to work for others too. Just as Amazon knew their web services worked, because Amazon.com ran on it.

The shared platform doesn’t need to be limited to technology in this way though, and indeed it probably shouldn’t be. There is a potentially fascinating role for customer contact centres to play here as another potentially shared capability. As digitisation of council services frees up customer service time, that time could be used offering a services to other actors within the system. The advantage is yet more data around people’s needs flowing into the system, building up a better, more accurate picture of what is going on locally.

Allied to this could develop a service design capability, reusing and repurposing user research, patterns and design work across different services and providers and providing the opportunity for the genuine rewiring of local public services delivery thanks to the shared technology stack (no more trying to integrate the NHS with local gov) and commitment to sharing and collaboration.

This might sound like a pipe dream but it is perfectly possible to start small and iterate in this space. The project I kicked off at Adur & Worthing called Going Local, which saw the local CCG and the councils collaborate on a new, shared cloud based platform for social prescribing, which has been developed brilliantly since my departure by the team under Paul Brewer, shows the benefit of this way of operating – and that it is possible. Just find somewhere to start, and have a go.

The challenge perhaps is in scaling it up and where this will come from is having a council willing to seriously back this as a future operating model, and a good, strong network of local collaborators willing to put local people’s needs ahead of organisational silos and patches of perceived jurisdiction.

The final point should be, of course, that it doesn’t have to be the council that does this. Any of the local actors could take the lead. What might be very interesting would be if a social enterprise type organisation takes the lead and starts to develop the platform. My reason for focusing in on local government as being the vehicle for this approach is partly because of my background  and professional interest, but also because of the democratic accountability angle, which would be important for folk having trust in the platform. But theoretically, anybody could take the lead on this.

To quickly summarise what has been a bit of a wordy post, the steps to implement digital civic infrastructure are:

  • build the coalition of local actors to be involved and identify some quick early collaborations to prove the model
  • start putting together the new platform of shareable components, including technology and an approach to service redesign, separate from existing technology stacks
  • establish a governance model with local democracy at its heart to ensure the platform continues to meet the needs of local people.

Simples.

Photo by Troy Jarrell on Unsplash

Six themes for a good local government digital strategy

I recently went through the rather painful process of applying for a senior digital transformation role in local government and not getting it. I might write in more detail at some point about it all, but right now I am far too bitter about the whole experience.

As part of the process I needed to talk about what I think the key themes are for councils when thinking about the impact of digital on what they do and how they do it, and I thought I would share them here – just in case some people find it more interesting than the original intended audience did.

1. Digital service design

Meeting the heightened expectations of residents, communities and businesses means radically rethinking how services are delivered. This requires new approaches to change that meet the specific requirements of each service’s users, and in the long term working to prevent those needs from emerging in the first place.

2. Digital workplace

In order to deliver the change that is needed, people need to have the best tools possible available to them, whether hardware or software. This means looking at the whole suite of technology, from productivity tools to line of business applications and the devices they run on.  People also need to feel confident in using them, along with developing a customer-focused, commercial, flexible culture.

3. Digital inclusion

It’s vital that the services that many people rely on remain accessible to all of them. For some, using the internet will never meet their needs and so other forms of access will be needed. For others, there is much that councils can do to help them get the most from it.

4. Digital intelligence 

Local councils should have the best understanding of the people, communities and businesses in their area. Often, however, this understanding is limited by the inability to make the best use of the data held in siloed systems that do not share information easily or in usable formats. This needs to change, along with keeping up with obligations around data protection and information security.

5. Digital economy

To protect and grow the local economy in the future, councils must do all they can to ensure local businesses can thrive in the digital age, and attract new enterprises to base themselves locally. This means ensuring businesses have access to high speed broadband; the equipment, systems and skills to make use of it; and easy, simple access to the council services they need.

6. Digital civic infrastructure

True digital transformation in local public services involves not just putting existing services online, but radically rewiring the local system to take advantage of shared, common digital components. The Council should take a lead in stewarding this work, collaborating with all organisations that meet local people’s needs, whether central government, the health sector or community and voluntary groups on a digital platform for genuinely joined up service delivery.

Photo by Johannes Plenio on Unsplash

Be your own best customer to advance your transformation

One thing that has been taking up quite a bit of my attention lately is how, in the real world, an organisation can do the kind or big picture, strategic transformation that’s almost certainly needed whilst making progress on what might be termed everyday digitisation – the sort of thing that makes peoples lives easier but doesn’t dramatically change the core operating model of the organisation.

I’ve imperfectly defined three ways to attack digitisation before:

  • Access – taking a paper or telephone based process and whacking it online with an e-form (quick to do, few benefits except a bit of convenience for web savvy users)
  • Efficiency – taking that process and digitising it end to end, involving the replacement or integration with back office systems, removing unnecessary admin touch points an so on (takes longer, more difficult, but yields better results)
  • Transformation – taking an entire service and rethinking it from the ground up, knowing what we know about networks and connectivity (really hard, but could ensure the relevance of that service for the next 20 years).

The problem is that transformation is where the real action is, but it is hard, so hard in fact that it’s difficult in my experience to get people to even talk about it. In the meantime, you’ve got folk shouting at you to increase self service or decrease unnecessary demand.

In a recent conversation with Catherine Howe I reminded myself about Ben Thompson’s great analysis of the Amazon purchase of the Whole Foods supermarket chain (Amazon is, I think, by far the most interesting company of our times). In it he describes the concept of Amazon being its own best customer. When building the AWS service for cloud based computing infrastructure, they had a huge customer ready and waiting to use it (and more importantly, test the hell out of it): the Amazon.com e-commerce site. Likewise, having its own in house supermarket would be a great way to build and test Amazon’s emerging logistics business.

This I think gives a hint towards the way an organisation (I’m thinking of my usual local government context, to be clear, although it could work in other sectors too) could start laying the foundations for genuine transformation whilst doing some of the quick wins stuff in efficiency, and maybe a bit of access if they really have to.

By having an idea of what the future big picture might look like, it’s possible to start building things in the here and now in such a way that it delivers the short term gain whilst creating the capabilities, the building blocks, for making the future happen too.

The danger is to drive yourself into a technical cul-de-sac delivering on the immediate requirements which leaves you hamstrung in your ability to execute on the much greater strategic win of genuine transformation when that opportunity arises.

As always the difficulty with this conversation is figuring out what that future looks like. It’s easy to write posts saying “digital isn’t about tech! It’s about changing your fundamental operating model!” but such posts rarely tell you what one of those operating models might be. I don’t necessarily have an answer to that myself (the consultant in me screams “it depends!” at this point) but I’ll post a few thoughts another time.

What I would say though is that the ‘be your own customer’ part of this does point to an organisation in the future being the provider, or perhaps steward, of technical capabilities that can be shared and re-used across a wider (perhaps local) system. However other assets could also play a part in this and it doesn’t need to be a technology focused discussion.

Photo credit: Jomjakkapat Parrueng on Unsplash