Digitally transforming Government is hard. Public money is hard to access and hard to spend. Public opinion is hard to gauge and even harder to satisfy. Government's infrastructure, policies and process change slowly but its leadership changes fast and often. Success is hard to define and so many people and organisations have a stake in what you're doing that managing stakeholders can be a never-ending task. All of this and more can make it feel like an impossible job.
Frustrated rage at individual projects, staff or suppliers is common and misplaced. Public sector organisations are complex systems that require an intelligent and subtle approach to change. Too often, brute force is applied with consistently poor results. The aim of this article is to outline a way of thinking that is adapted to these complex systems. It is not a detailed and comprehensive "to-do" list. It deliberately does not look in any detail at big issues like supplier management, programme management, user research, software development, communications or any number of other things that digital transformation leaders consider on a daily basis. Instead, it aims to guide readers away from common and often repeated mistakes by offering some understanding for how those mistakes happen and sets out a series of high-level preferences that, if at least considered, make success a little more likely.
Many of the observations below are applicable to digital transformations in the private sector and many are applicable to transformation programmes more broadly. However, I have written it with government digital transformations in mind and structured my thinking in similar terms to the "Agile Manifesto". I like this structure as it does not discount the alternative to the preference as worthless. Instead it acknowledges that sometimes constraints are constraints and you have what you have. For that reason, the first preference for pragmatism over rules (including the ones I'm about to set out) is critical to keep in mind.
1. Value pragmatism over rules Government loves rules. It gives them loads of different names; 'processes', 'governance', 'approvals', 'guidance', 'methodologies' etc. but they are all rules and the public sector simply wouldn't function without them.
My view is that rules in all their forms are central to the effective running of government. You will see below that I don't shy away from the need for documentation, plans and reports. I embrace these things far more than many others who are convinced, erroneously, that developing software in an agile manner means that programmes, procurements, and staff should all be managed outside the "rules". This belief is wrong and is directly leading to widespread waste of public money. I make every effort to distance myself from this view.
However, rules cannot deliver change. Indeed, they are usually established in order to avoid it. Therefore, those of us tasked with delivering change must take a pragmatic view of the rules of the organisation in which we find ourselves working. In particular, the temptation to follow a path defined for us by rules and proven not to work should be avoided at all costs.
If, as a leader within a transformation, you do not feel that you are entrusted with this degree of flexibility, if you feel that the constraints are simply too tight and too strong, then you must think twice before taking on the task. However, if you simply do not understand the existing environment with regard to rules, you will never be able to work out what you want to adapt or how to do so. Turning-up and saying something like, "I don't do rules, I do success" is a much-tried, much-failed approach that should be avoided before the system makes a fool of you.
So understand your constraints but don't let them deny you success. Government feels impenetrably bureaucratic but most of the system is there for legitimate reasons. Navigate it expertly, have empathy with those you feel are blocking you, break only the rules that are barring you from success, trust yourself and your opinion, adapt to the situation you're presented with and you'll have a far greater chance of success than if you blindly bounce between constraints set out for you.
2. Value delivering change from within the business over a separate programme
Programmes get created because transformation leaders think that their operational staff don't do change. This couldn't be more wrong. On a daily basis operational public sector staff across government are delivering extraordinary change.
While the semantics of what is a "transformation programme" over "business change" or "performance improvement" can be argued over ad-infinitum, I would simply say that, no matter what you call it, most of the benefits of a digital transformation will eventually have to be realised by operational staff - so they need to be at the heart of the programme.
Too many digital transformations across government follow this path to failure:
Realise the potential of digital to rationalise operational processes and headcount
Convince themselves that operational staff would be, "turkeys voting for Christmas" so should be kept well out of the way
Stand-up a shiny new transformation programme far from the operations and with little interaction within them
Create a capability to transform operations digitally within that programme
Present this new capability to the (now alienated) operational staff who quickly point out the avoidable gaps and errors
Disregard their views and press ahead with an attempt to implement regardless
Face angry and effective opposition from staff, unions and suppliers
Give-up blaming unions/outsourcing/politics or any number of alternative excuses.
Government gives everyone lots of excuses to use, but the truth is that a failure is a failure. If the ultimate aim of the digital transformation is an old-school headcount reduction or estates rationalisation then the operational staff in charge of those things must sit within the programme and the programme must understand, in minute detail, how those operations run today and how they will run in the future.
The business-end of the public sector can be tough, gritty and frightening and digital transformation people tend to keep their distance from those kinds of things. The truth is though, if you want to digitise someone out of a job, you should be willing to look them in the eye and explain to them why the future state will be better for the people they serve. If there's one thing that 20-years in the public sector has taught me, it's that public servants care about delivering a great service more than they care about anything else. Honesty, clarity and the ability to frame the change in terms of service improvement will generate the support you need to deliver that change.
3. Value continuity of programme staff over churn
As a programme evolves, the team should adapt. However, it requires consistency and commitment to deliver change, and transformation leaders should avoid their programmes becoming hubs of transitional talent.
The Civil Service rolls staff in and out of jobs on a regular basis. The impact of this is a much repeated lament. Less often mentioned is the impact of hiring contractors on cut-price day rates and wondering why they leave as soon as a better offer comes along, or changing the terms on which they are engaged and wondering why they disappear, or firing their consulting partners halfway through the programme to bring in a new point-of-view, or any number of other self-inflicted ways in which programmes in government encourage churn and devalue consistency.
Delivering a transformation requires a clear and consistent vision that is doggedly delivered. It is almost impossible for a programme to deliver change to its organisation if the programme itself is constantly changing.
Operational teams usually have far less churn which is another reason to embrace them within a change programme. Beyond that, see above for the preference for pragmatism over rules. If suppliers are vital to delivery, don't sack them and hire their competitors over a marginal saving or blind adherence to a procurement process. If an individual is the right person for the job in hand, pay a fair rate and keep them until the work is complete. If a civil servant is critical to the programme, protect them.
4. Value an accurate business case over an ambitious business case No one likes writing a business case and everyone accepts that they are wild guesses at the future and so largely fictional. However, that is not an excuse to deploy them cynically to obtain the largest possible budget before disregarding them.
It is my view that leaders of digital transformations should be held to their business cases. Too often in government business cases gather dust while the world changes around them and £100m and two programme directors later, people wonder why the benefits were never realised.
Business cases can be weighty documents. Public money is valuable so, while we can all try to improve it, this rigorous process should not be begrudged. However, it is my view that within every business case there should be a single page that summarises all the expected benefits that have driven the initiation of the programme.
It is the realisation of these benefits that should drive everything within the programme from that moment on. With that in mind, it is critical to get them right. The preferences below will offer some insight as to how to do that and how to avoid the pitfalls of many ongoing government digital transformation programmes.
5. Value detailed benefits analysis over light-touch benefits analysis Digital transformations exist only to deliver benefits and yet many are initiated and run for many years without those benefits being monitored or even defined.
No one starts a programme without considering the eventual benefits, so it is worth trying to understand how it is possible that major programmes can spend £100s of millions without clearly defined benefits to enable an accurate judgement of success or failure.
The first (and in my opinion most common) way this comes about is through changes in the way benefits are articulated over time and across documentation without appropriate governance or control. The cumulative impact of having too many versions of the benefits case is a loss of clear intent and an inability to closely monitor or definitively measure progress.
The second way it happens is through a failure to take benefits analysis beyond an outline stage. I regularly hear senior transformation staff say things like, "Digitising process X will help us reduce our headcount by 30% and our estates bill by 50%". As an outline statement of intent, that's fine. However, if those aspirational outline benefits are not broken down in detail with each component being allocated to an activity within the programme it is impossible to understand what progress is being made and which particular activities within the programme are delivering that progress. As an aside, I have more than once come across major programmes that have spent £100s of millions to almost no effect only to be declared successful when the benefits have been delivered by an external force like a change in consumer technology or a departmental budget cut.
The third way benefits get neglected or confused is when human nature gets in the way. People often prioritise illogically which can mean that pet projects are pushed to the top of the priority list despite little connection to the stated benefits being targeted by the programme. Not only does this have the effect of directing resources incorrectly, it also usually has the effect of blurring benefits as these skewed priorities are retrospectively justified.
So how should it be done? Like many things in life, the simpler the better. The business case should be the definitive source for clear and quantifiable benefits so use it to source the aims of the programme. If they're not clear enough for the purpose, re-write and re-circulate the business case.
Next, understand how each benefit is constructed. Some benefits are delivered in a linear fashion and can be measured in that way. For example, success in the programme may show a month-by-month reduction in temporary labour costs. These should be monitored in real-time by the programme and shape management decisions as discussed below.
However, most benefits have critical mass issues. If the benefit is closing down an office, it is hard to track progress towards it through a benefits lens. It doesn't become 20% then 60% then 100% closed. One day, after an awful lot of work, it is just closed. For benefits like this, progress towards the critical mass must be analysed and tracked. For example, if the office closure is going to be made possible through a digital take-up that reduces call volumes and face-to-face consultations then these three metrics become the tracked benefit. What's more, the point of critical mass is tracked with them. That way, if the critical mass is reached and the office isn't closed, you know where to look to unblock the problem.
Much of this may seem simple but it is very frustrating to see how many public sector programmes lose track of their benefits. To be clear once again, this is the reality of working in the public sector. Complex stakeholder environments, governance, reporting lines and success criteria mean that the risk of losing track of benefits is very high. It can't simply be brushed-off, it requires thought, patience and commitment. Once benefits are defined and processes are in place to monitor them, day-to-day decision making across the programme becomes much easier. The next preference will illustrate how.
6. Value adaptive budgets and plans over fixed budgets and plans I have no objection to a good old-fashioned MSP plan. Indeed, I take some comfort from knowing that a programme has made some attempt to list its jobs to do, put time frames against each of them and connected dependencies. Equally, I like to see detailed budgeting. However, if a project delivers exactly to its plan and budget yet still fails to deliver its benefits, it's just as much a failure as the project that imploded. Delivering plans is not the point of transformation programmes, delivering benefits is the point of transformation programmes.
Therefore, with benefits defined and monitored as described above, the allocation of work, plans and budgets should all be adapted in-line with the feedback from this real-time monitoring.
If take-up of the recently released digital service is poor, there is no point in simply moving-on to developing the next service in accordance with the plan. It's the take-up that is important, not the release. Effort has to be re-directed and lessons have to be learned. Equally, if digital take-up has been good, but calls have gone up rather than down - that too requires real-time adaptation of planned activity. It may even be that every metric has been a success and so the headcount reduction programme is ahead of schedule. If this means that redundancy costs are set to blow this year's budget. Should you slow down? Maybe, but your CFO is going to thank you for asking the question if a bit of pain this financial year makes the next far easier.
The ability to notice these unexpected trends is, in my view the critical skill of today's digital transformation leaders. It can only be done with quality staff working to a flexible plan based on clear aims that are accurately monitored. It is also another reason to have the business close throughout any digital transformation. Without them on-board, all sorts of unintended consequences can go unnoticed. With them on-board, the programme automatically lifts its eyes up from delivering outputs towards delivering outcomes.
When a programme is capable of adapting its plans and budgets to deliver benefits, priorities also quickly change. A programme previously obsessed with marching towards milestones and mindlessly operating within fixed constraints becomes obsessed instead with delivering benefits. Endless analysis and formalised conjecture give way quickly to experiments and pilots specifically designed to test hypothesis around what will deliver the greatest benefits fastest. It is hard to do and requires a good team delivering clear aims within flexible constraints but the effort is worth it.
7. Value standardised reporting over bespoke reporting This preference is a by-product of the two above, but reporting is such an industry in government that it deserves its own brief focus. It is easy for digital transformation leaders to have all their time taken up bouncing from board to board via the occasional leadership team meeting and steering committees. Each one demanding its own reporting format and each one analysing your progress from a slightly different angle.
The truth is that, if the aim set out in the business case is clear and progress against benefits is being tracked, there is only one angle to look at the programme from. That angle is, "What progress are we making against delivering the benefits we set out to deliver?"
Given this single angle, a single reporting format should suffice. Design it as soon as the analysis of the benefits has been complete, get stakeholders to sign-off on it and (in line with the first preference for pragmatism) politely ignore any requests to report anything else.
8. Value leadership over almost everything else If getting the right approach is hard, executing well is even harder. Digital transformations are often delivered by disparate, diverse and transient "rainbow" teams. It is common to have contractors, consultants, several suppliers and civil servants all working together with separate skills, knowledge and backgrounds. Each will have very different incentives and each will have their own views on the abilities of the others.
This kind of complex team requires extraordinary leadership skill. Hosting mindless myriad meetings and angrily demanding timely reports from your subordinates simply doesn’t cut it. Being seen around the programme, being seen within the business you’re trying to change, caring about your team and being passionate about your mission are all critical attributes for a transformation leader.
Equally critical are old-fashioned concepts like leading by example, loyalty and discipline. A digital transformation can only be successful if its leader is in control, owns the approach, defines and enforces desired ways of working and has a relationship with their team characterised by loyalty and trust.
Your team is like many of the stakeholders in government - if they trust you, if they understand how their work will improve a public service and if they can see progress being made, then they'll make your digital transformation the success it deserves to be.
Programmes and projects often fail across government because the challenge is under-estimated. Being honest and clear about the task ahead is the first job of a transformation leader. Framing that challenge in terms of public service improvement and engaging business leaders is the next job.
Isolated change programmes almost invariably fail, so the business must be at the heart of any technology-led change from the start. The business case should be an honest document with clear and measurable aims. These aims should be understood in detail and carefully monitored.
The programme should be structured to flex its plans and constraints in accordance with the progress it makes in delivering those aims. The programme must be led by someone who understands the environment, the business and their staff (including all their different incentives) and that leader must also have that intangible “x-factor” required to inspire and challenge those around them.
The various constraints of the public sector mean that this utopian version of a programme is impossible to find. However, as a check list, it should help to guide transformation leaders when they try to understand if they’re set-up for success.
I wish anyone working on a digital transformation within government all the very best of luck. It is a tough job but the potential to transform lives makes it exciting and rewarding. I’m always happy to offer advice to anyone interested in my thoughts, please feel free to get in touch.