Signs that Toronto’s FPARS (financial control) system may be failing

The FPARS (Financial Planning, Analysis and Reporting System) system is based on a sophisticated SAP data warehouse system, and is being heavily customized by Toronto and SAP staff.

In the absence of direct access to the system, the severity of the judgement of FPARS is a judgement call. If the system falls far short of its intended goals, and of its potential, during its intended development lifespan, has it failed? If it is mired in an endless, shifting quest to achieve a dream, has it failed?

In a report dated September 12, 2008, City staff stated that “The FPARS project is scheduled to be implemented by June 2010, in time for the 2011 budget process to deliver a multi-year operating budget for the next term of Council” (see top of page 3). This did not occur.

The most recent assessment I could find is in the Financial Services Capital budget for 2019. See SAP Modernization Roadmap on page 17. It claims “Phase I” of the project was completed in May of 2015. The same report puts the cost of FPARS at about $60M “to the end of project” (see table 9 page 23; the 2017 capital budget puts it at $67.4M; the 2016 budget $69.5M — it keeps shifting). The report is vague; recent reports are vague; and multiple reports since 2008 report slippage of timetables owing to lack of resources and the size and complexity of the project. Most of the functionality of FPARS has been relegated to “Phase II” of the project (the “Enterprise Performance Management (EPM) “), for which I can find no target deadline, and which is still described in terms of future benefits.

So it seems clear that the project has encountered major delays, feature creep, and unforeseen difficulties at a large scale. Now the project appears to be on a perpetual development footing. In corporate circles I have engaged with in the past this alone would have triggered a fail assessment, leading to major concerns, and changes to the project’s organization and timeline.

1. A recent FOI request I pursued provided some insight into the deficiencies of the system. I requested matching actual figures to open data budget figures for 2016 (so that I could compare to audited numbers). I consider this to be very basic functionality of FPARS, and should have been literally a matter of configuring a query and hitting a button. Instead, it took me five months to obtain half of the information I requested (from City Divisions), with an instruction to obtain the remaining information from Agencies by approaching them individually. (We of course don’t have the time or resources for this). So even this core capability appears to have been relegated to Phase II, with no discernible timeline.

2. The Municipal Reference Model (MRM) embedded in FPARS seems to be a heavy burden. This is the aspect of FPARS that provides a “Program Model” based on activities undertaken by the City, in parallel to the Organizational model of the City. It is literally a second hierarchy of data, and among other things requires invoice data to be entered twice, including distributions. Thus a double-entry book-keeping system becomes a quadruple-entry system. This places a huge burden on staff both for time and knowledge, and strikes me as a major impediment. From a systems point of view, the MRM places a huge burden on development, as it is essentially an ontology, which is inherently difficult, and which requires ongoing systems responses to shifting perceptions of the value of classifications. In fact the original idea was to have the Program Model assemble data across Divisions and Agencies. This goal has apparently been abandoned (for now), and Activities are limited to their own organizations. I see very little difference between the organizational and activity structures. As a software developer, I am deeply concerned that these goals will not, and in fact can not, be achieved, and in the meantime impose a huge drain on development resources.

3. I asked the Executive Director of MISA whether MRM is still the standard for systems development, and his response was But if I had to get a yes or no answer to your question of whether it is still considered “best practice” by Canadian governments, I would have to say “no”. I think the reason is that it has been found to be an untenable burden on systems. Yet in spite of this Toronto perseveres. I think that equivalent functionally could be achieved through design of management reports which can apply statistical methods to accounting data captured once, as is convention, in an organizational hierarchy.

4. FPARS has a history of conflict. In the auditor general’s report on FPARS in 2013, the AG said, among other things “the working relationship between the Financial Planning Division and the Information and Technology Division has been uncooperative, challenging and unprofessional.” There are multiple other issues raised by the AG, including major change of budget from ~$8M (2006) to ~$70M. Worth a read.

5. FPARS failed to deliver on promises for basic enhancements. I submitted a request of additional budget data (so that I could create prototypes of improved budget designs). This was accepted, but never delivered. Never a good sign. Important update, November 2019. The 2019 version of the open data portal spreadsheet details of the 2019 budget includes much more detail than in previous years (~20k lines vs ~2.5k lines), and appears to be a direct response to my request (though not confirmed). This has been very helpful in creating a prototype of an improved budget design. Thanks to the City for that!

6. In addition:

- There is no sign of use of promised dashboards

- There is some anecdotal evidence that FPARS is little more than a repository for spreadsheet data

- There is some anecdotal evidence that FPARS is not at the core of budget planning and control

My own judgement is that FPARS is currently barely functional, and that there is a real risk that its proffered benefits will not, and can not, ever be realized.

Finally, here are a couple of questions which, if posed to Toronto authorities, would help clarify the current FPARS status:

How many division/agency dashboards are fully implemented and actively used?

How close is the FPARS data warehouse to automatically collecting, on a comprehensive, granular, regular basis, accounting, budget, staffing, and performance data?

Henrik Bechmann is a retired software developer. From 2015 to 2018 he was the lead of the budgetpedia.ca project. Twitter: ‘@henrikbechmann’