How is a FreeBalance GRP Implementation Different from Alternatives?

This is part 2 of 3 posts:

  1. Why are GRP FMIS Implementations Different
  2. How are FreeBalance GRP Implementation Different
  3. Practical Advice to Optimizing your FreeBalance GRP Project

Government Resource Planning (GRP) implementations for government Financial Management Information Systems (FMIS) differ from alternatives such as Enterprise Resource Planning (ERP) systems designed for the private sector, and bespoke systems. GRP software, like the FreeBalance Accountability Suite,  is enterprise-class software designed exclusively for governments.

Context: government FMIS projects are transformational. FMIS is not a back-office technical initiative. FMIS projects transform financial management and government organizations.

  • Human Capacity Gaps: New sophisticated software, combined with upgraded fiscal processes, can tax civil service capabilities
  • Organizational Change: Financial management automation, controls, and reporting replaces manual and legacy technology processes disrupts job requirements, hierarchical structures, and power relations – especially the use of technology to enforce accountability
  • Legal Reform Change: Public financial reform requires legal and statutory reform that further disrupts job requirements, hierarchical structures, and power relations – especially around fiscal transparency
  • Comprehensive Impact: Financial software rolls out across all government entities compounding capacity and change issues, while disrupting perceived organizational autonomy

Any government FMIS project represents high transformation risk with potentially high transformation rewards. Among the benefits achieved through PFM reform supported by software automation include:

  • Transparency and accountability to reduce fraud (USAID) and corruption (U4)
  • Improved allocation of budgets (World Bank)
  • Improved spending efficiency and effectiveness (McKinsey)
  • More credible budgets (U4) and (IBP)
  • Improved fiscal discipline (PEFA Secretariat

The FreeBalance exclusive focus on Public Financial Management enabled the company to understand this transformational promise for government FMIS. The result: software and implementation methodology designed to optimize transformational benefits while minimizing risks.

Global GRP implementations by FreeBalance differ from traditional approaches by:

  1. Governance: Accountable product fit and project success with FreeBalance as software provider and implementation partner
  2. Glocal: Optimal costs and improved government-specific effectiveness by combining FreeBalance international and local project staff
  3. Sustainability: Affordability across many years for fiscal sustainability, and ease of adaptation to support future modernization for reform sustainability

Many providers of FMIS solutions, who do not have GRP software, often claim similar benefits. Our analysis for these five differentiators is to describe:

  • Traditional Approach: legacy, or traditional, approach to FMIS approach
  • Bespoke Context: reasoning for the legacy approach for custom-developed FMIS
  • ERP Context: reasoning for the legacy approach for ERP software
  • GRP Context: reasons why GRP software enables more effective approaches
  • FreeBalance Approach: approach used by FreeBalance

1. Project Governance

Traditional Approach

Project governance structures can be very complex in FMIS implementations because of the mix of government, funder, and provider stakeholders. This structure is further complicated by differing incentives among stakeholders. 

The good practice of setting up a program management office (day-to-day management) with a project steering committee (oversight and important decisions) is usually implemented in all scenarios.

Other project governance good practices common among FMIS approaches include:

  • Ensure leadership commitment 
  • Provide dedicated government project teams authorized to make decisions
  • Engage stakeholders and user early and often
  • Recognize the transformational nature of FMIS that requires finance ministry oversight, not just technology oversight
  • Focus on outcomes rather than the project schedule, especially when new evidence is uncovered
  • Plan for change resistance and continuous capacity building

Bespoke Context

Prime Consideration: Custom-developed, or “bespoke”, projects include many considerations including the selection of technology platforms, architectures, and development methods.

  • Therefore: granular project management is required with oversight and traceability from high level requirements to individual code quality

Governments often select technology platforms for bespoke projects even when software outsourcing is contracted. In other words, there is limited flexibility for expert firms to select technologies that are more likely to succeed. 

Governments require minimum expertise from software development outsourcers and individual developers. Education, experience and recognizable certifications for software tools, quality, and project management. 

Rationale:  This practice of specifying skill levels has been considered a “best practice”. 

  • Theory: certifications validate skill levels, meaning that risk is reduced, as is the need for granular oversight
  • Reality: certifications do not validate skills in understanding unique government needs, nor validate the ability to manage projects within government with so many stakeholders; while risk levels are far higher in bespoke projects than COTS (refactoring when specifications found to inaccurate, product quality given the lack of testing compared to commercial options, difficulties to engineer for future change, etc.)

ERP Context

Prime Consideration: ERP manufacturers are rarely part of FMIS project implementation governance structures. Governments deal directly with systems integration firms who are authorized to manage projects by ERP manufacturers. Systems integrators have an incentive to add billable hours for code customization that is often unnecessary. Yet, project timeliness and maintainability are enabled by reducing customization. 

  • Therefore: project management focus on reducing code customization is critical

ERP software was developed for the private sectors. Public sector functionality has been added to these product suites. Code customization will be required because governments need legal reform to support many standard processes in ERP software. 

Governments require significant design up front for bespoke and ERP options. A “waterfall” project management approach is typically used consisting of documenting:

  • As-Is describing how public financial functions are currently processed, what software applications are used, benefits and problems
  • To-Be describing how functions will be improved, problems overcome, aspirations achieved, and recent legal reform
  • Fit-Gap describing the degree of fit with COTS software, and how gaps will be overcome through code customization
  • Software Requirements with full customization specifications

Each stage is approved using the governance structure. Agile methods for managing ERP projects is not considered a helpful practice because of the downstream negative impact of any code developed that will need refactoring.

Rationale:  This waterfall method is considered a “best practice” for any ERP implementation. 

  • Theory: requirements can be known during design, fully articulated and understood, with limited downstream changes
  • Reality: design requirements are often incorrect by not fully understanding informal processes, complex documentation is often misunderstood, and the time required to complete documentation and sign-offs increases change resistance and demands for unnecessary code customization

Governments attempt to overcome capacity constraints by hiring third party consultants to provide oversight.

Rationale: Use of PFM expert consultants to help government oversight of ERP projects is considered a “best practice”.

  • Theory: PFM consultants have experience in many similar project and understand the capabilities of ERP packages
  • Reality: Significant risk is experienced in many governments as consultants make decisions without fully understanding contexts, demand unnecessary documentation and meetings to delay projects, or attempt to increase billable hours

GRP Context

Prime Consideration: GRP implementations almost always include the manufacturer as part of the governance structure. 

  • Therefore: project benefit from the combined product and domain knowledge of GRP providers

Constraint: Project governance waterfall methods are imposed.

  • Theory: all COTS applications are similar with the same limitations, therefore rigid waterfall processes need to be imposed 
  • Reality: GRP applications are highly configurable meaning that most design documentation is useless when functionality can be demonstrated in workshops, so imposing waterfall practices results all of the problems associated with ERP implementations except that the configuration and customization phase is much faster

Constraint: GRP manufacturers should not be part of the governance structure.

  • Theory: GRP providers have incentives to limit scope 
  • Reality: GRP providers have an incentive to limit unnecessary scope, but an incentive to encourage necessary scope improvements so that products will provide more comprehensive functionality with other governments.

FreeBalance Approach

Context: Vendor accountability is improved when the GRP manufacturer is also involved in implementation and is part of the governance structure.

Government and FreeBalance incentives align. FreeBalance is committed to improving needed product functionality without incentives to drive up billable hours because of the negative impact of services revenue for software company valuations. 

The configuration nature of the FreeBalance Accountability Suite supports agile implementation. No-code configuration and low-code workflow can be adapted with no refactoring. There is no need to provide significant as-is or to-be documentation when results are fully demonstrable. Interfaces and reports can also be implemented iteratively.

More rigid processes for custom development is recommended by FreeBalance, although requirements and software change management processes remain agile.

2. Glocal Team Approach

Traditional Approach

Systems integration firms typically deliver government FMIS projects. These firms have incentives to increase billable hours. Expertise in these firms are often compartmentalized. 

Bespoke Context

Prime Consideration: Custom-developed, or “bespoke”, projects are complex. Requirements and specifications need to be developed. Technology platforms need to be selected. 

  • Therefore: significant software technology skills required covering architecture, design, documentation, development environments, programming, code standards, code reviews, testing, quality assurance, and release (some of these elements can be certified)– augmented by public finance domain knowledge

Custom-developed projects are most often developed by systems integration firms primarily using local country personnel, especially in Emerging Market and Development Economy (EMDE) countries.  The staff complement includes software developers and subject matter experts. These experts are often deeply knowledgeable about PFM in countries, but often unfamiliar with the broad range of potential future reforms. Meanwhile, software developers focus on containing scope, often “hard-coding” functionality. 

The lack of global expertise limits project success rates. Successfully implemented custom systems are rarely resilient to modernization.

Rationale:  This practice of local providers has been considered a “best practice”. 

  • Theory: local IT capacity will be built and source code is provided to the government
  • Reality: governments struggle with numerous financial software systems with different technology platforms, architectures, and metadata, while source code ownership enables future fraud, and reduces code quality for every additional customization

ERP Context

Prime Consideration: ERP implementations are complex requiring understanding full requirements to eliminate unneeded private sector functionality while developing specifications for customized code. Systems integrators, rather than ERP manufacturers, provide code customization.

  • Therefore: significant knowledge of ERP product, and customization required, including software development good practices (some elements can be certified by the ERP manufacturer), with PFM knowledge to eliminate private sector functionality

ERP systems are usually implemented by global or large regional systems integrators in (EMDE) countries. These integrators leverage global experts, often at high rates, to run projects and provide subject matter expertise. These experts include ERP specialists with limited government knowledge or government knowledge in other countries. Subject matter experts are most often familiar with PFM in more advanced countries. Large teams with silos of expertise are deployed, requiring complex project coordination.

Local resources are often used to pad out projects, develop documentation, and provide some government context. 

Rationale: The use of systems integrators for government FMIS implementations is considered a “best practice”.

  • Theory: systems integrators are “independent”, and best able to provide objective advice
  • Reality: systems integrators build vendor practices, there is no independence

GRP Context

Prime Consideration: GRP implementations require limited code customization because these systems are highly configurable. 

  • Therefore: PFM understanding is most important, products can be learned because of configuration capabilities, where any code customization (beyond interfaces and reports that do not affect the main code) is typically handled by the software manufacturer

Constraint: Project methodologies used in bespoke and ERP implementations are often imposed on GRP providers.

  • Theory: project management “best practices” should apply to any FMIS implementation regardless of solution type, beginning with a thorough design
  • Reality: standard FMIS project management practices lead to overly-customized systems, unnecessary project documentation, and increased change resistance – all of which can be avoided with GRP but not with ERP or bespoke alternatives

FreeBalance Approach

Context: there is reason why FreeBalance government customers enjoy better success rates than alternatives (based on meeting  time, scope, budget, goals and sustainability criteria)

FreeBalance development globally commits to any customized code in core FreeBalance Accountability Suite – this code is fully supported (rather than “orphan” code developed by systems integrators).

FreeBalance international global multicultural staff kicks off projects in countries, leveraging experience in similar countries.. FreeBalance hires local staff and sets up local project offices. Capacity is built for new staff, mentored by FreeBalance global experts. Local staff provide country and cultural perspective. This staff takes more responsibility throughout the project, and provides post-implementation sustainable support. A byproduct of this approach is lower costs thanks to local staff rates, and lower transportation costs.

Individual FreeBalance consultants typically have project management, product, PFM, and information technology expertise. This enables smaller and more effective teams with less project coordination overhead. 

Knowledge of similar circumstances enables FreeBalance project teams to better align to real needs because requirements provided during tendering are rarely accurate, complete, or reflect informal processes. Some project aspirations are unrealistic during project lifetimes. 

3. Sustainability

Traditional Approach

FMIS implementations are considered projects. Projects end, typically after about five years. These projects are considered “turnkey” – governments are expected to take over managing FMIS implementations. Many implementations are not sustainable by governments.

  • Financial sustainability: affordability to operate, maintain, upgrade, update, and train – a high Total Cost of Ownership (TCO)
  • Reform sustainability: adaptability to future process modernization and legal reform

Bespoke Context

Prime Consideration: Governments operate as software development organizations with product management, software engineering, and quality assurance disciplines. 

  • Therefore: product development capacity needs to be built, and key employees need to be retained

Rationale:  The creation of software development capacity in government is a recommended practice for some governments. 

  • Theory: overall costs will be reduced by avoiding onerous COTS software maintenance licenses and developing only what is necessary, while giving governments more control to support reform and modernization
  • Reality: costs to ramp up software development capacity and retain employees is most often much more expensive than leveraging COTS while compromising quality = challenge to financial sustainability; adapting source code to meet reform and modernization is often more time-consuming than reconfiguring in COTS software = challenge to reform sustainability

Bespoke core FMIS, payroll, human resources, procurement, assets, and budget planning systems in government often use different technology platforms (across numerous technology eras) and do not share metadata or controls. This compromises interoperability while adding complexity for civil servants using more than one application.

Rationale: The development of silo custom-developed applications is considered an acceptable practice.

  • Theory: silo applications align with primarily standalone functionality while supporting PFM reform in that standalone domain without much impact to other FMIS functions
  • Reality: there is no such thing as primarily standalone functionality in government financials with some financial applications requiring tight metadata, controls, and reporting integration causing errors, introducing manual processes, enabling fraud = challenges financial sustainability; while legal reform in one finance domain almost always requires changes in other finance domains = challenges reform sustainability

ERP Context

Prime Consideration: ERP systems are highly complex to maintain. Significant training is required for users and administrators, particularly for those who manage customized code. Governments often require building software engineering teams, similar to the bespoke option, at a slightly smaller scale.

ERP vendors force upgrades to new software versions. (Or, support previous software versions at higher maintenance costs.) Every upgrade requires an analysis of all custom code that may need to be changed, and any new functionality that may not be compliant with government regulations.

  • Therefore: ERP capacity needs to be built in government otherwise external consultants will be required for operational and advisory functions

Rationale: The development of government “shared services” ERP organizations with requisite capabilities needs to be built .

  • Theory: shared services organizations pool ERP capabilities for product operation, maintenance, upgrading, maintenance, and testing
  • Reality: shared services organizations experience difficulty in retaining capable employees, often requiring hiring external consultants = challenges financial sustainability; while often lacking the PFM knowledge to support reform, and integration  = challenges reform sustainability

GRP Context

Prime Consideration: GRP is far less complex than custom-developed or ERP options. GRP systems require PFM knowledge and understanding of government processes. Basic information technology skills are required to manage these systems. Configuration is the primary method to support reform and modernization 

  • Therefore: the GRP maintenance and management footprint is contained = enables financial sustainability; while reform is “progressively activated”  = enables reform sustainability

Constraint: Governments often set up GRP support organizations that reflect the needs of the bespoke or ERP context.

  • Theory: all software, regardless of type, requires similar support mechanisms, personnel, and capacity
  • Reality: GRP does not require significant overhead

FreeBalance Approach

Context: product sustainability is a FreeBalance mission as a purpose-driven company. FreeBalance supports financial and reform sustainability by:

  • Government rules, translation flexibility, additional fields, terminology, and custom help supported through parameters and configuration
  • Process workflow supported through a low-code tool
  • Fully supporting any customized code (and, making new functions available to all countries)
  • Capacity building and mentoring programs, including certifications, an online academy, custom courses, and engagement through the FreeBalance International Steering Committee to share good practices
  • Value-based pricing model making additional software licenses affordable
  • Strategic sustainability services available to augment government over short periods of time while building capacity
  • No forced upgrades, although support for the latest versions of middleware may necessitate upgrades
  • Open system and open source support providing governments with middleware choices to reduce technology costs

Topics