How to Modernize FMIS Procurement class=

How to Modernize FMIS Procurement

Posted on in Government Technology

How to Modernize FMIS Procurement to Avoid Failure

Our previous post – FMIS Procurement: A Greek Tragedy – detailed the most common problems causing failed Financial Management Information System (FMIS) procurements. In this post we provide suggestions on how to deal with each of these issues.

So, how can governments modernize procurement to improve FMIS success rates when developing Requests for Proposals (RFPs)? Our experience recommends that governments should question FMIS procurement practices that are based on the rationale that this is ‘how it has always been done’ and address ‘risky’ risk management as follows:

How to Manage External Consultants Effectively

As external consultants hired to develop FMIS RFPs may not have the full PFM 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

Given that they rely on interviewing public servants, some of whom may be resistant to change:

  • Provide avenues for consultants to engage stakeholders outside government

To overcome the problems associated with consultants using out of date or irrelevant findings in your PEFA assessments:

  • 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 

Mitigate personal bias and prejudices that may not apply for your government by:

  • Ensure that consultants are open to good practices
  • Articulate any ‘positive deviance’ practices currently used where positive outcomes are achieved by doing things uniquely

Given that not all consultants are familiar with different FMIS solution types and generally are not proficient in both PFM and IT

  • Rank consultants that have had experience with custom solutions, GRP, and ERP higher
  • Provide at least one government IT expert to assist external consultants

And lastly, overcome the risk of inappropriate tender requirements from consultants ‘copying and pasting’ from other RFPs by:

  • Collecting RFPs from other countries to ensure that there is no copying
  • Examining the quality of RFPs to benchmark consultant work

How to Best Articulate FMIS Functionality in FMIS Procurement

When specifying the desired functionality for the new government financial management software, recognize that:

Many PFM ‘best practices’ may be inappropriate for your government – while many requirements may be anchored on inappropriate legacy processes that ought to change. Therefore:

  • 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 and adding more sophisticated FMIS processing aligned to improving capacity

Some implementations ‘rip and replace’ too many legacy systems too quickly, so:

  • Consider replacing core treasury systems first with sub-systems integration
  • Plan for gradually replacing legacy sub-systems 

Many vendors may be unwilling to bid if the tender has vague requirements or requirements that are not tied to clear government objectives. To overcome this:

  • Remember that FMIS systems are not just a ‘technical reform’ so it’s important to explain how the system will support PFM reform goals and how the PFM reform goals support development plans. However, avoid generic concepts like ‘efficiency’.
  • Show willingness to provide more information when receiving clarification questions – err on providing too much

Requirements often make vendors non-compliant even though these vendors can fully satisfy all underlying needs. Be sure to:

  • 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 and leverage consultants to ask difficult questions

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

The level of precision and accuracy for requirements is rarely good and many needs are exposed during implementation. Plan for this by:

  •  Recognizing that scope can change so build requirements for validating the ‘to be’ requirements
  • Focusing implementations on PFM goals rather than individual requirements

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. Rather:

  •  Identify ‘gateway requirements’ – those that are mandatory and tied directly with PFM reform objectives and capacity that are rated higher than others

Depth requirements often differ, with some critical public finance functions described at too high a level, so:

  • Show willingness to provide more details when requested by vendors

There are limits to the amount of change and reform that can be consumed by governments in set periods of time. Your government could also suffer from reform fatigue and unable to sustain the pace of change. Therefore, governments should ensure that: 

  • FMIS functionality implementation pace aligns with capacity
  • There is a dedicated government project team
  • All ‘in-progress’ reform projects are considered to identify government project teams, users and decision-makers

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 as improving a medium score (such as a ‘C’)

Project design sometimes leaves little room for capacity building and change management – very critical factors for government. Overcome this by: 

  • Realizing that governments sometimes try to control change and capacity costs to the detriment of project success
  • Rate vendors’ change and 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

Existing IT infrastructures are inadequately described leading to unexpected performance and reliability problems. It’s thus important to:

  • Provide full infrastructure description and performance and reliability using existing software

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 are significant IT capabilities for proprietary middleware

Post-implementation reform and modernization is rarely considered in tender analysis leading to government financial management systems that cannot support modernization. Avoid this by: 

  • Specifying the need for changes to support reform, such as changing budget classifications to support program budgeting in one phase, modified accrual accounting 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

Modularity, cloud deployability, metadata management and extensibility are also rarely considered in tender analysis that limits flexibility to meet new requirements. So:

  • Require vendors to describe all deployable options
  • Request vendors to explain level of system modularity

How to Manage Differing Project Management Methodologies

When specifying methodology and milestones, recognize that:

Most vendors have proven methodologies that will not necessarily align with that specified in a tender. Therefore, governments need to:

  •  Enable vendors to adapt milestones and project methods if meets overall requirements

Qualified experts struggle to implement when vendor methodologies are not tuned to government and the vendor has limited knowledge in the public sector. Avoid this by:

  • Discounting vendor experience in the private sector  
  • Looking for vendors with public sector experience is similar circumstances  
    • 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.

Government project teams are sometimes unaware of good project management practices. It is therefore important to:

Waterfall processes and ‘big bang’ approaches are associated with poor success rates, while agile processes are associated with good success rates. Governments should:

  • 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 timeline
  • Use a phased approach

Inflexible contracts lead to vendors working to the contract, rather than to the true government needs. Rather:

  • Require vendor reporting against objectives

Code customization is associated with slowing time to results and increasing long-term costs or the Total Cost of Ownership. Be sure to:

  • 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

Some manufacturers of Commercial-Off-The-Shelf (COTS) make inaccurate and extravagant claims about ease of adaptability with little customization. To avoid this:

  • Require the demonstration of configuration capabilities  

Separating expertise in silos, like treasury, procurement, software and IT consultants often leads to silos and disconnected implementations. Governments should:

  • Look for smaller vendor teams who have cross-functional expertise
  • Look for project managers with expertise across the PFM domain

The incentive for some systems integration vendors is to increase billing through unnecessary code customization or generating large amounts of documentation. Therefore:

  • 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)

Bottom Line

The bottom line when acquiring a financial management system for government is:

  • 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

Contact