Optimizing IFMIS Requests for Proposals
Friday, February 27th, 2009This is section 1.2 of a series of blog entries creating a Government IFMIS Technology Evaluation Guide. This includes information to assist in evaluating IFMIS options and the technology requirements for FreeBalance IFMIS implementations. These series will be combined with feedback to produce a comprehensive Technology Evaluation Guide to be published on our web site.
Introduction to Optimizing IFMIS RFPs
Formal Requests for Proposal (RFP) are required for open and transparent government. The best value to the government can be achieved through an optimal process tailored to country requirements. Many good IFMIS acquisition practices have been developed. In particular, government organizations who survey the market for Integrated Financial Management Information Systems often generate the most effective RFPs.
Best Value for Money
The lowest price does not always mean the best value to the government. The astronaut John Glenn was concerned while hurtling through space in a craft built by the “lowest compliant bidder”. Better results come when civil servants determine the value to the government of functional criteria and build this into the evaluation.
Governments use the financial proposal to determine the Total Cost of Ownership (TCO) over a period of time, typically five years. This approach builds in the foreseeable maintenance costs but is deficient in determining the real TCO to the government. The five year approach often captures the project cost from a donor grant and does not include other costs to the government. Nor does this approach reflect the sustainability of the system past five years. This can be important because many whole of government implementations roll out to sub-national governments and small agencies in the last phase. A comprehensive TCO calculation is helpful to evaluating IFMIS sustainability.
Lessons Learned
FreeBalance participates in formal government IFMIS acquisition processes around the world. We have seen good practices that can be replicated with other governments. We have also seen many situations where major parts of formal RFPs were cut from RFPs from other countries or levels of government. This can generate risk because the country context can be completely different. Human capacity, computing infrastructure and pressing needs can be different among neighbouring countries.
Good practices to consider in RFP development are include defining core requirements well, presenting the context rather than the solution, defining flexibility, ensuring functional completeness, encouraging site visits prior to RFP release, focusing on the sequencing, defining “similar circumstances”, and determining “build” or buy prior to the RFP release.
Defining core gateway requirements
Many government requirements are important, but some are critical to success. RFPs tend to be comprehensive and can include over 100 pages of functional and technical requirements. Evaluators and vendors can get lost.
RFPs tend to have eligibility requirements for vendors. This enables some vendors to realize that they can not meet minimum requirements and should not spend money to bid on the RFP. Although it is optimal to have many vendors for competition, there is significant cost and delay to evaluate vendors who cannot meet critical needs. Therefore, identifying a key set of critical functional and technical needs can assist both the vendor and government. Approximately 5 key criteria should be chosen – no more than 10.
Difficulty with “solutioning”
Most governments have manual and computerized financial systems in operation. The IFMIS acquisition is often designed to overcome limitations of the current system. Many RFPs are written in context to the current systems. RFP authors examine this limitations or problem and determine a functional or technical solution. These solutions can be irrelevant to the vendor software. The underlying problem may not exist or the problem is solved in a different way, sometimes a better way.
The notion of requiring vendors to support the functional and technical solutions in an RFP is known in the industry as “solutioning”. Many times, the solution proposed by the government is the best alternative. Civil servants who are close to the problem often understand system limitations best. Nevertheless, compliance with any requirement should meet overcoming the problem. It is often best for the proposal to describe the limitation with a proposed solution. The vendor can describe how that limitation has been tackled in the past.
System flexibility and progressive activation
Many RFPs are designed with the notion that the IFMIS will provide the desired future end state. Yet, governments are always reforming processes meaning that IFMIS software needs to support modernization in a progressive manner.
Some RFPs recognize the need for flexibility and require full customization capabilities. This is an example of “solutioning”. Software designed for government can be configured to support these changes at a lower cost and risk than customization. An RFP good practice is to identify the likely reform and request the vendor to describe how they have handled PFM reform with other customers.
Functional Completeness
IFMIS requires Information Technology (IT). Most government RFPs require a “turnkey” solution that includes the implementation services, support and maintenance, IFMIS software, middleware, computers and networks. This is a good practice because it ensures that there is a single vendor or joint venture responsible for success.
The technical specifications in RFPs are often more complete and robust than the functional IFMIS specifications. IFMIS software can usually deploy with different middleware and computer equipment. The IFMIS software design determines technology requirements. Therefore, it is best that there is some flexibility for vendors so that the best value can be provided. Technology is an enabler for software.
Functional requirements are sometimes sparse and unclear in comparison to the technical requirements. There is often the assumption that IFMIS software is generic and that there is little different among vendor solutions. This is true in some vertical markets, but not in the public sector. The number of functional requirements for the IFMIS software should normally exceed the number of technical requirements for computers, networks and middleware.
Sequencing
Phasing the roll-out of IFMIS functionality is one of the few acknowledged “best practices” in the industry. Practitioners agree that implementations should be sequenced as “small wins” rather than as a “big bang”.
The amount of functionality that can be implemented in a single phase can be determined by the capacity of the government. Nevertheless, we have seen some unrealistic “medium bang” implementation schedules. For example, implementing a financial accounting system, budget preparation, procurement and human capital functionality in the first phase is fraught with danger. It is better to identify the critical functional needs and generate implementation plans based on a number of short duration implementation of modules.
Site Visits
Governments can gain insight by visiting other country implementations and IFMIS conferences. Vendors can gain insight by site visits to the government. Many governments enable vendors to visit after the RFP has been prepared. Site visits and presentations during the formation of the requirements can be very helpful in creating an RFP that addresses the best value to the government.
Implementations in similar circumstances
RFPs often require vendors to list IFMIS implementations in similar circumstances. Successful implementations in governments with the same or more limitations are relevant. Vendors can often provide success stories in situations where there are less limitations. For example, the success of a city IFMIS implementation in the United States is not relevant to a whole of government implementation in Africa or Asia. Many vendors will provide “public sector” successes from NGOs, post offices or universities. Governments can define the parameters for “similar circumstances”. These parameters should not be too restrictive.
Build vs. Buy
There is an active debate among practitioners about the proper approach to IFMIS. Should the IFMIS be bought with commercial Off-the-Shelf software (COTS) or built by the government or a 3rd party. There has been a trend toward the preference for COTS. The build approach can be more appropriate for some circumstances. The build or buy approach should be determined prior to release of the RFP. This will enable the government to optimize the specifications and considerations for the preferred approach.
Missing Information
Government RFPs are most often very comprehensive. They provide an excellent overview of the government situation and objectives. On rare occasions some important information is missing:
- Government technology standards in operations such as relational database, application server or e-signature standards. Sometimes the standards are mentioned but details such as the Certificate Authority for e-signatures.
- Current business process workflow is often missing. RPFs often focus on the desired business process. Vendors can gain insight by recognizing how to migrate from the current processes.
- Capacity building is often costed out of the RFP. The winning vendor must deliver a solution based on a fixed cost. Many governments and vendors try to reduce the proposal costs by reducing the training component. Comprehensive and continuous training makes IFMIS systems sustainable. Vendors should be asked how they will build capacity and ensure government self-sufficiency.
Alternatives
Governments can consider alternatives that can improve success rates while reducing costs. These include:
- 2-Stage Process. The 2 stage process begins with a Request for Information (RFI) that generates a short list of qualified vendors. Vendors require demonstrating their system in order to be eligible for the RFP.
- Contracting prototypes. Vendors can be paid to produce a small prototype. This can generate more information to the government to prepare an effective RFP and to eliminate unqualified vendors. This will enable the government to experience the vendor products and services in a real situation.
- Alternative acquisition strategies. Governments can consider software rental, Software-as-a-Service (SaaS) and performance contracts as methods to generate best value.
