Risk Factor iconRisk Factor

Medical Marijuana spilling out of a jar

Cyber Intrusion Creates More Havoc for Washington State’s New Marijuana Tracking System

Licensed marijuana product growers and retailers have been very unhappy with Washington State’s new “seed-to-sale” marijuana tracking system that went live on 1 February.

Buggy software has kept many suppliers from shipping their products because of manifest errors and, equally, retailers from accepting their orders. While Washington’s Liquor and Cannabis Board officials have insisted that the myriad software problems are being fixed or work arounds exist for most of them, it also has disclosed that the tracking system experienced a cyber intrusion.

In a letter to licensees, the Liquor and Cannabis Board stated that on 1 February someone downloaded a copy of the traceability database, which in turn affected key operations of the tracking system in a way the Board refused to disclose. The intruder was able to access information for four days of marijuana deliveries, including delivery-vehicle information together with type, license-plate number and VIN numbers. The Liquor and Cannabis Board said that since the latter information was publicly available and no personal information was accessed, there was no need for anyone to be concerned. Retailers and growers, however, were not exactly comforted by the Board’s reassurances.

Read More
The F125 frigate 'Baden-Wuerttemberg' sails in Cuxhaven, Germany

New German Warship Fails Sea Trials Due to Tech Woes

Reducing the size of a combat ship’s complement through advanced automation has been a goal of the world’s navies for decades [pdf]. However, as the U.S. Navy has already discovered, the German Navy is now finding out that this is easier desired than done.

In December, the German Navy refused to commission the lead ship of its new Baden-Württemberg class Type 125 (F125) frigate after it failed its latest at-sea trials. This was the first time that Germany’s navy has ever refused to commission a ship after delivery. The refusal was due in part to unresolved hardware and software integration problems affecting the Baden-Württemberg’s ATLAS Naval Combat System [pdf] and other ship systems, which have plagued the frigate’s sea trials since it entered them in April 2016.

The persistent problems with the €3 billion F125 program, which is meant to replace Germany’s Bremen F122 class frigates, have delayed the Baden-Württemberg’s planned commissioning from occurring first in 2014, then in 2016, and now to sometime late this year―assuming its problems can be resolved. In addition to the IT troubles, the ship reportedly has issues with its radar and the fireproof coating of its fuel tanks—and it’s overweight. It is critical that the ship’s problems be solved quickly since three other frigates in its class should all be delivered before year’s end.

Read More
Computer with cyber criminal

Healthcare IT Systems: Tempting Targets for Ransomware

Well, there’s no use in waiting, I suppose. Two Thursdays ago, Chicago-based electronic health records provider Allscripts Healthcare Solutions suffered a ransomware attack that paralyzed some of its services. This past Friday, the company announced it had completely recovered from the cyberattack. But not before a class action lawsuit [pdf] was filed against it by an orthopedic non-surgery practice for failing to secure its systems and data from a well-known cybersecurity threat, i.e., a strain of SamSam.

The ransomware attack impaired Allscripts’ data centers in Raleigh and Charlotte, North Carolina, affecting a number of applications, such as its Professional EHR and Electronic Prescriptions for Controlled Substances (EPCS) hosted services, which were mostly restored within five days, according to the company. Other services, like clinical decision support, analytics, data extraction, and regulatory reporting, took the longest to make operational again.

Allscripts tried to play down the impact of the loss of services, saying that only about 1,500 out of the 45,000 physician practices it serves were impacted; “none were hospitals or large independent physician practices”; and no patient data was taken.

Read More
Illustration of computer pointer fingers accusing a group, with most considered guilty.

Michigan’s MiDAS Unemployment System: Algorithm Alchemy Created Lead, Not Gold

Perhaps next month, those 34,000 plus individuals wrongfully accused of unemployment fraud in Michigan from October 2013 to September 2015 will finally hear that they will receive some well-deserved remuneration for the harsh treatment meted out by Michigan Integrated Data Automated System (MiDAS). Michigan legislators have promised to seek at least $20 million in compensation for those falsely accused.

This is miserly, given how many people experienced punishing personal trauma, hired lawyers to defend themselves, saw their credit and reputations ruined, filed for bankruptcy, had their houses foreclosed or were made homeless. A sum closer to $100 million, as some are advocating, is probably warranted.

The fiasco is all too familiar: a government agency wants to replace a legacy IT system to gain cost and operational efficiencies, but alas, the effort goes horribly wrong because of gross risk mismanagement.

