Why Choose the FreeBalance GRP Solution?
This is part 2 of 3 posts:
- Why are GRP FMIS Implementations Different?
- What Does FreeBalance Do Differently?
- Practical Advice on 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. Government Resource Planning software, like the FreeBalance Accountability Suite™, is enterprise-class software designed exclusively for governments.
Government FMIS projects are transformational. They are not just a back-office technical initiative. FMIS projects transform the way a government is run. The implementation of sound Public Financial Management (PFM) practices often requires both legal reforms and the restructuring of government organizations.
Common Challenges in FMIS Implementations
- 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 comes with high transformation risk but also high transformation rewards. PFM reform supported by government digital transformation provides many benefits including:
- Transparency and accountability to reduce fraud (USAID) and corruption (U4)
- Improved allocation of budgets (World Bank)
- Improved spending efficiency and effectiveness (World Bank)
- More credible budgets (U4) and (IBP)
- Improved fiscal discipline (PEFA Secretariat)
What are the Benefits of FreeBalance’s GRP Software?
FreeBalance’s exclusive focus on PFM has enabled the company to fully understand the transformational promise of a government FMIS. As a result our GRP software and implementation methodology are designed to optimize the transformational benefits while minimizing risks.
What Makes FreeBalance’s GRP Implementations Different (and Better)?
FreeBalance’s global GRP implementations differ from traditional approaches in three key ways:
- Project Governance: As FreeBalance acts as both the software provider and implementation partner, we are accountable for both the product fit and project success
- Glocal: Our commitment to building local teams mean that we are able to offer customer governments optimal costs and improved government-specific effectiveness by combining FreeBalance international and local project staff
- Sustainability: A FreeBalance solution offers affordability across many years which provides fiscal sustainability. Our progressive activation approach means that the FMIS can easily be adapted to support future modernization which contributes to the sustainability of the PFM reform initiative.
Many providers of FMIS solutions, who do not have government resource planning software, often claim similar benefits. Below is our analysis of the key differentiators in FMIS implementations:
- Traditional Approach:
- Legacy, or traditional, approach to FMIS implementations
- Bespoke Context:
- Reasoning for the legacy approach to 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 for government resource planning
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
Read: Practical Advice on Optimizing your GRP Project
Bespoke Context
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.
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 do they validate the ability to manage projects within government with so many stakeholders
Risk levels are far higher in bespoke projects than Commercial-Off-The-Shelf (COTS) projects. For example, refactoring when specifications are found to be inaccurate, poor product quality given the lack of testing compared to commercial options, and difficulties to engineer for future change.
ERP Context
ERP manufacturers are rarely part of FMIS project implementation governance structures. Governments deal directly with systems integration firms that 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 sector. Public sector functionality has been added to these product suites. Code customization will be required for a FMIS implementation 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.
The 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.
The 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
Read: ERP Failures in Government
GRP Context
GRP implementations almost always include the manufacturer as part of the governance structure. Therefore, the project benefits from the combined product and domain knowledge of GRP providers. However, the practice of using waterfall project governance can be a constraint. GRP applications are highly configurable meaning that most design documentation is useless when functionality can be demonstrated in workshops. Imposing waterfall practices results in all of the problems associated with ERP implementations except that the configuration and customization phase is much faster.
FreeBalance Approach
In FreeBalance’s implementations, our incentives are aligned with our government customers. Vendor accountability is improved when the GRP manufacturer is also involved in implementation and is part of the governance structure.
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 are 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
Custom-developed or “bespoke” projects are complex. Requirements and specifications need to be thoroughly developed and technology platforms need to be selected. Therefore, significant technology skills are required covering architecture, design, documentation, development environments, programming, code standards, code reviews, testing, quality assurance, and release (some of these elements can be certified). And all of this needs to be 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 those 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.
The practice of using 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
ERP implementations are complex and require the full understanding of requirements to eliminate unneeded private sector functionality while developing specifications for customized code. Systems integrators, rather than ERP manufacturers, provide code customization. Therefore, significant ERP product and customization knowledge is required, including software development good practices, along 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.
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
GRP implementations require limited code customization because these systems are highly configurable. Therefore, a solid understanding of PFM is most important. However, 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
There is reason why FreeBalance’s government customers enjoy better success rates than alternatives. In fact, there are four reasons:
- FreeBalance development commits to any customized code in the core FreeBalance Accountability Suite™ – this code is fully supported (rather than “orphan” code developed by systems integrators).
- FreeBalance’s international, multicultural team kicks off projects in country, leveraging experience in similar countries. FreeBalance then 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 perspectives. This staff takes more responsibility throughout the project, and provides post-implementation sustainable support. A by-product 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. However, 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
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.
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.
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. Some financial applications require tight metadata, controls and reporting integration which causes errors, introduces manual processes, enables fraud = challenges financial sustainability
- Legal reform in one finance domain almost always requires changes in other finance domains = challenges reform sustainability
ERP Context
ERP systems are highly complex to maintain. Significant training is required for users and administrators, particularly for those who manage customized code. Governments often need to build 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 within government otherwise external consultants will be required for operational and advisory functions.
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 external consultants to be hired = challenges financial sustainability
- These employees often lack the PFM knowledge required to support reform, and integration = challenges reform sustainability
GRP Context
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 which enables financial sustainability. At the same time reform is progressively activated which enables reform sustainability. However, governments often set up unnecessary GRP support organizations that reflect the needs of the bespoke or ERP context. In reality, GRP does not require significant overhead.
FreeBalance Approach
Product sustainability is our mission as a purpose-driven company. We exist to improve the lives of citizens around the world through PFM reform that matters. 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 The FreeBalance Academy certifications, 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
To find out more about the benefits of FreeBalance’s software, please get in touch.