Back to TopBack to Top
 

PFM Knowledge Sharing, Part 4: IFMIS Acquisition Practices

 

March 5, 2009

Doug Hadden

This is part 4 of the 9 part series on PFM knowledge sharing.

FreeBalance provides a Commercial Off-the-Shelf (COTS) IFMIS suite that is used in many countries around the world. We hope that the following is sufficiently objective to be of value to you.

Acquiring financial management systems for government is a complex process. Experts suggest that effort during the preparation stage are rewarded by more effective implementations. Preparing to acquire (buy) or develop (build) a government financial management system requires identifying key needs. Many implementations fail to meet objectives because too many “nice to have” functions were identified.

Generating political will for modernization was discussed by conference presenters. Project communications should focus on all important stakeholders including politicians.

Experts recommended that governments should identify the total long-term costs for the IFMIS acquisition.

“One size does not fit all” was a constant theme in conferences. Country contexts differ. Objectives for reform and human capacity differ. Most observers believe that governments should acquire Commercial Off-the-Shelf (COTS) software. Nevertheless, there were many instances where building a solution could be the best option.

Notes

  • Functional specification should be down as part of the RFP, after re-engineering. (Farooq)
  • Best predictor of implementation success is good procurement practices. (Vickland)
  • Need to define success at the beginning. What is the desired outcome? (Vickland)
  • Should invite vendors to present ahead of time. (Vickland)
  • Must not tell vendors “how” to do the work. (Vickland)
  • A long procurement process. Real work begins after acquisition. Most IFMIS projects to some extent fail – the majority according to the web. (Parry)
  • The bigger, the broader the FMIS implementation – the bigger the risk. Governments should avoid the “shopping basket” approach of trying to buy everything.  Many FMIS implementations have proven to be unsuccessful and not sustainable. Major problems include cost (on-going and maintenance), organizational (training, capacity), system decision (inadequacies shown as system grows). (Parry)
  • Should always ask if it is the right product at the right time. Should focus on simple and sustainable. Yet, there is pressure to build it big. (Parry)
  • There has been a tradition of describing a standard series of elements that are essential to public financial management reform. These elements include medium term expenditure frameworks, financial management system implementation, program and performance budgeting. Not enough has been done to determine if these are the right reforms for addressing the problems that a country faces. It is vital that the country is prepared and understands the problems it is trying to solve and the results it is seeking through PFM reform. Equally important, is understanding the capacity of the country to embark upon and then sustain the change. For example, if the country is struggling with implementing a single treasury account, it is probably not ready to embrace program budgeting. What is apparent is that it is critical to get the basics in place first, to not embark on too much reform at the same time and to set a realistic timeframe for introducing change. (Dorotinsky)
  • “One size does not fit all”. In particular, the approach to decentralization, accrual accounting, budget management and financial management information systems need to be tailored to the country context. There was an inadequate amount of time associated with design in failures – that’s why there were component changes – required mid implementation changes. Example: in Ghana where they tried to do IFMIS, MTEF and Payroll all at the same time. (Dorotinsky)
  • The tangible benefits of the system must be explained – not just technical, but how the people of the country – the constituents – be affected. Such as saving money? This is a strong statement. Technicians need to become politicians. Negatives must be provided up front including ways to mitigate it – such as knowing that there will be downsized – which becomes a political issue (bad). Very useful to involve 3rd parties – civil society. If a person from chamber of commerce, church – could endorse the system, removes the system from the political system – has independent support. (Dr. Cort)
  • Political will is required for reform. Reform is often thought to be a problem of supply. In reality, there needs to be the creation of demand. Reform and modernization is not just about generated reports, it is about monitoring and evaluation. (Alvarez)
  • The Cabinet must be committed. Must be coordinated and leading. (Sottie)
  • Need to define the current and desired states and the “concept of operations”. (Vickland)
  • Need to calculate all design, development and on-going costs. (Osler)
  • Feasibility study should determine the roll out schedule. (Osler)
  • Take the time for a conceptual framework, strategy, cost estimates for initial training etc. ore sweat now less blood later. (Myers)
  • Need to define what is mandatory for vendors. (Vickland)

Most governments buy rather than build (Osler)

Build or buy? (Pessoa):

Parameter

Buy

Make

Development Period

Immediate

At least 1 year

Adaptability

50 to 75%

100%

Cost ownership

Initial license costs may be high. Maintenance fees also.

No license required. If creation of IT necessary, high cost. Delays cost.

Source Ownership

Vendor

Client

Maintenance and Upgrades

Available, but subject to cost

Maintenance yes, but usually no upgrades.

Documentation and Training

Documents are available for evaluation. Training package readily available.

Documentation (if any) and training only at end of the development cycle.

Software evaluation

Can be tested before buying

No evaluation before development.

Performance

Stable

Needs constant troubleshooting and debugging

Integration with other systems

Limited

Integration parameters can be included at the design stage

Flexibility

Limited

High

There was a debate between off-the-shelf vs. buy at the Community of Practise. Series of issues that one needs to walk through to determine whether make vs. buy: (Dorotinsky)

  • Development period
  • Functionality
  • Compliance with BPR
  • Total Cost of Ownership (TCO)
  • Intellectual Property Right (IPR)
  • Flexibility
  • Integration with existing systems and modules
  • Performance and quality
  • Documentation and Training
  • Software Evaluation
  • Legal redress
  • TCO should include the training of IT staff and loss of that staff. Customized system often hard wire existing practices. Perhaps should have a simple custom system in preparation for an off-the-shelf system. Have seen some systems up in post-conflict countries in less than 3 months. In Ukraine, the custom software house budget software broke two weeks before the budget was due. Conclusion: there is no one right answer for build vs. buy.
  • Government accounting is similar among countries. (Osler)
  • High degree of success in post-conflict countries. (Symansky)
  • Examples of failed large ERP projects in government were cited.
  • Customization of code makes ERP implementations as complex or more complex as build. (Dorsey)
  • Commercial-off-the-shelf (COTS) software requires a big IT infrastructure. (Dorsey)
  • View in Africa that most COTS projects have failed. (Peterson)
  • Accrual accounting functions in the COTS software should not drive introduction of accrual accounting. (Peterson)
  • Rarely, if ever, is a pure COTS – requires customization. (Peterson)
  • “Innocent are fired and the guilty are promoted and rewarded.” (Vickland)
  • Enterprise Resource Planning systems. Have not implemented ERP well. Has procured ERP in sub-optimal fashions. (Libby)
  • IFMIS has been implemented in Africa with different levels of success. (Sottie)
  • Interim functionality, small number of users with limited functionality is a candidate for build. (Osler)
  • Building a solution is usually more expensive. (Osler)
  • Build projects are often over budget and not on time. (Osler)
  • Understanding of government functions by the technology staff in developing the solution is limited. (Osler)
  • Limited controls built into build systems. (Osler)
  • Future requirements not or ill considered so system has limited capability to expand, accommodate needed changes or integrate with other systems. (Osler)
  • Testing not always adequate so many problems upon implementation. (Osler)
  • Can have weak design and poor controls. (Kamaray)

References

The following two tabs change content below.
Doug Hadden
My Twitter profileMy LinkedIn profile

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.

Leave a Reply