This time, it was the Michigan Unemployment Insurance Agency (UIA) which wanted to replace a 25-year-old mainframe system. The objectives of the new system were three-fold and reasonable. First, ensure that unemployment checks were only going to people who deserved them. Second, increase UIA’s efficiency and responsiveness to unemployment claims. And third, through those efficiency gains, reduce UIA’s operational costs by eliminating more than 400 workers, or about one-third of the agency’s staff. After spending $47 million and two years on the effort, the UIA launched MiDAS, and soon proclaimed it a huge success [pdf], coming in under budget and on-time, and discovering previously missed fraudulent unemployment filings.

Read More
Illustration of corporate logos with data information.

Will U.S. Corporations Ever Take Cybersecurity Seriously?

It’s another month, and another major IT-related security problem has been uncovered. The latest, the security flaws discovered in Intel, AMD, and AMR chips that can allow the bypassing of operating system security protections are a bit different than most vulnerabilities. They are hardware rather than software-based, and their impacts are exceptionally widespread, impacting nearly every Intel processor made since the mid-1990s. Billions of chips in total could be affected.

Intel, in conjunction with AMD, ARM, operating system vendors, and others, has been working on software and firmware security updates to close the security holes, with mixed success. There were reports that Intel’s firmware update had a bug that needed fixing itself, and that there were problems with updates on some AMD-based machines. There is also a debate between Intel and Microsoft regarding whether some of the updates would result in a significant slowdown of a patched machine. Intel insists the fixes will likely cause minimal performance impacts for most users, while a Microsoft executive instead seemed to suggest that users might be better off not updating their machines if loss of performance was greater than the security gained.

Intel has not only been downplaying the performance impacts of the fixes, but the financial impacts as well, even going so far as to say the flaws will have no material impact on the company’s finances. That is rather amazing: billions of products sold with two fundamental security flaws that need urgent correction and the result isn’t seen as being material. It leads to the question of what would need to happen for an IT security issue to become material, not only to Intel, but to all U.S. corporations.

Read More
Photo of a keyboard with 2018 on it.

2018’s IT Failures Already Have a Familiar Look

The more things change, the more things seem to stay the same, at least for international travelers arriving in the United States over the New Year’s holiday period. For a second year in succession, the U.S. Customs and Border Protection (CBP) computer systems experienced an outage that left thousands of passengers across the United States waiting in long lines to clear customs. This time, the outage was only for about two hours, while last year’s lasted four hours and affected more than 13,000 passengers on 109 flights, according to a Department of Homeland Security Inspector General report released last November that investigated the disruption. The DHS IG report indicated that the 2017 New Year’s problem was caused by an inadequately tested software change related to CBP’s long-running IT modernization effort.

No official cause or total number of passengers or flights affected has been given for the latest CPB computer hiccup. However, another IT modernization-related issue is a likely culprit given that a September 2017 Homeland Security IG report assessing the state of the Customs Department’s IT systems and infrastructure indicated that the main CPB computer system used to screen international passengers has seen its performance “greatly diminished over the past year as a result of ongoing efforts to modernize (its) underlying system architecture.” Before this latest outage, there were three other service disruptions in 2017, according to the IG report.

The few hours of distress suffered by international travelers, however, is minisucle in comparison to that of the tens of thousands of Canadian federal government workers who are now facing a third year of payroll system torment. In what is quickly moving into contention as one of the worst government-managed IT implementations ever, over half the 290,000 plus civil servants paid through the IBM-developed Phoenix pay system have been underpaid, overpaid, or not paid at all since its rollout began in February of 2016. Government records show that, as of November 2017, there were some 589,000 payroll-related transactions still awaiting processing, meaning many government employees are contending with several pay issues. For instance, in Canada’s Department of National Defense, 63 percent of its workers  had outstanding pay issues as of 1 November 2017, with 15 percent having three or more outstanding problems to contend with. According to Canada’s Auditor General, nearly 50,000 government workers have had to wait over a year to get their pay straightened out.

A major objective of the Phoenix system—which traces its history back to 2009—was to save the government C$70 million per year through reductions in payroll processing overhead and staffing costs.  However, things have not turned out as planned. While the original cost of the project was pegged at C$309.5 million, Public Services and Procurement Minister Carla Qualtrough, who is now in charge of the project, admitted in November that it might cost as much as C$1 billion and three or more additional years to completely fix the system. The added costs include hiring hundreds of new payroll staff—including some of the 2,700 laid off when Phoenix was introduced—to try to sort out the mess.

