July 10, 2013Doug Hadden
What are the GRP implementation and sustainability risks?
The quality of public financial management (PFM) systems is a key determinant of government effectiveness. The capacity to direct, manage and track public spending allows governments to pursue their national objectives and account for the use of public resources and donor funds.
Governments are increasingly adopting Commercial-Off-the-Shelf (COTS) software to replace legacy and custom-developed software applications for financial, budget, expenditure, tax, treasury and civil service management.
Government organizations can chose to acquire Enterprise Resource Planning (ERP)software from large software firms whose software is used in multiple “vertical” markets or Government Resource Planning (GRP) software designed exclusively for governments in the COTS category.
There is a need for organizations that provide PFM products and services to help governments overcome risk factors.
What are the problems associated with COTS and bespoke GRP?
- Research shows that there is significant risk of cost overruns, late delivery, poor Total Cost of Ownership (TCO), payment problems and failure to meet objectives in COTS software for PFM
- Bespoke systems often go over budget and seldom get delivered on time. They require established skill sets in custom software development and—expertise that is often difficult to find in less developed markets
- COTS software includes features provided to support other customers and have commercial quality assurance processes resulting in significant “out of the box” functionality and higher quality that should have a better value proposition than custom developed code
- There is significant evidence that IT projects, whether custom or COTS, experience higher failure rates in the public sector than the private sector
- The evidence shows that government organizations that chose to acquire Enterprise Resource Planning (ERP) COTS software from large software firms whose software is used in multiple “vertical” markets tend to experience similar risks to acquiring custom-developed software
- The acquisition of Government Resource Planning (GRP) software designed exclusively for governments includes the COTS benefits with the ability to meet requirements that are often satisfied through custom-developed software
How are systems adapted to meet government requirements?
Custom-Developed or Bespoke Software
- Software is developed from “scratch” using software programming
- Specifications are developed that articulate government needs
- Software architecture is created including the development of logic and data models
- Software code customization including programming languages and scripting languages are used
- Development tools such as Computer Aided Software Engineering (CASE) or Business Process Management (BPM) are used
COTS ERP Software
- Configuration tools and vertical market “quick starts” are used
- There is usually a method to adapt user screens and basic business rules
- Specifications are developed that articulate government needs
- Software architecture is included in the ERP
- Logic and data models are extended to meet unique government needs
- Change management tools are used to identify the difference between the off-the-shelf and needed functionality
- BPM and business rule engines are often used, where some scripting or software code could be imposed, scripting languages are sometime used
- Call-outs to custom-developed code is often used
- Software code customization is required
COTS GRP Software
- With focus on a single market, GRP software provides a broad range of configuration options for business rules and workflow
- There is usually a method to adapt user screens
- Software architecture is included in the GRP
- Logic and data models to suit government requirements are included with methods to extend these with little or no development
- Scripting and code customization is often required for legacy integration
- Vast majority of unique requirements are supported out-of-the-box without any software code use
- Software code customization is available, but rarely necessary
How do governments mitigate risk in GRP projects?
- It is considered a good practice to ensure that the COTS software manufacturer is part of project governance to ensure commitment to meet government needs
- COTS manufacturers place software source code in escrow
- Governments receive source code for all COTS customizations and bespoke development created by consultancies
How does access to source code reduce government risk?
- Access to software source code provides limited risk mitigation to governments because the code is often complex and difficult to use or adapt
- Governments that have access to bespoke code are rarely able to adapt to meet changing reform needs
What source code elements do governments receive from vendors?
- Governments do not receive source code for physical device firmware, middleware or platforms from vendors except under open source licenses
- Application platforms include specialized components for reuse such as business objects
- Technical platform include middleware, programing languages and engines such as workflow
- Government receive source code for configuration, custom development (including integration, reporting, custom application extensions) help and documentation as part of contracts or part of escrow agreements
What are the risks of custom developed GRP?
- Building a solution is usually more expensive over the life of the project
- Build projects are often over budget and not on time
- Understanding of government functions by the technology staff in developing the solution is limited and there is often a lack of knowledge of how systems work elsewhere and lack of visibility for future needs so systems have limited capability to expand, accommodate needed changes or integrate with other systems
- This custom approach has been known, in some circumstances, to encourage poorer practices including limited controls built into build systems, can have weak design and poor controls
- The government assumes all the risk related to quality, performance and reliability and testing not always adequate upon implementation
- Difficulty to integrate among multiple bespoke systems is a significant risk
How does choice of GRP software affect the TCO?
- Adaptability: code customization (including software code, call-outs, scripting) costs more than configuration for implementation and significantly more for software upgrades because customized code has to be maintained.
- Footprint: hardware and bandwidth footprint including replication services can add significantly to space, equipment and electricity costs.
- Leverage: importance of the government market to the software manufacturer is critical to ensuring that product upgrades meet emerging needs otherwise customization costs increase year over year.
- Governance: many GRP projects create governance structures with Systems Integration firms but without the software manufacturer. This reduces the manufacturer commitment to meet government needs over time.
What is the adaptability problem in government?
- Ease of adapting software to meet changing reform needs and government modernization differs significantly among COTS software solutions while bespoke systems are notoriously difficult to adapt
- Governments cannot implement many process changes without legal reform. So, updating process to support accrual accounting, electronic signatures on cheques, HR recruitment or digital signatures requires legislative approval.
- Government undergo organizational changes frequently. That’s because there isn’t a fundamental agreed structure in government like there is in the private sector. Ministries are split up or consolidated.
- Private companies can acquire other companies. New management can perform an organizational shake-up. After elections, though, there are sweeping management changes that ranges from Cabinet (as in the Westminster system), to Cabinet plus top public service positions (as in the United States) to comprehensive changes down to management. Shake-up is de rigeur in government because you’re not elected to replace the incumbent government to keep the status quo.
- An Information Week 2012 Enterprise Applications Survey found upgrading, optimizing and changing processes to be significant barriers to success and very time consuming in Enterprise Software because of code customization
- Upgrade costs associated with moving to newer software versions. This includes change management to ensure that any customization accomplished in the previous version is added to the next, with full acceptance testing
Is COTS software too expensive to roll-out government-wide?
- Many governments are concerned about the cost of software licenses when implementing government-wide GRP
- Vendors often have confusing software pricing methods and long-term maintenance contracts that can increase initial costs significantly. Poor licensing and pricing decisions incur long-term cost burdens.
- There is a movement to supporting value-based methods of software licensing where the price is based on the customer’s perceived value of the benefits received. Pricing methodologies tend to change as markets become more mature.
- The initial cost for enterprise software may not reflect the overall cost or Total Cost of Ownership(TCO) experienced by government organizations. The software total cost of owernship have become far more important, and questioning software value has become a requisite business practice.
- Some vendors provide value options to governments that include site and enterprise unlimited contracts, concurrent user and user profile licenses designed for government environments that reduces long term software costs. Some license methodologies are designed to support developing nation and emerging economy government needs.
What are the considerations in developing country governments?
Developing nation governments have lower human capacity than more developed countries. There tends to be more public servants dealing with financial transactions and fewer “power users” in developing countries. This is particularly evident when developing nation governments are looking at the cost of government-wide implementations. As a result, traditional licensing models used by enterprise software manufacturers are often unrelated to value received.
What are the acquisition, licensing and source code options available from FreeBalance?
- Acquisition: Governments can acquire one or more FreeBalance modules, special packaging of components and modules, FreeBalance application and technical platform: the FreeBalance Accountability Platform,t o enable custom development
- Meeting custom requirements: configuration, custom domains (to adjust data), custom development on the FreeBalance Accountability Platform, with the government, FreeBalance or a partner acting as the consultancy. FreeBalance will commit to adapting software to meet government needs as part of any acquisition. The use of the FreeBalance platform accelerates custom development when compared to general technical platforms because all underlying business objects used in the COTS suite are available for use.
- Source code: all source code is placed in escrow, custom development based on business objects are available to governments as part of contracts.
- Licensing: combination (based on government needs) of named users, concurrent users, user types (professional, power, data entry, approval, reporting) and enterprise-wide based on underlying components to enable flexible granular cost-effective licensing
What are good practices for reducing GRP implementation and adaptability risk?
- Leverage GRP products and platforms that enable change with a minimum of customization
- Reduce the burden of customization and code maintenance on the government Information Technology departments
- Negotiate for good license terms but with the view that TCO is the most critical factor to manage
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