A new pay system will mean new union deals

Can it be done? Can the federal government build a new pay system from scratch, even as it’s engaged in a herculean effort to fix a Phoenix platform that is careening out of control?

The answer, of course, is yes. This isn’t metaphysics, merely a laborious process of aligning pay rules with a computerized system for calculating what should appear on employees’ pay stubs.

But whatever path government and its unions select for rebuilding, the decision has to come quickly. The knock-on effects of Phoenix’s failed launch two years ago are accumulating and may at some point become unmanageable.

In the wake of the revelation in Tuesday’s federal budget that the government will spend $16 million over the next two years to study how to build a new pay system, it’s important to ask why Phoenix failed.

The idea behind Phoenix was to standardize pay terms and rules — for instance, who qualifies for leave, under what conditions and how should the details be entered — allowing the system to deal automatically with many requests.

Information technology experts, ones who have successfully built large pay systems, make the following points:

If you are going to build a single, centralized pay system for 300,000 government employees, involving multiple strands of federal legislation and 101 departments and agencies, then you absolutely must make the process simpler.

This is not a knock against the multitude of safeguards and clauses that have been built over decades into unions’ collective agreements. It’s just a reality.

If your objective is to produce a workable and accurate pay system as quickly as possible, there’s no real mystery about what’s required: rewrite collective agreements and streamline federal legislation. Without dramatic changes, building a new pay system will take seven years or more — two years to sort out what kind of system (custombuild, off-the-shelf ), then five years to choose a contractor (internal or private-sector), develop the detailed design and test it.

There’s another way to go, and that’s to allow federal departments to develop their own pay systems, either alone or in collaboration with others. While the same complicated pay rules would apply, there wouldn’t be as many of them — and these wouldn’t have to be standardized across so many departments and government agencies.

Also, if one department screws up, its mistakes can likely be contained.

In a more positive light, single departments can experiment to see what works. They can take advantage of cloud technologies, allowing them to quickly set up different types of payroll services and pay for them through a monthly subscription.

But even here, the government would have to streamline the way it does pay.

“There are no radically different payroll technologies (available) unless they want to outsource on the cloud and have it run externally,” said one Ontario-based expert who has spent decades installing these large software systems. “Any provider of those services would insist first on the simplification of the business and processes,” added the software designer, who did not want to be named because of work they do with the federal government.

In short, the government, unions and technology experts have some interesting choices over the next two years as they negotiate the general form a new pay system — or systems — should take.

The big government unions — Public Service Alliance of Canada and the Professional Institute of the Public Service of Canada — are not surprisingly wary about the idea of significantly altering hard-won contract language in the name of efficiency. Especially since it was a mixture of politics and bureaucratic mismanagement that produced this mess.

“Any changes to federal public service pay rules need to be negotiated during collective bargaining,” said Robyn Benson, national president of PSAC. “PSAC is willing to consider proposals from Treasury Board to simplify pay rules. However, we will not agree to any changes that would negatively affect our members.”

But incentives abound for finding common ground. A strong majority of the government’s workforce has suffered incorrect pay, with the current backlog of pay queries and transactions now topping 630,000. Complaints about Phoenix are descending on members of Parliament with relentless force.

The sooner the main players agree on an approach, the better, because there are two other potential difficulties.

First, it’s not clear there are enough payroll experts available to simultaneously fix Phoenix and develop its replacement. Nor are the skills interchangeable in the short run. Pay administrators or software designers wellversed in the Phoenix system would have to adapt their knowledge considerably in switching to a new, and hopefully much different, replacement system.

Taxpayers are financing the twin developments at a significant clip. The repair bill to date is nearly half a billion dollars, with another $431 million already committed. But most of this repair budget will be exhausted by March 31, 2019. It’s early to talk about what the replacement system for Phoenix would cost — though $300 million would be a good starting point.

Meantime, the longer it takes the extra legions of pay administrators to whittle down the Phoenix backlog, the more serious becomes a new source of pay difficulties — one involving pensions.

While the government’s administration of pension services is generally considered good, the pensions themselves are based on a formula involving salaries. During the past two years, thousands of government employees have retired. Because of the fact at least part of their pension involves salary calculations done by Phoenix, errors will emerge and these will likely have to be corrected by hand.

This is another incentive for moving quickly — but only within reason. Everyone knows a principal failing of Phoenix was that it was pressed into service too soon.

No one wants to follow up that disaster with another one.

Any provider of those services would insist first on the simplification of the business and processes.