December 22, 2013Doug Hadden
Doug Hadden, VP Products
I've come to look forward to the year-ending review of IT disasters from journalist Chris Kanaracus from the IDG News Service and the musing of analyst Michael Krigsman. In the 2013 round up, Krigsman opines that "nothing has changed" in the nature of IT failure. “People mistakenly believe that IT failures are due to a technical problem or a software problem, and in fact it has its roots into the culture, how people work together, how they share knowledge, the politics of an organization. The worse the politics, the more likely the failure.”
Could Krigsman be Right? Are we doomed to repeated large IT project failure?
Kanaracus had documented 33 different cases from 2010, 2011, 2012 and 2013. One can argue that IT failures that reach the press and become well-known are sensational and may not be representative of the state of success or failure. (All 33 come from the English-speaking developed world of the United States, Canada, the UK and Australia.) It seems that these failures reported by Kanaracus are among the very worst IT disasters of the year.
A quick analysis of these failures shows that a slight majority come from the public sector and the vast majority involve Enterprise Resource Planning (ERP) deployment.
Although within the realm of reasonable statistical probability, public sector IT failures seem disproportionate to market activity.
And, all non-ERP failures were from the public sector.
There is politics in the public sector, and different incentives around failure, as Rich Farrell of Panorama Consulting suggests: "government program managers are not always held accountable for their decisions." There is clearly an organizational change management problem that is more accute in the public sector than the private.
You can't quibble with Krigsman that we don't seem to learning much. After all, most of these projects were implemented by large systems integration firms with "repeatable" certified processes like CMMi-Level 5. The project management discipline has been around for some time.
The Public Sector Software Connudrum
One of the recent publicized government IT failures involved a major ERP payroll system. The manufacturer, SAP, stepped into the project when the systems integration firm was fired. This was the right thing to do. Nevertheless, the project was canceled and there is a lawsuit. Perhaps it was too late to recover. The general view within the tech community agrees with Krigsman that the software is rarely at fault. Consultant Jarret Pazahanick was among those who take that point of view.
— Jarret Pazahanick (@SAP_Jarret) December 20, 2013
My reading of the situation is that there was a gap between built-in software capabilities and customer needs. And, it is likely that legislative changes would have been needed to adapt processes to meet "out-of-the-box" capabilities. This generated the need for customization. It's no wonder that many government organizations look at this large gap between ERP built-in functionalities and needs as being better to custom develop. What governments can end up with is either the custom healthcare.gov failure or the customized ERP Cover Oregon failure. It might suit the general narrative to blame governments for these failures.
What is the Role of Vendors to Government?
Public sector organizations are criticized for not properly articulating business rules. I wonder how it gets to this point where systems integration firms send consultants who only have a passing understanding of typical government procedures. Government people don't want to sit down to train the consultant about how budgets are managed. Consultants should be asking about how salary budgets are managed, whether programs are reported from the financial system and what are the rules for asset capitalization.
Vendors need to realize that they have a moral obligation when public money is being spent. Vendors should be augmenting government IT capabilities rather than finding more creative billing methods.
The Third Way
There is a general view that ERP software originally designed for the private sector and extended to meet needs or many vertical markets is the long-term low-risk choice. This is predicated on the notion that large ERP vendors enjoy economies of scale. This was once true before the era of massive acquisitions where large ERP vendors need thousands of engineers maintaining hundreds of software projects on numerous technology platforms. And, it was true before the economies of scale enjoyed by open source eliminates the vast majority of the middleware burden on Independent Software Vendors (ISVs) like FreeBalance.
It also means that software can be optimized to a specific domain such as Government Resource Planning (GRP). This means more than features – it's about the underlying architecture, the non-functional requirements, extensibility and implementation methodology.
We've seen interest in our solutions pick up significantly in the past two years as reports of ERP and custom-developed software failures in government persist. Why?
- A software platform was developed by FreeBalance that enables custom development of government applications by leveraging reusable business objects
- An extensive software suite for government was developed that meets a broad range of Public Financial Management (PFM) that requires limited (if any) customization
- A methodology to improve success rates in government was developed
- Products and processes continue to improve through learning with customer implementations when the manufacturer is involved in the governance structure on all projects
Latest posts by Doug Hadden (see all)
- The (IT) Project was a Success, but the Patient Died [Part 2] - September 21, 2016
- The (IT) Project was a Success, but the Patient Died [Part 1] - September 20, 2016
- Have we over-complicated the ‘smart’ in smart government? - September 8, 2016
- Why PFM reform is integral to smart government - September 8, 2016