June 22, 2016Doug Hadden
Yet more disappointing results from government technology shared services – this time: Canada. Delays in implementing government-wide e-mail has resulted in an independent review process at Shared Services Canada. Meanwhile, the roll-out of a leading ERP vendor payroll system has resulted in underpaying many public servants. The decisions by government officials to achieve savings through technology standardization and sharing makes perfect sense. The implementation of these ideas had all the characteristics of a Greek tragedy: the strategy to reduce the risk of failure resulted in tactics that ensured problems.
This isn’t the first government shared services failure and likely not the last. Don’t get me wrong, I’m not against shared services, I’m against shared services done wrong.
We have some insight into shared services because that’s how the majority of our implementations are deployed. And, we are very familiar with the situation in Canada, where we are based. Not to mention advice that we provided back in 2011.
Here are some updated “baker’s dozen” lessons learned for government leaders:
1. Shared Services Vendor rather than Demand-Driven
The primary advocates for shared services in government are large systems integrators and enterprise software firms. That’s a warning sign. Large vendors see shared services as a way to dislodge incumbent vendors. In other words, the benefits of consolidating technology and standardizing enterprise software often accrues more to vendors than governments. (See item 2)
2. A Compelling Rationale Doesn’t Make a Business Case
It is logical to think consolidating technology can save money. That makes for a suspected business case. A real business case requires realistic costs for acquisition, conversion, retraining, and change management. Not every aspect of technology consolidation will have a positive financial outcome. For example, standardizing on more complex software may add significant costs to smaller government organizations.
3. Hubris is no Way to Run a Project
There seems to be a pattern in shared services failures: the more confident that government officials are that they will avoid problems, the more likely they will generate problems. We need to learn from the success and failures from around the world. It’s not a question of whether problems will be encountered. It’s a certainty. Governments need a risk management plan that monitors and mitigates risks.
4. You Can’t Reduce Eliminate Risk through Clever Contracting
Governments try to use contract provisions in order to reduce implementation risk. There can be penalties to vendors for late delivery. (Mind you, this doesn’t stop vendors from using the legal system to blame governments for any delays). In other words, charging vendors doesn’t eliminate the risk of IT failures like the inability to pay public servants properly.
5. From Rust to Legacy
The need to replace ancient equipment in order to reduce technical debt is an impetus for shared services. We all recognize that software operating on floppy disks and 8-bit computers is risky. Yet, many governments seek to replace very old systems with old systems – from super legacy to legacy. It makes no sense to modernize to 1990’s technology – web-wrapped client/server and proprietary systems. This is what the Gartner Group calls legacy. In other words, it’s a matter of years before the software chosen for shared services needs replacement.
6. It’s not about Technology, it’s about Organizational Change Management
Very few users buy into major technology changes. The bigger the change, the larger the change management burden and the higher the perception of job loss or massive job change. Yet, many who lead government implementations seem to assume everyone will fall into line, because they must.
7. Don’t Waste the Shared Services Transformation Opportunity
Many see shared services as primarily a cost reduction tactic. The ROI can be long in common and relatively low because of all of the upfront costs. Yet, the return on transformation can be significant (if point 9 is considered). The return on organizational change management cost can be optimized when re-envisioning government processes.
8. Diminished Returns to Standardization
Standardization of processes, technology and software is touted as an advantage of shared services. Many processes in government can be standardized. Other processes are either unique by law (see point 9), or requires adding complexity that is not required. Many enterprise software applications are much harder to use, administrate and integrate compared to many that are in use in governments today. It is often more expensive to administrate a suite of software from a major vendor than multiple “best of breed” applications.
9. Best Practices often Aren’t
Another rationale for shared services is to implement “best practices” across governments. These “best practices” are often not “best”, just what the application provides – and, not best in the government context. There are often legal and mandate differences (see point 10). For example, accrual accounting is considered a best practice, but may not be legal or desirable. In another example, the best practice for military procurement is not the best practice for all procurement.
10. Everyone is Unique, Some more Unique than Others
Every government organization is unique in some way. “Lines of business,” budgets and organizational size differ significantly. Many organizational units have legal obligations. This makes broad standardization difficult. Therefore, the creation of shared services for similar organizations makes sense: municipalities within a province, public security organizations, or independent commissions. It also makes more sense to standardize non-core functions.
11. From Optional to Mandatory Shared Services
Many governments have optional shared services offerings. The number of government organizations that elect to acquire these services is indicative of service quality should these services become mandatory. In other words, a shared services organization that has few clients is unlikely to effectively support many clients. The result could be the inability to consolidate the low-hanging fruit of data centres and e-mail.
12. Free isn’t Free
All enterprise software vendors provide government-wide software licenses. These can be configured such that additional users do not increase license costs. These are techniques used by database, mail, document management, portal and ERP software vendors. The notion this is “free” is a typical conceptual mistake. Replacing software that you’ve already paid for doesn’t reduce cost. And, the total cost for training, consulting, support and administration for this “free” software can be significant.
13. Big isn’t Better
Many government leaders believe that risk is lower when selecting large IT vendors. That’s been a general view that “no one got fired buying…” That’s about reducing the risk for those who select technology, not the risks that governments assume. Products from very large vendors tend to be highly generalized and complex, resulting in relatively high failure rates in government, and in the private sector.
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