There is a beautiful, shiny new building out by Heuston Station. It opened in 2022 to house, amongst other things, Ireland’s new National Train Control Centre. Picture a high-tech air-traffic control room, full of blinking lights and real-time maps, but for the 600 trains that run daily along 2,400km of tracks across the country. The kind of room a train nerd might describe if you asked them to close their eyes and imagine heaven.
At the heart of this operation is a sophisticated computer brain, called the Traffic Management System, automatically setting routes, changing signals and providing real-time updates on every train in motion. It’s so smart that it can even predict problems and solve them before they happen.
Thanks for reading The State! Subscribe for free to receive new posts and support my work.
That’s the dream, anyway. Unfortunately that part of the new building sits empty. The traffic control team are still operating out of their old building in Connolly Station, using a system created in the 1970s, last updated in 2004. The (no doubt very talented and hardworking) team sit in what reminds me of a school computer room from the 90s, with ceiling tiles and fluorescent lights, watching monitors and pushing buttons, managing by some miracle to keep the show on the road.
Their efforts aren’t always successful. In May of this year, for example, all trains were stopped for 30 mins during rush-hour after a major signal fault. Their ancient system is teetering on the edge. They are currently down to two spare CPUs, more of which aren’t being made. So in 2014, the board of Irish Rail approved a €500k project to update the system.
This summer, 12 years later, details started to emerge about the now €50m project going (if you’ll excuse the unavoidable pun) completely off the rails.
It took half a decade(!) to get the new software ready, and when it was completed it failed Irish Rail’s testing. It failed so badly that they have decided to scrap the whole thing and start over. Ouch.
I think it’s fair to describe this, from a project management perspective, as a failure.
As journalists and the Public Accounts Committee raked through the ashes to understand what went wrong, many familiar culprits have been suggested; There was no in-house technical expertise in Irish Rail, an outside agency was hired with unclear scope and lines of reporting, and as it all started falling apart, Irish Rail needed external consultants to tell them how to think about handling it.
These are all very legitimate areas for attention and improvement, but there is one very significant factor which I haven’t seen discussed in media or online, which explains not only why this project failed, but how Irish Rail and all other public bodies can stop this mode of failure from happening again.
The Problem with Projects
The underlying problem here is that this technical system was being managed through a series of projects, rather than as one ongoing concern.
This problem arises in all organisations, not just in the public sector, when tech funding is doled out as parcels of capital investment, rather than as ongoing operational costs.
I learned this the hard way many moons ago, in my first ever “real” job as a junior product manager in Vodafone.
The first product I managed was called IOU, which let you get a €2 overdraft if you ran out of credit. It had launched 6 months prior to me starting the job, but usage was plateauing. My task was to make it start increasing again.
What I found challenging was that I needed budget to get anything done, but I could only request budget for work in the shape of a project. I could request budget to run a 6 week marketing campaign, to tell more people about IOU. I could request budget for a technical project, which would take 6-12 months, to add new features or change the way it worked.
Everything needed a proposal with a budget request, a start date and an end date.
I didn’t have an avenue to do what I really needed to do, which was to have regular conversations with the tech team to understand how the product was performing, make small changes, see what impact they have, then iterate. Without that feedback loop, how was I to know what needed to get done?
To make matters worse, the tech team were all external contractors, so I couldn’t even engage them in meetings to learn how the system was failing, because I didn’t have a project code against which they could track and bill their hours. Uggghhhh.
Government Tech Failures Are Almost Always Project-Shaped
In the 20 years since my time at Vodafone, I have seen this exact failure state at many government bodies and large private organisations, like banks, airlines and utilities.
Organisations really struggle when they are not institutionally set up for technical product management - in their job titles, org charts and most importantly budgeting.
Jennifer Pahlka writes wonderfully on the difference between Projects and Products in government, so I’m going to quote her extensively here as she illustrates how projects like the Irish Rail TMS upgrade tend to fail:
Government typically follows a “project” model. The following graph shows the number of staff who work on an IT project at its outset, as requirements are being developed, a request for proposal written, bids from contractors sourced and evaluated, and a winner chosen. The contractor, once hired, brings a team to develop the software based on the RFP, and the staffing levels (counting both internal and contracting staff) shoot up. There is a development period, followed by a short period of “user acceptance testing,” and then the project falls into “operations and maintenance.”
Contrast this with a typical “product” model, in which, instead of a requirements gathering phase up front, a small team, often but not always internal to government, conducts what are called discovery sprints to better understand the problems the software is supposed to address. If some parts of the proposed solution are riskier than others (for instance, it’s not clear whether a data integration will work well), they find ways to test those problems first, before an entire software solution has been built. They may develop prototypes to help question their assumptions, and they engage with users from the beginning. Product teams almost always leverage contractors, but the contractors are there to complement a core internal team which holds the product vision and provides clear direction to vendors. Staff is added slowly over time as the team learns what they need, but doesn’t dramatically ramp down once a first or even second version is shipped.
At this timescale, there seems to be an obvious reason to prefer the project model: the minimal ongoing expense. [….] What happens next on the project line is one or more of the following scenarios: the software doesn’t work well for its users, and funds are sought to fix its defects; it quickly becomes outdated, either by changes in the technical environment, the policy environment, or other external factors, and funds are sought for modernization; or new needs have emerged that the existing software doesn’t address…and funds are sought to meet those needs. Thus, the actual project model line looks more like this in the medium term:
And then in the longer term, as modernizations fail, needs escalate, and even more money is allocated, like this:
I think this is an entirely accurate description of where Irish Rail are currently stuck, likely between a failed first modernisation and a second.
The best path to escape here is to switch to product based funding and management. One person within Irish Rail needs to be given the title of “Product Manager - Rail Traffic Management”. Her first direct report will be the poor soul who is currently keeping the entire show on the road - likely some guy who knows how everything works because he has been there for 40 years and hasn’t been allowed to see sunlight in a decade. She should be given a budget of, say, €2m/yr (way less than the €50m spent over the last decade) with reasonable discretion on how to spend it. With both budget and responsibility, she can start allocating resources to fixing this piece by piece.
Maybe she does even go back to an external agency to build foundational parts of a new system, but at least now that agency will have a key point of contact, someone who can set clear expectations, scope requirements well and take ownership and accountability of it’s completion. More preferably she would engage with them not on a project basis, but as contracted FTEs on her team.
Getting Back on Track
I have no doubt that Vodafone runs differently now. It was transitioning away from the project model by the time I was leaving. But Projects also mostly made sense for the company at the time. We only had 4 big products - phone calls, text messages, picture messages and data - so all the efforts of a product manager were project shaped; a new price plan, a new text bundle, a marketing campaign.
My little product fell through the gaps because, unlike the others, it was a technical product.
Equally, I’m sure that the project based approach makes sense in lots of areas of the public sector. It is certainly the easiest way to organise your work when it is downstream of an annual budgeting process at government level. The political system is geared to fund projects, so it takes skilled management and tenacious fighting to try to carve out ongoing resources and multi-annual funding.
Technical systems, however, need to be managed as products, not projects.
“Every government agency, everywhere is working on a “new system”; It will solve *all* of their data problems and will be ready to use in 18-24 months”
Irish Rail, like every other government agency in the world, risks living in a perpetual cycle of project bloat and failure, until they start re-organising internally to manage their tech platforms as products, not projects, and until people further up the chain start funding them accordingly.
Thanks for reading The State! Subscribe for free to receive new posts every week.
