32 Ways to Optimize Your Government Financial Management Information System (FMIS) Procurement

Acquire FMIS systems with modern procurement methods, and overcome acquisition dysfunction
Context: most government FMIS implementations struggle for success 

  • Over schedule
  • Over budget
  • Achieve fraction of expected benefits
  • Financially unsustainable
  • or, completely abandoned

An alternative view is that large IT projects, particularly Enterprise Resource Planning (ERP), have poor success rates, so we shouldn’t be surprised by failures in FMIS implementations
FMIS projects has additional risk factors beyond typical ERP projects:

  • Rule and workflow complexity, including unique legal reform elements
  • Post-implementation modernization and PFM reform 
  • Public Financial Management (PFM) transformation, including transparency, accountability, budget planning, public service, and accounting method reform
  • Public service incentives and change resistance
  • Human capacity

Many governments attempt to reduce risks through complex procurement processes that prefer larger vendors with the assumption that “bigger is better” despite evidence that these providers often:

  • Charge much higher than alternatives
  • Work contracts to justify additional charges
  • Create complex governance structures
  • Fail to build government capacity
  • Use international consultants with limited knowledge of the country context

We covered some of the reasons for FMIS failures in “44 Reasons why Your Government Financial Management System Failed” last year. That post covered the entire project lifecycle, starting with procurement. We’ve recently received a set of highly complex Requests for Proposals (RFPs).  
Background: as a PFM and Government Resource Planning (GRP) specialist, FreeBalance has received hundreds of LOIs, RFIs, RFQs, RFPs and ToRs. Many of these government procurement documents increase implementation risk. It’s much like a Greek tragedy: in the process of reducing failure risk, failure becomes a certainty.

Signs of FMIS procurement dysfunction

Where are the opportunities for improvement?

  1. Managing consultants who help build FMIS procurement requirements
  2. Articulating government FMIS requirements
  3. Demanding project management practices

A. Managing consultants who help build FMIS procurement requirements
When hiring external consultants to build tender requirements, recognize that:

  • 1. consultants may not have the full Public Financial Management context in your government, especially about informal practices
  • 2. consultants rely on interviewing public servants, some of whom may be resistant to change
  • 3. consultants leverage external assessments like Public Expenditure and Financial Accountability (PEFA) that may no longer be accurate
  • 4. consultants have experiences that has created preferences and prejudices that may not apply for your government
  • 5. consultants may not be familiar with different FMIS solution types that are appropriate for your government 
  • 6. consultants rarely possess PFM and Information Technology proficiency leading to contradictory requirements 
  • 7. some consultants copy requirements from other tenders that may not be appropriate for your country

B. Articulating government FMIS requirements
When designing FMIS requirements, recognize that:

  • 8. many PFM “best practices” may be inappropriate for your government – while many requirements may be anchored on inappropriate legacy processes that ought to change 
  • 9. some implementations conceive of “ripping and replacing” too many legacy systems too quickly
  • 10. many vendors may be unwilling to bid if the tender has vague requirements and when requirements are not tied to clear government objectives 
  • 11. requirements often make vendors non compliant even though these vendors can fully satisfy all underlying needs
  • 12. some changes to PFM processes require legal reform while others do not – this distinction often does not go into the design
  • 13. the level of precision and accuracy for requirements are rarely good, many needs are exposed during implementation 
  • 14. some requirements are too rigid while others are so vague that scope is not well-understood leading to high bid prices because of perceived risks 
  • 15. depth requirements often differ, with some critical public finance functions described at too high a level
  • 16. there are limits to the amount of change and reform that can be consumed by governments in set periods of time 
  • 17. your government could also suffer from reform fatigue and unable to sustain the pace of change 
  • 18. phases for PFM reform and financial systems could be out of sequence from the real government needs 
  • 19. project design sometimes leaves little room for capacity building and change management – very critical factors for government 
  • 20. existing IT infrastructures are inadequately described leading to unexpected performance and reliability problems 
  • 21. expensive middleware and proprietary systems are often preferred in the design over open systems and open source that gives government more choice
  • 22. post-implementation reform and modernization is rarely considered in tender analysis leading to FMIS that cannot support modernization 
  • 23. modularity, cloud deployability, metadata management, and extensibility are also rarely considered in tender analysis that limits flexibility to meet new requirements

