700 words (3 minutes reading time) by Tim Whistler
‘The IT Wager’ by Tim Whistler (with the assistance of ChatGPT)
Carole Parkinson has put together a compelling and well researched post on how Councils can avoid gambling on IT investments – or at least how the risks in the bet can be understood.
I asked some experienced IT managers what they thought and they said the post was useful but didn’t go far enough.
I asked them why.
Why the IT bet feels safer than a service bet
The first point made was that the post should have explored why CEOs prefer to gamble on an IT bet than a service review and improvement bet. It was suggested that perhaps they didn’t understand how to make the service review and improvement bet. Or it was simply easier to bet on an IT product from a big vendor. It is a way of outsourcing risk for them. They pass on the responsibility for service improvement by their organisation to a Big 4 consultancy and the software vendor.
One suggested that CEOs don’t have a choice because they are caught up in the race to digitise simply because their councils and communities expect them to do it. It is the new service standard. Non one wants to be left behind. Whilst this may be true, I have never seen a business case with a justification of ‘they are doing it, so we should too!’.
Why business cases mislead
The second point was that excessive optimism is just one of the judgement errors CEO’s and councillors make. This could have been explained more. They saw it as accompanied by overestimation of benefits and underestimation of risks. Of course, they are related and Parkinson could have discussed how this occurs in the benefit:cost analysis of the business case. I suppose, in fairness to Carole, she did say to treat the business case as a ‘claim to test, not a plan to implement’. She encouraged Councillors to question the way benefits and risks are quantified.
What vendors actually guarantee
The last point they made was on vendor assurances or guarantees that their software will deliver the expected benefits. I was told attempts to set this up had all failed. A quick search using ChatGPT revealed that software vendors will provide some assurances. For example, the uptime/availability of their software for use by the purchaser. Typically there are numerous exclusions, remedies or damages are limited, and there is seldom compensation for losses. But they do provide it.
Vendors will also warranty that their software will conform with their specification and documentation, and they will rectify any defects. They don’t warranty that the software will achieve what the purchasers specification requires or transform their services. Whilst vendors often claim that their software will improve productivity/efficiency/service experience, their contracts don’t guarantee it.
To get a guarantee of business improvement, a purchaser would have to explicitly turn their expected operational outcomes into contractual obligations with measurement linked to payment – and then get the vendor to agree. This is unlikely to happen with the big software vendors because they would be taking on much more risk. It would also be reflected in their price if they did agree. Expect to pay a lot more.
In the end…
In the end, the uncomfortable truth is simple: vendors will stand behind availability and conformance to documentation, not the operational outcomes your business case is counting on. It is illustrative to think of an outcome guarantee as if it was a bet.
If the benefits in the business case are real and predictable, the vendor should be prepared to place a bet by putting meaningful fees at risk. This would help the council to monetise the risk it would otherwise take because the price of getting the vendor to accept the risk would equal the cost of the risk.
If the vendor won’t place the bet, why should the council?
2200 words (20 minutes reading time) by Carole Parkinson
Podcast option:
Credit: ChatGPT
In a nutshell…
This post explores the risks and pitfalls associated with large-scale IT investments in local government. It argues that councils often rely on technology and automation to fix financial deficits or service inefficiencies without first optimising their underlying processes. Drawing on expert theories, the post suggests that these ambitious projects frequently over-promise and under-deliver by ignoring the complexities of human-technical systems. To avoid failure, Parkinson recommends that leaders adopt a skeptical mindset, demand evidence-based service studies, and implement incremental project stages. Ultimately, Parkinson emphasizes that improving service design from a resident’s perspective is more effective than simply digitising outdated methods.
Introduction
“I voted for the IT project because the business case promised the budget would balance by year four. But no one told us what we’d do if the savings didn’t arrive. In the end, we automated our inefficient services instead of fixing them. It has now cost us more money than we have saved!
We should have demanded a service study to improve services first, limited the project scope, put a ‘kill-switch’ in place, and made sure the CEO had an effective early warning system in place for failure.”
Councillor
The lesson?
Big IT doesn’t fix services; it just automates them. You can make governance improvements to reduce the odds of an expensive disappointment.
Why councils are betting on IT
I have been reading the plans Victorian councils are releasing for the next 10 years. These plans are all a bit different. In essence they cover how a council will serve its community, define the services and projects the council will deliver, and show how the councils strategic direction will be funded.
IT investment is positioned as an enabler of efficient service delivery, better decisions, streamlined operations, and improved customer experience, while also promoting transparency and accessibility. It is justified as necessary to meet online-service expectations, modernise old systems, and sustain previous investments.
In a nutshell, they are relying on IT investment to improve how council work gets done so services are delivered more efficiently and conveniently. More importantly, they are relying on them to balance budgets through efficiency dividends from process automation and use of artificial intelligence.
How that bet goes wrong (in real life, not in the plan)
In these plans, some councils provide detailed action plans for IT investment. They describe how the investment in enterprise IT/digital/artificial intelligence (AI) will pay dividends through increased efficiency and better decision making. Few include quantifiable measures, like hours of customer/staff time saved, time or money saved from improved service performance, or number of blocked cyber threats.
Most make more general statements, such as IT investment improving ‘integration, efficiency, service responsiveness, analytics, and data protection’. They tend to flag things like AI and emerging tech as ‘disruptive’, and say they will need continued ‘exploration, upskilling and adoption’ to capture opportunities and maintain service effectiveness.
In all cases, there are lots of red flags. Savings are assumed to come from unspecified efficiencies, even when the way services are delivered hasn’t been optimised. Many benefits depend on behaviour change by people across the organisation, not just installing new software. None consider the cost shifting that happens when you reduce visible headcount but increase hidden work in data cleansing, workarounds, exception handling, and vendor dependency. Finally, they underestimate the cost of learning, backfilling, training, retrospective process redesign, change fatigue, and the productivity dip experienced after go-live.
A major IT investment isn’t simply a technology purchase. It’s a high-risk intervention in a complex socio-technical system. If you don’t understand the system first, IT will amplify the waste, workarounds, delays, and blame that is already there.
Here is how it can play out…
“At the planning counter, the new system looked slick—until the first week of lodgements. Applications bounced back for “missing information” that had already been provided, just in the wrong field. Staff spent mornings ringing applicants to re-collect the same details, then re-attaching the same documents. Phone calls doubled, mostly “Can you just tell me where it’s up to?” The dashboard said turnaround times were “on track” because the clock stopped during “awaiting customer” loops.
Meanwhile in local laws, officers found the system couldn’t handle the real-world exceptions. So, they started writing “manual notes” in notebooks and emailing themselves reminders. A shared spreadsheet reappeared to track cases the workflow couldn’t represent. At go-live, the backlog quietly grew: more clicks, more steps, more handoffs. Complaints rose—missed follow-ups, inconsistent decisions, people repeating their story. The weekly report stayed green, while the work moved off-system to get done.”
So, what can councils do?
The good news is that there are people trying to help councils to get major IT investments right.
Three due diligence tests before approving a major IT investment
Be pessimistic on purpose
This is the advice from Professor Robin Gauld and Professor Shaun Goldfinch in their book ‘Dangerous Enthusiasms: E-government, computer failure and information system development’. Across their work on public-sector IT investment failures, the recurring message is that large, ambitious, long-horizon projects routinely over-promise and under-deliver, especially when leaders get swept up in ‘e-government‘ enthusiasm and underestimate complexity and control problems.
Assume forecasts are biased (i.e. the cost, time, and benefits) and treat the business case as a claim to be tested, not a plan to be accepted and implemented.
Keep aims modest and measurable, and avoid ‘everything at once’ transformations.
Prefer modular, incremental projects with real-world checkpoints and the ability to stop without catastrophe (no ‘big bang’ that can’t be unwound).
Governance must surface bad news early (i.e. not just traffic lights, milestones, and spend-to-date). When control is mostly through reports and committees, failure can occur quietly.
Knowledge first, IT last
Professor John Seddon has supported service improvement in public and private organisations for over three decades. He advises ‘fix the method (i.e. way of delivering a service) before digitising it’ (i.e. configuring or coding IT software to support delivering the service). His consistent warning is that public services go wrong when leaders manage by targets, budgets and functional silos instead of studying demand and improving end-to-end service delivery. In those circumstances, digitisation often codifies the wrong work (including avoidable and capacity-stealing failure demand) and makes it harder to change later.
Before making a major IT investment, Seddon says:
Study real demand (i.e what matters to residents, what triggers customer contacts, rework, complaints, and escalations/follow-ups).
Redesign the service against purpose (i.e. ‘outside-in from the viewpoint of the customer) and variety in demand first; only then decide what IT software supports delivery of the improved service.
Be suspicious of ‘standardisation’ being sold as creating efficiency when the actual demand is variable and contextual (i.e. planning, local laws, assets, customer requests, aged services interfaces).
Measure capability and flow, not just activity like the calls handled, jobs closed, or milestones met.
Design for work-as-done, not work-as-imagined
Sidney Dekker’s core field is human factors/safety science: how people and technology interact in real work, why ‘human error’ is usually a symptom of deeper system conditions, and how complex organisations drift into failure over time. A major IT investment is a socio-technical change: it rewires workflows, decision rights, handoffs, and defines what ‘good work’ looks like. Dekker has studied the exact failure modes that show up and he specialises in better governance processes.
If you apply Dekker’s thinking to a council IT investment, the practical takeaway is:
Start with ‘work-as-done’ before procurement. Shadow frontline staff, map handoffs, exceptions, and the ‘real’ rules people follow to keep services moving, especially services with high variety like planning, local laws, customer requests, and asset maintenance. Then design the system and its supporting IT around that reality.
Expect workarounds and treat them as intelligence (i.e. signals of a mismatch), not as misconduct. Workarounds usually signal the system doesn’t match the reality for workers.
Look for drift signals: rising exceptions, backlog, duplicate handling, staff ‘shadow’ systems, increased complaints – even when (perhaps, especially when) if the project dashboard is green.
Build a learning response: safe pilots, parallel runs, rollback plans, strong user support, and time for training/practice. Otherwise, time and budget pressure will force risky shortcuts.
Make governance ‘just’ and inquiry-based: when things go wrong, ask “how did this make sense at the time?” so you uncover the system conditions that create failure (rather than hunting a culprit).
What are useful questions to ask before approving a major IT investment?
Based on the advice of Gauld and Goldfinch, Seddon and Dekker, there are three sets of questions to ask:
Set 1 – Method (Seddon): Ask for evidence – the demand study, failure demand estimate, and before and after measures. Make sure you have answers to these questions – What service study have we done? What demand did we observe? What did we change in the service design before identifying the potential new IT software?
Set 2 – Ambition (Gauld/Goldfinch): Ask for evidence – staged scope, kill switch criteria, and the independent audit/review arrangements. Make sure you have answers to these questions – Exactly what have we done to reduce project complexity? Have we looked at modular scope, short horizons, staged implementation, and independent reality checks?
Set 3 – Drift (Dekker): Ask for evidence – what are the rollback and continuity plans, and how will we detect “drift” early? Make sure you have answers to these questions – Are we looking for, and planning to respond to, staff workarounds, increasing exceptions, backlog growth, manual rekeying, and community complaints?
How can you help yourself?
The sets of questions (really, just due diligence tests) are useful, and I have identified three authoritative sources. There are many more sources of advice. If you are curious and want to know more, try asking ChatGPT or Copilot (or your favourite Ai) this question:
“Find credible, citable evidence (auditor-general reports, VAGO/GAO/NAO/ANAO, peer-reviewed studies, and major post-mortems) of enterprise ERP/CRM/asset IT failures in the public sector. For each case, summarise: what was promised, what happened, root causes, early warning signs, quantified impacts (cost/time/service), and 10 governance actions a council can take to reduce risk. Include citations and links.”
If you really want to tighten up your search, add:
“Prioritise sources from audit offices and primary documents; avoid vendor marketing; include publication dates and direct quotes under 25 words.”
Some final words…
Councils are looking for ways to respond to the challenges of population growth, changing community expectations, and the rate cap. In their long-term plans they are relying on major IT investments to deliver reductions in expenditure through increased productivity, better decisions, and improved customer service. It is a big bet. Firstly, because major IT projects are difficult and exceed the capability of councils to implement. Secondly, they are difficult to govern and there is a real risk of over optimism and drift that gets the council into difficulty before it is recognised. Lastly, unless services have been reviewed and optimised, the implementation of an enterprise IT system will only cement in place inefficiencies and waste.
Before deciding, ask the right questions about what is proposed and why.
A cautious councillor can ask for the IT supplier to carry more risk for their technology. This happens with aquatic facility construction where councils now ask the architect and builder to carry risk for Greenstar compliance and they reduce contract payments if the target Greenstar rating is not achieved. You can also ask for evidence of the success of previous IT installations. This could be at your own council for any major IT change in the last 10 years – ask: What were the reasons for the investment and were the benefits realized? How do you know? The vendor should be able to provide detailed analysis of their success in previous installations, including lessons learned and post-implementation reviews giving quantified achievement of benefits.
Before deciding, gather evidence on your organisations capability and performance of the software.
It is noteworthy that councillors are only given choices about the IT investment needed to improve organisational efficiency, make savings, and improve services. CEOs have decided that the only solution to the councils challenges will come in a cellophane wrapped box from someone else. They are channeling the council down this path and have excluded the alternative that they organise for the people managing the organisation to examine the services they deliver and improve them by focusing on what customers need and expect. It is easier to place a bet on someone else’s solution to your problem than to develop your own.
3100 words (15 minutes reading time) by Colin Weatherby
Podcast option:
Credit: ChatGPT
Summary
Councils under rate caps are being pushed into a capability trap: cutting investment in how work is done, while demanding the same (or more) output.
Doing more with less works for a while, then it quietly destroys the ability to deliver safe, reliable services.
Escaping the trap means shifting from “work harder” to “work smarter” – investing in process capability, not just pushing people to do more.
This piece explains the trap in plain language and offers advice to avoid it.
Introduction
After ten years of “doing more with less”, many council roads managers describe their world like this:
“Today, I barely recognise our roads program. Every budget cycle we cop another efficiency dividend, another round of ‘temporary’ cuts to inspections, reseals, heavy patches and drainage repairs. On paper the program still looks coherent thanks to some clever rephasing and optimistic assumptions, but out on the network the cracks are literal.
We’ve gone from renewing assets at the right time to stretching them well past their use-by date. Crews that used to do planned maintenance now spend most of their time chasing potholes and complaints. We’ve sweated the plant so hard that breakdowns are normal, and cut training and supervision to the point where we’re relying on a few old hands to hold everything together.
What hurts most is knowing this was avoidable. Every ‘saving’ we booked was borrowed against the future condition of the network. We’ve lost capability in quiet ways – trainees we didn’t take on, engineers who left and weren’t replaced, inspectors who no longer have time to inspect, relationships with contractors hollowed out by always taking the lowest price.
The community still expects the same level of service, but we’re no longer set up to deliver it. We’ve traded investment in capability for short-term budget wins, and now the bill is arriving as risk, backlog and a network that’s deteriorating faster than we can look after it.”
This isn’t a story about lazy workers or bad managers. It’s what it looks like when a council slides into what Repenning and Sterman call the capability trap – without realising it.
1800 words (18 minutes reading and/or 20 minutes listening) by Colin Weatherby
I recently found out about Notebooklm and asked it to analyse the entire Local Government Utopia website and answer a set of questions about challenges, solutions and future directions for councils.
The question and answer is below. First, a bit about Notebooklm.
Notebooklm
Notebooklm is a new AI product that takes a specific source or sources nominated by you and provides a summary, or answers to questions you ask about the source or sources that you have uploaded. I loaded the URL for localgovernmentutopia.com but could have loaded pdfs or other types of sources (or combinations of sources). You can load up to 50 different sources with a maximum of 500,000 words.
The person who told me about it had uploaded a manual for their camera as a source and then asked how to change the camera battery. Instead of leafing through a massive pdf manual online, Notebooklm explained how to change the battery with a link directly to the relevant section in the manual!
It also produces podcasts, primarily to help listeners understand complicated topics by hearing a discussion between two people about the source or sources. I was interested in this feature, so I had a go!
Podcast
I asked Notebooklm to make a podcast addressing this question using the Local Government Utopia website as a source:
“What does Local Government Utopia say about what a local government putting the wellbeing of its constituents first looks like; what issues are important and currently not acknowledged in local government; what are current research or policy gaps in local government; any thoughts around recent Commonwealth or Victorian parliamentary inquiries into local government; and finally, what thoughts are there on where public policy might be able to make a meaningful contribution.“
Local Government Utopia 