The perennial call for public sector reform has not slackened. The pain of austerity measures and the pressures for increased efficiency heighten that call. And, the hype around “smart cities” amps up the pressure for municipal leaders faced with decisions about which problems to attack first, and which tools are most appropriate. But most organizations are not starting from a clean slate. That’s exactly the issue. In most cases we’re talking about reform, about doing things differently, not starting from scratch.
When we asked government leaders what their top priorities are, improving the customer experience comes in on top: 68% report the customer experience is either a high or critical priority. But reducing costs is right up there with it. That’s the age-old do-more-with-less mantra. And, from a technology perspective their top priority is to upgrade or replace legacy systems, which might not sound like the wiz bang “smart” technology we’ve been hearing so much about. But it’s likely the smartest thing these governments can do; and when they do, they should do it together.
As we all learned as kids, it's nice to share. That holds true for public sector organizations as well, particularly in tough times. Public sector organizations don't have the privilege of dialing back on scope in challenging economic times. In fact, when the going gets tough, government organizations often have to kick into high gear. And that was the case with state unemployment insurance (UI) programs in the US, which saw spikes in applications when the economy slumped. But in most states the technology infrastructure wasn’t up to the task.
Legacy systems were on life-support... Colorado’s 25-year-old COBOL-based mainframe systems continued to process unemployment insurance claims, but it was increasingly difficult and costly to find the "doctors" to keep it alive. They had to bring developers out of retirement to maintain it. State officials knew it was only a matter of time before they had to pull the plug on their system.
…and just weren’t up to the task. Not only did the “look and feel” leave a lot to be desired, the legacy system failed to deliver. The system ran processes in batch mode, meaning that data was typically collected over a period of time (daily, weekly, or monthly) and processed into the system at the end of the period. Daily downtime for processing excluded the possibility of 24-hour availability or even extended hours. The delays and lack of availability frustrated end users who wanted or needed real-time or near-real-time information to make decisions.
Twenty three years ago I arrived with a backpack and my best friend. Last week I went back. The city was as welcoming this time as it was the last, although the circumstances of my visit – and certainly my accommodations – were vastly different.
Pamplona is a city of about 200,000 inhabitants in Navarra, in the North of Spain. It is best known for the running of the bulls or, as it is known locally, the Festival of San Fermin, which many of us were first introduced to in Ernest Hemingway's The Sun Also Rises.
The bulls were not what brought me to the region this time (although they were the principal reason for my first visit). Last week I participated in e-NATECH, a tech industry forum organized by ATANA, an association of local ICT companies in Navarra. From what I saw in both the audience and across the city, Pamplona is clearly a front-runner in terms of ICT (and bulls as I recall from my first visit).
There has been a lot of negative press and commentary regarding the recent Queensland Health Implementation of Continuity Project (SAP HR and Payroll), which recently experienced a very public failure as many employees were not paid due to multiple points of failure in the project. The recent Auditor-General's Report on the process is damning, spreading the blame across multiple agencies and the systems integration partner, IBM. I make no claims to be familiar with the intricate details of the process, but I have read the report and feel I have a clear understanding of the (many!) points of failure.
While this project did seem to be a monumental failure, I would suggest that we consider two important facts: