October 28, 2013Doug Hadden
Something known as a “fit-gap analysis” is completed as part of most government Integrated Financial Management Information System (IFMIS) projects. The analysis seeks to determine gaps between what the software currently accomplishes and what it should. This is a fundamental part of analyzing the “as is” situation that is currently in use by a government organization and the “to be” scenario that will typically leverage new software such as the FreeBalance Accountability Suite.
Governments have the choice to acquire custom developed software, Commercial Off-the-Shelf (COTS) Enterprise Resource Planning (ERP) software designed for multiple industries and Government Resource Planning (GRP) software designed exclusively for government. What is generally not well understood is the extent to which the fit gap exercise differs based on choice of solution.
The 4 Gaps
- Functional Gap: the lack of functionality built into the solution. The gap in custom-developed is 100% while the ERP gap is typically larger than the GRP gap because of the focus by ERP vendors on private sector functionality.
- Architecture Gap: ability of the solution to achieve “non functional” requirements of scalability, reliability, usability and manageability. The gap in custom-developed is 100% because the architecture needs to be defined. There can be architectural gaps in ERP and GRP software.
- Configuration Gap: where functionality exists, it should be configurable without any code customization. Custom-developed software is 100% code customized. Although ERP software supports configuration options and workflow, government implementations typically require significant software code customization including scripting, call-outs and adapting underlying code. GRP software often requires no code customization. (FreeBalance has a unique process of committing to developing any missing features and placing these into the mainline of the code to enable long-term manageability.)
- Workaround Gap: where the system needs to be circumvented by special reports, call-outs or manual workarounds. There ought to be no need for describing workarounds in custom developed projects.
The burden on the implementation team for the fit gap process differs depending on the technology solution used. The custom project might be built on existing custom software. The government functionality gap differs among ERP vendors. There are some general patterns:
- Custom development: should be managed almost as the development of COTS software with deep articulation of specifications. Project governance is critical. There is significant risk that the software will not meet long-term needs if not developed to facilitate change. There needs to be significant effort in analyzing system architecture for scale.
- ERP software: is usually scalable but has usability and other issues. The fit-gap exercise is usually one comparing gaps between the “vanilla” public sector implementation and the government need. The more customized the ERP is to provide unique needs, the more difficult the system is to manage and change. ERP government projects often take significant time because there is a need to determine whether it is best to legally change government processes to match the generic functions in the software. Some of this “business process re-engineering” requires legal reform. ERP professionals are often reluctant to try incremental changes to software over time because these suites are expensive to adapt.
- GRP software: the lack of private-sector functionality and the focus on government features reduces fit-gap risks. The process of comparing GRP with government requirements is relatively simple and fast. GRP software enables most or all functionality (outside custom reports and interfaces) to be supported through configuration. For example, FreeBalance supports parameters, workflow and custom information. This configuration method supports change, or progressive activation, by changing parameters or workflow. No software code required.
Most government IFMIS Requests for Proposal (RFPs) that I see focus primarily on functional gaps but not on how to achieve functional completeness. There is often short shrift given to architectural issues. Many governments rate “configuration” and “customization” as almost identical. What seem as nuances in RFPs are often critical factors in making systems financially sustainable.