The pain has been acute for the thousands of public workers who have received less than their correct salary, but those thousands who have been overpaid have not escaped misery, either.  For this latter group, the government delivered a New Year’s surprise: notice that they will have until 31 January 2018 to pay back any overpayments they received. If they don’t, they have been told they will have to pay back not the net salary overpayment after taxes were taken out, but the gross salary overpayment the workers erroneously received.  They then will have to wait to claim the difference back on their personal income tax filings in May, with refunds coming who knows when. To say the least, demanding  money that they did not receive and further complicating their tax returns has not made the affected government employees very happy, given that most have already spent months trying to get their pay straightened out to no avail.

Read More

Remembering the Technology Glitches and Failures of Tax Years Past

We're pleased to note that on 1 April, IEEE Spectrum won the Jesse H. Neal Best Infographics Award for our series "Lessons from a Decade of Failures." To celebrate, it seemed like a good time to once again take a dive into the Risk Factor archives and search for additional historical lessons. Because we're nearing the end of tax season here in the United States, I decided to examine the often volatile combination of tax policy and IT systems. Tax-related problems are some of the most painful IT failures, because they tend to hit citizens right where it hurts most: their bank accounts.

Below you'll find some of the most noteworthy operational glitches of the past decade, but as with previous timelines, the incidents listed here are merely the tip of the iceberg, and should be veiwed as being representative of tax-related IT problems rather than comprehensive. It doesn't even include incidents of tech-assited fraud, data breaches, or failed modernization projects (like the cancellation of the My IRS Account Project). It's not always easy to identify the exact impact of tax related glitches: in some cases it's easier to measure the number of people affected, while in others, the monetary cost is more straightforward. Use the dropdown menus to navigate to other incidents that might be hidden in the default view.

In reviewing this list of failures, a few of lessons jumped out at me:

  • For ongoing, excruciating, cringe-worthy tax-tech pain, no one beats Her Majesty's Revenue and CustomsAs my colleague Bob Charette has chronicled, the multiyear rollout of the Pay-As-You-Earn computerized tax system is a textbook case of technological and bureaucratic hubris in the face of a challenging IT problem. You can see from the timeline the magnitude of people affected by calculation errors, which grew over time.
  • Data validation, verification, and sanity checks remain poor. Increasing computerization has meant an increase in mistakes that should have been caught by common sense. Tax systems need better safety checks and governments need to be more skeptical of sudden, unexpected windfalls.
  • Don't automatically trust automatically generated notices. It seems like the software in tax systems that generates letters and notices is subject to even less scrutiny and oversight than the rest of the systems' components.
  • There's danger in waiting to file your taxes at the last minute, but doing them early can also cause problemsThere are many examples of tax services simply being unprepared to process early returns, whether because of last-minute changes to the tax code, or from data that has not yet been updated.

Clearly there are lots of advantages to digitizing tax calculation and collection, including efficiency and accuracy. But it's worth keeping in mind that in all likelihood, our IT systems are bound to fail occasionally, so we need to make sure our laws and systems are better prepared for those contingencies. In the past decade, our ability to cause harm with tax systems has often outpaced our ability to make things right.

If there's a notable tax-related glitch you'd like to see represented on the timeline, let me know in the comments, and I'll try to add it.

We Need Better IT Project Failure Post-Mortems

In pulling together this special interactive report on a decade’s worth of IT development projects and operational failures, the most vexing aspect of our efforts was finding trustworthy data on the failures themselves.

We initially started with a much larger set than the 200 or so projects depicted in this report, but the project failure pool quickly shrank as we tried to get reliably documented, quantifiable information explaining what had occurred, when and why, who was affected, and most importantly, what the various economic and social impacts were.

This was true not only for commercial IT project failures—which one would expect, given that corporations are extremely reticent to advertise their misfortunes in detail if at all—but also for government IT project failures. Numerous times, we reviewed government audit reports and found that a single agency had inexplicably used different data for a project’s initial and subsequent costs, as well as for its schedule and functional objectives. This project information volatility made getting an accurate, complete, and consistent picture of what truly happened on a project problematic to say the least.

Our favorite poster child for a lack of transparency regarding a project’s failure is the ill-fated $1 billion U.S. Air Force Expeditionary Combat Support System (ECSS) program (although the botched rollout of HealthCare.gov is a strong second).  Even after multiple government audits, including a six-month, bi-partisan Senate Armed Services Committee investigation into the high-profile fiasco, the full extent of what this seven-year misadventure in project management was trying to accomplish could not be uncovered. Nor could the final cost to the taxpayer be ascertained.