C. Demanding project management methodologies
When specifying methodology and milestones, recognize that:

  • 24. most vendors have proven methodologies that will not necessarily align with that specified in a tender 
  • 25. qualified experts struggle to implement when vendor methodologies are not tuned to government and the vendor has limited knowledge in the public sector 
  • 26. government project teams are sometimes unaware of good project management practices
  • 27. “waterfall” processes and “big bang” approaches are associated with poor success rates, while “agile” processes are associated with good success rates
  • 28. inflexible contracts lead to vendors working to the contract, rather than to the true government needs
  • 29. code customization is associated with slowing time to results and increasing long-term costs or the “Total Cost of Ownership”  
  • 30. some manufacturers of Commercial-Off-The-Shelf (COTS) make inaccurate and extravagant claims about ease of adaptability with little customization
  • 31. separating expertise in silos, like treasury, procurement, software, or IT consultants often leads to silos and disconnected implementations
  • 32. the incentive for some systems integration vendors is to increase billing through unnecessary code customization or generating large amounts of documentation

Modernizing FMIS procurement

How can governments modernize procurement to improve FMIS success rates when developing Requests for Proposals (RFPs)?

  • Question FMIS procurement practices that are based on the rationale that this is “how it has always been done”
  • Retain FMIS procurement practices that drive value and reduce risk
  • Consider the following suggestions

A. Managing consultants who help build FMIS procurement requirements good practices

  • 1. consultants may not have the full Public Financial Management context in your government, especially about informal practices
    • Give consultants country-context
    • Provide documentation, particularly around informal processes
    • Favour consultants who have country experience or similar countries
  • 2. consultants rely on interviewing public servants, some of whom may be resistant to change
    • Provide avenues for consultants to engage stakeholders outside government
  • 3. consultants leverage external assessments like Public Expenditure and Financial Accountability (PEFA) that may no longer be accurate
    • Update PEFA factors on budget reliability
    • Ask questions about PEFA gaps to determine whether processes have been improved
    • Communicate any disagreements over the PEFA assessment 
  • 4. consultants have experiences that has created preferences and prejudices that may not apply for your government
    • Ensure that consultants are open to good practices
    • Articulate any  “positive deviance” practices currently used where positive outcomes are achieved by doing things uniquely
  • 5. consultants may not be familiar with different FMIS solution types that are appropriate for your government 
    • Rank consultants that have had experience with custom solutions, GRP, and ERP higher
  • 6. consultants rarely possess PFM and Information Technology proficiency leading to contradictory requirements 
    • Provide at least one government IT expert to assist external consultants
  • 7. some consultants copy requirements from other tenders that may not be appropriate for your country
    • collect RFPs from other countries to ensure that there is no copying
    • examine the quality of RFPs to benchmark consultant work

B. Articulating government FMIS requirements good practices

  • 8. many PFM “best practices” may be inappropriate for your government – while many requirements may be anchored on inappropriate legacy processes that ought to change 
    • Focus on phased reform across multiple stages where the first phases include overcoming significant gaps and implementing functionality critical to the government (planning, controls, procurement, payroll, transparency sequencing priorities differ across countries)
    • Look at improving PFM practices & adding more sophisticated FMIS processing aligned to improving capacity
  • 9. some implementations conceive of “ripping and replacing” too many legacy systems too quickly
    • Consider replacing core treasury systems first with sub-systems integration
    • Plan for gradually replacing legacy sub-systems 
  • 10. many vendors may be unwilling to bid if the tender has vague requirements and when requirements are not tied to clear government objectives 
    • FMIS systems are not just a “technical reform”, so it’s important to explain how the system will support PFM reform goals & how the PFM reform goals support development plans, avoid generic concepts like “efficiency”
    • Show willingness to provide more information when receiving clarification questions – err on providing too much
  • 11. requirements often make vendors non compliant even though these vendors can fully satisfy all underlying needs
    • Show willingness to update requirements that have specific ways to doing things
    • Bring in vendors to show solutions before starting the tender process to learn the state-of-the-art & leverage consultants to ask difficult questions
  • 12. some changes to PFM processes require legal reform while others do not – this distinction often does not go into the design
    • Use this distinction in the tender and in phased planning
    • Do not use legal reform as an impediment to implementation, configure systems to meet current legal requirements, and phase in changes when reform passes
  • 13. the level of precision and accuracy for requirements are rarely good, many needs are exposed during implementation 
    • Recognize that scope can change so build requirements for validating the “to-be” requirements
    • Focus implementations on PFM goals rather than individual requirements
  • 14. some requirements are too rigid while others are so vague that scope is not well-understood leading to high bid prices because of perceived risks 
    • Identify “gateway requirements” – those that are mandatory and tied directly with PFM reform objectives and capacity that are rated higher than others
  • 15. depth requirements often differ, with some critical public finance functions described at too high a level
    • Show willingness to provide more details when requested by vendors
  • 16. there are limits to the amount of change and reform that can be consumed by governments in set periods of time 
    • Ensure that FMIS functionality implementation pace aligns with capacity
    • Ensure that there is a dedicated government project team
  • 17. your government could also suffer from reform fatigue and unable to sustain the pace of change
    • As above, consider all in-progress reform projects to identify government project teams, users, and decision-makers
  • 18. phases for PFM reform and financial systems could be out of sequence from the real government needs 
    • Complete a country context canvas that shows where returns are most likely
    • Recognize that improving some PEFA scores (like a “D”) may not have the returns of improving a medium score (like a “C”)
  • 19. project design sometimes leaves little room for capacity building and change management – very critical factors for government 
    • Realize that governments sometimes try to control change & capacity costs that compromises project success
    • Rate vendor change & capacity plans as high, or higher, than key vendor project staff
    • Rate success in similar circumstances highly
    • Look for vendor trainers who have PFM experience
  • 20. existing IT infrastructures are inadequately described leading to unexpected performance and reliability problems 
    • Provide full infrastructure description and performance and reliability using existing software
  • 21. expensive middleware and proprietary systems are often preferred in the design over open systems and open source that gives government more choice
    • Consider specifying open source unless there is significant IT capabilities for proprietary middleware
  • 22. post-implementation reform and modernization is rarely considered in tender analysis leading to FMIS that cannot support modernization 
    • Specify the need for changes to support reform, such as changing budget classifications to support program budgeting in one phase, modified accrual in another and results-based budgeting in future phases after the implementation is complete
    • Require vendors to provide information about how governments have supported post-implementation reform
  • 23. modularity, cloud deployability, metadata management, and extensibility are also rarely considered in tender analysis that limits flexibility to meet new requirements
    • Require vendors to describe all deployable options
    • Request vendors to explain level of system modularity

