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 for the CEO to outsource risk. They pass on the responsibility for organisational service improvement 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.
Lancing Farrell raised several important issues in providing advice to a colleague regarding risk management. How does a council balance the pressure not to take risks and fail, with the competing pressure (often from the same sources) to take risks and meet demands to create new value?
Risk is an interesting concept and there are various definitions. I like to think of it simply as the uncertainties related to achieving your goals. It is about the hazards along the pathway as you make your way towards your destination.
Businesses that don’t take risks will fail. They become uncompetitive or customer satisfaction drops. Either way, they lose business to competitors taking risks to create value that customers want and will pay for. We can all think of the companies that have taken big risks in redefining a service or product to create a new market.
You are probably wondering what this might have to do with local government. Aren’t we just doing what we have always done?
Many councils are. Whether they should be, or whether they will be able to continue to do so, should be questioned. We now live in the ‘age of the customer’ – residents want personalisation, mobility, self-service, rapid response, and efficiency (efficiency for them, not the council). The variability introduced by customers must be quickly and effectively absorbed by the organisation. Complexity, by its very nature, creates risks.
In conjunction with mandated limits on prices (the rate cap) and growing numbers of customers (as Lancing points out, Melbourne is growing rapidly), the rising expectations of residents means that councils must do things differently. Different usually involves risk taking.
I recently attended a training session on developing an organisational risk appetite. It showed me how councils could identify hazards and manage risks differently, yet still satisfy the pressure to stop things going wrong while meeting the demand to create new value. It needs a re-think and a more sophisticated approach to risk and compliance. Continue reading →
Is there a delegation for taking risks at your council? Does your council have a risk appetite? Are the strategic risks that have been identified appropriate? Are the operational risks relevant? Does the audit program decrease or increase risk?
These are questions that a colleague raised with me recently when trying to understand the way risks were managed at their council. I suggested they look at their risk management framework – how is risk assessed in terms of likelihood and consequence. This should explain the inherent risk, current risk rating, the target risk and rate the effectiveness of controls. It can make interesting reading.
Next, I suggested they look for their organisations lists of key risks – strategic and operational. These are usually in the risk register. This isn’t always easy to find. Someone in the risk department will have it. Most councils will have up to 8-12 strategic risks. There will be many more operational risks.
Councils are very risk aware. Some people describe it as risk aversion. I think this is driven by the multiple accountabilities that councils live with – the Minister for Local Government, the Ombudsman, the courts, the media and the community. Sometimes it is hard to know who is going to take issue with what you have done. Continue reading →
Yes, it is that time of the year when our engineers and accountants become highly creative. By June 30 they will need to explain whether or not the targeted amount of capital works has been completed. Often the target is expressed as simply as ‘90% capital program completed’. Usually it is a KPI for the CEO and senior managers. That makes it an important target.
So, why the need for such high levels of creativity?
Delivering 90% of the planned capital works is harder than it sounds. Many councils would have averaged around 60% to 70% over the last ten years. This is partially explained by growth in capital expenditure that has exceeded the organisational capacity to deliver. Another part of the explanation is that capital works programs have become more diverse with more people participating in the planning and delivery across the council. As a result, projects have become more complex and people with inadequate project management skills are often involved. Finally, councillors have become much more involved and the capital works program will now have projects that councillors, sometimes in response to community submissions to the budget process, have included – often at the last minute.
As the capital works program has grown, become more complex, involved more people with less skills, and started to include projects without adequate pre-planning or feasibility analysis, especially if they require community engagement, it has become much more difficult to deliver the whole program. But the target remains.
Colin Weatherby has made some interesting points in writing about pretend managing. A colleague recently reminded me of another important idea – there are two kinds of work in any workplace: the imagined and the real.
He was discussing his work in injury prevention in the workplace. In his interactions with injured workers and their managers he has observed that there are two types of work. The imagined work exists in the minds of the managers making decisions about what and how workers will do their work.
When discussing worker’s injuries with managers, the managers frequently describe their understanding of the work and how it happens. This is imaginary work because usually they have not done the work. Some have not even studied the work. They are in charge of the work being performed and believe they know what is going on.
In comparison, the real work is what injured workers describe. It is how they actually do the work. It includes the short cuts and workarounds that are not in any Safe Work Method Statements. It is what they know from doing the work every day.
It is important for managers to know that there are two types of work and that there is a difference.
If managers operate as though their understanding of work is accurate and complete they will make mistakes. And, according to my colleague, workers will continue to be injured. Recognising that there is real work, and that it is important to understand exactly how it operates, is essential. Organisations need ways for the two types of work to come together. The Service Action Plans described in an earlier post is one way for this to happen.
There is no doubt that pretend managers are a problem. But a pretend manager dealing with imagined work is potentially a much bigger one.
I was reminded today of a practice that seems to have crept into local government with the increasing insecurity and risk aversion of top management. It is similar to the concept of ‘risk farming’.
The practice involves your manager avoiding responsibility by setting up meetings for anything that is happening that they sense could have a down side. In the past, a discussion with your manager at your one-on-one meetings would have sufficed. You could let them know what is happening and undertake to keep them informed.
Now, they are likely to ask you to set up a series of meetings involving them and anyone else they can think of who may have an interest in the matter. The purpose is to ‘keep an eye’ on the issue and ‘support’ you in seeing it through. At the meetings you become publicly accountable for your management of the matter.
In the event that the matter blows up, your manager will implicate everyone else involved and they will be witnesses to your failure. Your manager will no longer be held accountable for your performance – after all, there was a whole group of people ‘supporting’ you.
I am old enough to remember when a manager would provide support by encouraging and advising, and by standing by your side when things were getting tough. They don’t seem to be able to get out of the way fast enough now.
As someone said to me recently, when people don’t know something they get sacred and when they get scared their aversion to risk goes up.
This is the third post in a series of four. It addresses some of the challenges to design-thinking. Jon Kolko has identified several.
His first challenge is accepting that you will be dealing with more ambiguity.
“It is difficult if not impossible to understand how much value will be delivered through a better experience or to calculate the return on investment in creativity.”
He says that ambiguity doesn’t fit well with organisations that value ‘repeatable, predictable operational efficiency’. This will be an issue for councils seeking to use design-thinking. For councils, there is an expectation that value will be created through efficient use of resources without any waste. The strong risk aversion of local government reinforces elimination of uncertainty, or at least pretending it has been eliminated. Embracing a culture or experimentation, customer value creation and risk taking will be very challenging. Continue reading →
Local government executive recruitment is a game. Often recruitment is not genuinely based on competence and ability. In many cases, relationships are far more important. I have heard it described as the ‘deep web’ – what you see isn’t all there is. So, how does it work?‘
Councils recruiting a new CEO tend to go for ‘tried and true’ or ‘shiny and new’. I think analysis will show an alternating pattern from one to another. It is almost as though councilors become bored with their CEO, or, more likely, the CEO refuses to do what they tell them to do. Once a CEO stands up and says ‘no’, they are likely to be on the way out.
Councilors know that they can demand that a CEO does what they want – whether or not it is in their or the community’s best interests. I think that once a council has dismissed a CEO and they have a ‘taste of blood’ they are more likely to do it again and a cycle of CEO non-reappointments and appointments begins (with all the disruption this brings).
I have read Lancing Farrell and Colin Weatherby’s posts on characteristics of demands, redesigning operations and improving service operations through action plans and service redesign, with some interest. It is all good stuff and not too difficult to understand or do. The question I ask myself is why I don’t see it happening everywhere across the sector. The ‘special and different’ posts partially explain it but I think there is more to it.
To begin with, the motivation to make improvements doesn’t really exist. People say they want to improve the quality of services to their community, and in response to threats like rate capping they say they want to be more efficient. But they don’t really want to do either.
Most councils have the potential to improve productivity by 10-15% (more in some councils). Continue reading →
Local Government Utopia 