With that in mind, we make our plea to project assessors and auditors asking that they apply a couple of lessons learned the hard way over the past decade of IT development project and operational failures: 

In future assessments or audit reports of IT development projects, would you please publish with each one a very simple chart or timeline? It should show, at a glance: an IT project’s start date (i.e., the time money is first spent on the project); a list of the top three to five functional objectives the project is trying to accomplish; and the predicted versus actual cost, date of completion, and delivered functionality at critical milestones where the project being reviewed, delivered, or canceled.

Further, if the project has been extended, re-scoped or reset, please make the details of such a change absolutely clear. Don’t forget to indicate how this deviation affects any of the aforementioned statistics. Finally, if the project has been canceled, account for the opportunity costs in the final cost accounting. For example, the failure of ECSS is currently costing the Air Force billions of dollars annually because of the continuing need to maintain legacy systems that should have been retired by now. You’d think that this type of project status information would be routinely available. But unfortunately, it is rarely published in its totality; when it is, it’s even less likely to be found all in one place.

Similarly, for records related to IT system operational failures, would you please include all of the consequences being felt—not only financially but to the users of the system, both internally and externally?  Too often an operational failure is dismissed as just a “teething problem,” when it feels more like a “root canal” to the people dependent upon the system working properly. 

A good illustration is Ontario’s C$242 million Social Assistance Management System (SAMS), which was released more than a year ago, and it is still not working properly. The provincial government remains upbeat and positive about the system’s operation while callously downplaying the impact of a malfunctioning system on the poor in the province.

More than 100 years ago, U.S. Supreme Court Judge Louis Brandeis argued that, “Publicity is justly commended as a remedy for social and industrial diseases. Sunlight is said to be the best of disinfectants; electric light the most efficient policeman.” Hopefully, the little bit of publicity we have tried to bring to this past decade of IT project failures will help to reduce their number in the future.

Wishful Thinking Plagues IT Project Plans

“An extraordinary failure in leadership,” a “masterclass in sloppy project management,” and a “test case in maladministration” were a few of the more colorful descriptions of UK government IT failures made by MP Edward Leigh, MP for Gainsborough, England when he was the Chairman of the Public Accounts Committee.

Leigh repeatedly pointed that government departments consistently were not only wholly unrealistic in their IT project costs, schedule and technical feasibility, but also didn’t take any responsibility for the consequences of these assumptions.

Read More

Sorry for the Inconvenience

After looking back at the project failures chronicled in the Risk Factor for our recent set of interactive features “Lessons From a Decade of IT Failures,” I became intrigued by the formulaic apologies that organizations put out in their press releases when something untoward happens involving their IT systems.  For instance, below are three typical IT mea culpas:

“We would like to apologize for the inconvenience this has caused.”

“We regret any inconvenience this may have caused patients.”

“We apologize for the inconvenience to those affected.”

The first apology came about as a result of the Nationwide, the UK’s largest building society, charging 704,426 customers’ debit card twice for the same transaction, which it blamed on a batch file that was doubly processed. The second apology was in response to the crash of Northern California’s Sutter’s Health $1 billion electronic health record system crashing for more than a day across seven of its major medical facilities because of a faulty system upgrade. The last apology was prompted by the shambolic mess that marked the rollout of California’s EDD unemployment system that affected at least 185,000 claimants, many of them for weeks.

Apparently, regardless of the impact or duration of an IT failure, it is viewed by the offending organization as being merely an inconvenience to those experiencing them. Ontario’s Social Services Minister Helena Jaczek went so far as to liken the months of havoc resulting from the botched rollout of a new provincial CN$240 million welfare and disability system as reminding her “of when I have my BlackBerry telling me that there are issues and I need an update. . . it is often very inconvenient.”

Hmms, not receiving a desperately needed disability or subsistence check equates to a Blackberry software update. Who knew?

Most apologetic public statements by corporate or government officials at least attempt to provide the pretense that executive management feels bad for the consequences of their organization’s IT oofta. However, there have been other times where perhaps not apologizing would have been a better strategy than the apology given. Below are a few of my favorite “best of the worst apologies” from the Risk Factor blog files which clearly indicate that the organization would have been a lot happier if it didn’t have to deal with those pesky customers or taxpayers.

