Government of Canada's HR & Payroll: Will an Open, Two-Way Conversation Take Place?

A bitter principle follows titanic projects - when they fail, they fail in titanic proportions.

At the time of Canada’s Auditor General 2017 report - Phoenix Pay Problems - 49,000 public service employees were waiting for payroll. They had been waiting for over a year.

One thought runs through every industry CEOs mind, even if few say it openly, when they hear about $520 million in outstanding pay. “If this happened to us, my name, let alone the business, would be immediately buried.” Set aside the lawsuits and CRA fines for a moment. Employee trust, hard-won credibility, accounting transparency - all fly out the window. As someone who has been running a Canadian payroll services and software firm since 2015, I can attest to this.

While there may be many blameworthy contenders, there’s also one clear culprit responsible for the mess - something very familiar to all professionals in the technology sector.

I’m talking about ad-hoc design and the resulting technical bloat.

It looks as though some headway is being made to address this problem. Treasury Board President Scott Brison stated that the old ways of doing procurement - 250-page RFPs - are in the past. That the Government of Canada is going agile. This should be welcome news to vendors and tech industry leaders.

However, based on the conversations industry and the GoC have had so far, it’s becoming a little worrying that actions don’t match the rhetoric. One can imagine a phoenix rearing its head out of yet-unsettled ashes, if you will.

What It Means to be Agile, From an Industry Standpoint

It seems that the GoC has every incentive to be agile.

The issue is that it hasn’t given any realistic incentives for agile development to potential vendors.

There are very specific reasons why tech firms adopt “agile” methodologies. We can roughly sum up being “agile” as quickly prototyping solutions, deploying them, testing them, and iterating on the results.

But that still doesn’t explain why companies choose to do this.

The simple reason is that staying agile helps you find and validate markets quickly. In other words, agility promises a faster path to revenue when you don’t yet have an obvious way to get there.

Anyone in the tech sector is very familiar with this concept - think MVPs (minimum viable products).

The thing about agile methodologies is that you need to have scale for them to be truly useful.

Your ultimate test is whether someone is willing to pay for what you’ve created. So it’s imperative you have a large enough potential market to properly test who actually finds your product valuable, and how many of those potential buyers exist.

So what happens when you have a total potential market of just 1?

Well, there is simply little point in being truly agile. Sure, you might iterate on things like user experience or various features - but with potential revenue tied to just a single entity, you're risking time and development costs, and putting them all in one basket.

The GoCs approach now is to “allow vendors to build prototypes that will show the government what they can do.”

To put the questions bluntly - why would they?

To Build a Prototype You Need to Know What It's For

But let’s suppose that multiple vendors decide to take on undistributed risks, sacrifice resources, and build prototypes anyway.

How do you build said prototype when you’re in the dark about the exact issue your prototype is supposed to address?

So far, the GoC has released no concrete, actionable information about the requirements of its various payroll and HR processes.

The best we’ve gotten is a request for information that contains the following explanation regarding the 1.3 million annual processing requests made to the GoC’s Pay Centre: “The complexity of the manual processing varies from low level, repeatable transaction processing to higher complexity transactions that have decision points within them that alter the processing activities.”

This is the entirety of details provided.

It’s tempting to respond to this RFI by simply linking Knit’s feature page and nothing more.

On paper, saying that 250-page RFPs are a thing of the past sounds appealing. But what actually replaces them? Many would love to see at least a two-page explanation. Perhaps a sample department, the type of payroll they would deal with, some use cases on how the backlogs occur, a handful of processes and rules that apply would. Instead, we're in the dark.

The sad reality is that this type of communication completely locks out all except those who can easily absorb the costs of navigating an opaque landscape.

We’re back to Phoenix and IBM.

The Costs and Benefits Of A Single System

As we learned during industry briefing, Phoenix currently services 97 organizations, which have 32 separate HR systems.

Any equivalent organization in the private sector would have to answer the following very early in the process - what exactly is gained by putting all 97 organizations under one system, and what would that system have to cost to justify those gains?

The September 19th industry day conversation focused on the next generation HR and Payroll - and the GoC’s recognition that “HR and pay are mutually dependent and don't exist in isolation.”

But let’s bring the conversation back to why it’s happening in the first place - the massive backlog of pay requests. That’s the real, urgent business problem. Before speeding into another project that puts everything on the table, why not focus all-hands-on-deck to solve the pressing issue as fast as possible?

Without further information, industry can can do little but speculate.

But being part of the industry, I can say that anyone would start by understanding exactly what causes the issues and the backlogs in the first place, and what can be done to help right now, before ever entertaining a conversation about user experience or mobile apps.

To do this effectively requires a transparent, two-way communication. Whether the GoC will be having such a conversation still strikes many of us as an open question.

The Distributed Way Forward

One idea that has floated around, albeit without the GoC giving it the attention it deserves, is that of a truly distributed approach to fixing the pay problems.

Instead of treating this as another mammoth undertaking, the GoC could task each one of the 97 organizations to go through the discovery and solution process for their own department.

This would enable a truly agile approach:

• ‍‍Vendors could communicate with departments directly and understand their needs fully.
• Each department could implement a solution that meets their needs without additional bloat.
• The risks for errors would be distributed instead of having a single point of system failure.
• Many more vendors would have a very high incentive to propose solutions and stand a chance of winning.
• The costs would drastically reduce, since only the stakeholders actually affected by the problems would be tasked with solving them.
  

We can only speculate about the possible barriers to taking this route.

But for the sake of all affected, and as someone who deeply cares about the role of technology in payroll and HR very deeply, I hope that the Government of Canada finds a speedy and effective way out of this.

— Elliot Ngai, CEO at Knit People