C.Demanding project management methodologies good practices

  • 24. most vendors have proven methodologies that will not necessarily align with that specified in a tender 
    • Enable vendors to adapt milestones and project methods if meets overall requirements
  • 25. qualified experts struggle to implement when vendor methodologies are not tuned to government and the vendor has limited knowledge in the public sector 
    • Do not recognize vendor experience in the private sector as important
    • Look for vendors with experience is similar circumstances in government
      • PFM Scope
      • Human development
      • Population, country size
      • Special circumstances: small island states, resource-dependent, fragility, newly independent, highly decentralized etc.
      • Similar PFM practices: British/French/Spanish/Portuguese practices, current or former socialist countries etc.
  • 26. government project teams are sometimes unaware of good project management practices
    • Include methodology, project management, and change management training for government project teams as part of the requirement
  • 27. “waterfall” processes and “big bang” approaches are associated with poor success rates, while “agile” processes are associated with good success rates
    • Be willing to accept agile project management when vendors demonstrate how these are realistically achieved
    • Require vendors to explain how “quick wins” can be achieved through the project time line
    • As described in may points, use a phased approach
  • 28. inflexible contracts lead to vendors working to the contract, rather than to the true government needs
    • Require vendor reporting against objectives
  • 29. code customization is associated with slowing time to results and increasing long-term costs or the “Total Cost of Ownership”  
    • Ask vendors about functions specified in tenders that could be eliminated based on built-in features
    • Ensure bidders are clear on how software will be adapted,
      • Code customization
        • At the product core
        • For call-outs
        • For interfaces and reports
        • Using scripting languages
      • Low-code approaches (not scripting)
      • No-code approaches
        • Configuration parameters
    • Recognize that solutions that avoid code customization at the product core or use scripting languages are riskier
  • 30. some manufacturers of Commercial-Off-The-Shelf (COTS) make inaccurate and extravagant claims about ease of adaptability with little customization
    • Require the demonstration of configuration capabilities  
  • 31. separating expertise in silos, like treasury, procurement, software, or IT consultants often leads to silos and disconnected implementations
    • Look for smaller vendor teams who have cross-functional expertise
    • Look for project managers with expertise across the PFM domain
  • 32. the incentive for some systems integration vendors is to increase billing through unnecessary code customization or generating large amounts of documentation
    • Explain how code customization ideas will be handled
    • Ensure that the government project team avoids anchoring the implementation on how the old system operates (because that generates more customization requests)

The bottom line when acquiring government FMIS:

  • Enable consultants to better understand your government requirements
  • Determine what’s most important to succeed by defining high priority critical needs tied to the government and country context

Leverage implementation practices used successfully in governments that share circumstances in your country

Topics