We start off with two of the largest organizations in Ireland that worked overtime to antagonize their respective customers in the wake of billing system errors. The first is Irish Rail, which discovered that a software upgrade to its vending machines caused tickets to be issued to some 9,000 passengers without actually deducting the fare amounts from their debit cards for several days. On the Friday, a week after the discrepancy was discovered, Irish Rail decided to notify the affected customers by way of a press release on its website, which mentioned that it would be deducting the fare amounts due it beginning on the following Monday.

Irish Rail’s press release also stated, “We apologies [sic] for any inconvenience this fault causes customers,” which for many could include incurring hefty penalty charges for unauthorized overdrafts on their debit cards. When asked why it couldn’t wait a week so its customers could ensure that their accounts had the funds to cover the charges, Irish Rail responded it had every right to collect the money immediately and was going to do so. Unsurprisingly, the affected Irish Rail customers didn’t think much of the company’s apology.

Another “show me the money” demand disguised as an apology came from Eircom, the largest telecom provider in the Republic of Ireland. It, like Irish Rail, had a billing “system error” that did not directly debit some 30,000 customer bank accounts correctly, even though its customers’ bills indicated otherwise. Eircom deemed the incident “regrettable” and further stated that “it’s embarrassing and we're very sorry that it's happened.” However, Eircom was neither too embarrassed nor sorry enough to insist that although it planned to reimburse customers the failed direct debit fee charge of €18.45, customers would still have to pay all monies owed the telecom in their next billing cycle. Ireland’s telecom regulator was as unhappy with Eircom’s payment demand as its customers were, even more so because the utility also failed to inform it of the billing error.

“Teething issues” also featured prominently in several apologies for IT fouls ups. Take, for instance, EnergyAustralia, which claimed that on-going “teething problems” with its newly introduced accounting system were why 145,000 of its customers had not been billed for their electricity or gas usage on time, including 21,000 who had never received a bill from the utility. In the apology the company issued, it tried to downplay the extent of the foul-up by saying, “We are sorry to the small number of customers who haven't had the best experience and we're working round the clock to improve our service.” However, for some 12,500 EnergyAustralia customers, the clock spun around for more a year before their billing issues were finally corrected.

Automotive manufacturer McLaren also apologized that its MP4-12C $229,000 supercar was suffering from “teething problems.” Ron Dennis, the executive chairman of McLaren Automotive and McLaren Group, sent out a letter to customers that stated in part, “As you will have already heard from my staff, we are experiencing some early software bugs resulting in unnecessarily sensitive warning lights, battery drainage in certain conditions and IRIS [infotainment] performance issues. My team and the McLaren retailers are working with the pace and intensity that the McLaren brand demands to fully resolve these bugs rapidly and effectively to ensure that any inconvenience to you is kept to a minimum.” Dennis, however, tried to make up for the inconvenience by promising customers that he was going to give them “a pre-release copy of the new McLaren: The Wins coffee-table book." I wonder how many software bugs it would take to get a personally signed copy of the book.

Additionally, there were a couple of organizations that had to make so many apologies that customers just stopped listening to them, deciding  to head for the exits instead. Take, for example, UK’s RBS Group which had a major system meltdown in the summer of 2012 caused by a routine software-update gone bad that kept millions of its bank customers from accessing their accounts for days, and some even for months. At the time, then Chairman Stephen Hester apologized, saying, “Our customers rely on us day in and day out to get things right. On this occasion we have let them down… Once again I am very sorry for the inconvenience.”

Various RBS Group spokespersons had to apologize several more times that summer as they promised everything would soon be made right, which quickly turned out not to be true.  At the time, RBS promised to invest hundreds of millions of pounds into upgrading its IT systems to keep major disruptions from happening again.

However, RBS has suffered significant glitches since, including in December 2013 on Cyber Monday and once more in June of this year. Although after each incident RBS management stated that it was “sorry for the inconvenienced caused” and that the incident was “unacceptable,” tens of thousands of its discomforted customers have decided to do their banking elsewhere.

While RBS may have seen droves of customers desert it over its IT failures, it is nothing compared to Australia’s telecom company Vodafone which has seen millions of its customers leave because of the company’s persistent IT ooftas. The root of the problem can be traced to 2009, when Vodafone merged its network with rival Hutchinson’s “3” network.  Not surprisingly, the merger’s objective of creating a high-quality, unified network across Australia wasn’t as easy or seamless as envisioned. Customer complaints about poor Vodafone service grew throughout 2010, but really came to a head when a network software upgrade in late 2010 didn’t work as expected. Instead of speeding up network traffic, the upgrade slowed it down. That problem took weeks to fix, angering legions of Vodafone customers. 

