In my personal experience, there are certain institutional barriers to productive and successful delivery of major projects in government. Indeed it may be that the mechanisms that are put in place to reduce the risk of delivery failure and wasted money may in many cases be the very things that are significantly increasing the risk of that failure.
At the heart of many of the challenges facing major government IT programmes is the fundamental disconnect between the bottom-up Agile approaches encouraged by the Government Digital Service (GDS) and followed by most IT programmes and the top-down nature of the project approval, funding and oversight mechanisms.
This approach frequently demands an agreed up-front design, a fully defined set of outputs and benefits at the start of the project and a business case setting out in great detail the budget required for delivery. These are all fundamentally based on Waterfall-type project planning.
As an ex-Treasury official myself I fully understand the need to ration spending and to allocate it to where it is most useful, however the way this is currently configured does not align with Agile project delivery.
At best these are simply slightly spurious formalities that projects must go through before they can start the Agile approach to delivery. At worst they undermine the delivery approach needed and distract the project team from the iterative, fast-paced and flexible approach that is needed for successful delivery. This needs to change in the current government’s vision to emulate a start up’s test and learn mantra.
Disconnected by IT and business staff
But this approach will also falter if another tendency of government IT is allowed to prevail. Many departments focus on delivering all, or certainly most, projects almost exclusively in-house using bespoke code to build the necessary solutions. This is often done because of the complexity, or at least the perceived complexity, of government processes and how much they differ from those in private sector organisations.
However, this focus on building systems using bespoke code is time-consuming, expensive and hard to manage, and still all too often fails to deliver. It also often ends up with a disconnect between the frequently huge IT team and the business staff who are ultimately going to own and use the system, and with massive amounts of design documentation being passed back and forth between them.
Small and agile projects are key
To deliver Keir Starmer’s vision of re-wiring Whitehall, there does need to be an approach that looks to how government can apply low-code software development intelligently and in the right areas. This can revolutionise the way the government designs and builds IT by significantly reducing the amount of custom code creation needed and by transforming the way business people are involved in the process.
The new government is right in how it’s choosing small discrete projects. A more iterative, less ‘big bang’ approach to government transformation should be adopted. Starting small and picking one or two key processes in any given area, to begin with, and adopting an approach such as Agile low-code development that reduces reliance on scarce and expensive technical skills while compelling business and IT teams to work together in an integrated way.
This lets you get to the stage where the outcomes can be assessed much sooner, providing the basis on which to move onto the next mini-project. Ulitimately you end up ticking off a lot of stages and achieve sweeping but sustainable transformation but with the problems of more traditional approaches minimised.
Alex Case, is a former senior civil servant at Downing Street and a now government industry principal at Pegasystems, which has developed a low-code platform for building applications
