Back to TopBack to Top

Mitigating Risks in Government Resource Planning / Government Financial Management Systems


July 10, 2013

What are the GRP implementation and sustainability risks?

What are the problems associated with COTS and bespoke GRP?

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?

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?

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?

Is COTS software too expensive to roll-out government-wide?

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?

  1. Leverage GRP products and platforms that enable change with a minimum of customization
  2. Reduce the burden of customization and code maintenance on the government Information Technology departments
  3. Negotiate for good license terms but with the view that TCO is the most critical factor to manage
The following two tabs change content below.
Doug Hadden

Doug Hadden

Executive Vice President, Innovation at FreeBalance
Doug is responsible for identifying new global markets, new technologies and trends, and new and enhanced internal processes. Doug leads a cross-functional international team that is responsible for developing product prototypes and innovative go-to-market strategies.

Comments are closed.