Then a different, concurrent software issue caused additional problems across the network. Vodafone, which by now was being referred to in the press as “Vodafail,” had to apologize to its angry customers multiple times that the company was “truly sorry” for the continued “dropped calls, delayed SMS and voicemails, slow data speeds, inconsistent coverage, and long waits when you called us.” For more than 2 million Vodafone fed-up customers who left the company between 2010 and 2013, the company didn’t improve fast enough. Finally, after spending AU$3 billion to upgrade its networks and customer support, Vodafone Australia announced earlier this year that it had started adding customers again.

There was also an interesting apologetic non-apology that happened in my home state of Virginia. In the summer of 2010, a server problem at the Virginia Information Technologies Agency (VITA) knocked out the IT systems used by 27 of Virginia’s 89 state agencies for several days, and a number of agencies were affected for over a week. At the time, the state’s IT infrastructure was in the midst of a $2.3 billion upgrade which was a constant source of contention between Virginia and its contractor Northrup Grumman.

When the server problem was finally fixed, Northrop Grumman vice president Linda Mills put out the expected pabulum and said the company “deeply regrets the disruption and inconvenience this has caused state agencies and Virginia citizens.” However, Grumman’s “regrets” were immediately undercut by a company spokesperson who, when asked by a Richmond Times-Dispatch newspaper reporter whether Mills’ statement was an apology, declined to comment. Whatever little goodwill that was left in state government for Northrop Grumman quickly vanished.

In May of 2011, after an investigation into the outage, NG agreed to pay a $4.7 million fine for the outage, which is an apology of the best kind, in my opinion.

Our final apology was given through firmly clenched teeth. For years, Her Majesty's Revenue and Customs (HMRC) in the UK worked to upgrade (pdf) its troubled computer systems. HMRC promised that when complete, the new PAYE (pay as you earn) system would significantly reduce both over- and underpayments of taxes. When it was fully introduced in 2010, the HMRC announced that some 4.3 million UK taxpayers were going to receive letters stating that they had paid on average £400 too much in taxes between 2008 and April of 2010. Additionally, another 1.5 million would be receiving letters just before Christmas that they had paid on average £1,428 too little over the same period, and HMRC wanted its money now. Furthermore, the HMRC indicated that another 6 million taxpayers prior to 2008 were likely owned money for taxes paid previous to 2008, and another 1.7 million possibly owed more taxes. This group would be receiving letters soon, too.

The underlying reason for the millions of over-and under-payments was that taxpayers were being placed in an incorrect tax bracket for years because of errors in the new HMRC PAYE computer system database.

Needless to say, the UK public was not a happy bunch at the news. Fueling their unhappiness was the attitude of HMRC Permanent Secretary Dave Harnett, who stated in a radio interview there was no need for him or his department to apologize for the errors or demand for quick payment of owed taxes, because at least to him, the PAYE system was working as designed: “I'm not sure I see a need to apologise... We didn’t get it wrong.”

Politicians of both parties were appalled by that statement, calling Harnett out of touch and arrogant, especially in light of all the reported PAYE system foul-ups. Harnett was forced by senior Conservative party leaders to retract his statement the following day, saying that he was “deeply sorry that people are facing an unexpected bill.”

A few days later, however, HMRC CEO Dame Lesley Strathie made it very clear Harnett’s apology was really a non-apology when she insisted  that HMRC staff made “no mistakes,” and any and all errors were due to taxpayer mistakes. Dame Strathie also said the critiques of HMRC's performance was unfair since it couldn't pick and choose which customers to serve—it had to deal with everyone—whether her government department liked it or not. That bit of insight didn’t go over well, either.

HMRC’s PAYE system continues to cause grief to UK taxpayers, and the HMRC is taking yet another crack at updating its computer systems. Unfortunately, UK taxpayers don’t have a choice of which tax department to use, like customers of RBS or Vodafone do with banks or telecom companies. 

If you have some “worst IT foul-up apologies of all time” stories to add, please let me know.

Advertisement

Risk Factor

IEEE Spectrum's risk analysis blog, featuring daily news, updates and analysis on computing and IT projects, software and systems failures, successes and innovations, security threats, and more.

Editor
Robert Charette
Spotsylvania, Va.
Contributor
Willie D. Jones
New York City
 
Load More