Government Operations Committee on July 24th, 2024

[The Chair, Conservative, Kelly McCauley]

Good morning, everyone. I call this meeting to order. Welcome to meeting 133 of the House of Commons Standing Committee on Government Operations and Estimates, widely known, of course, as the mighty OGGO, the only committee that matters.

Before we start, I would just remind that you all keep your earpieces away from your microphones at all times to avoid feedback.

We're very pleased to welcome back to OGGO Professor Clarke and Mr. Boots.

We'll start with Professor Clarke with a five-minute opening statement and then we'll go to Mr. Boots.

The floor is yours, Ms. Clark. Welcome back. We're very pleased to have you back helping us.

Go ahead, please.

[Dr. Amanda Clarke, Associate Professor, School of Public Policy and Administration, Carleton University, As an Individual]

Thank you very much, Mr. Chair. It's a pleasure to be back speaking with the committee.

In 2022 our research team, which is based at Carleton University and includes both me and Mr. Boots, launched govcanadacontracts.ca, an open access research tool to help people more easily explore the Government of Canada's proactively disclosed data on federal contracting. That tool provides data on all federal contracts between 2017 and 2022, but our focus in the research paper and in the testimony that we'll give today is focusing on just the IT contracting piece specifically. I should note that the paper we're presenting and the findings are still under peer review, but we wanted to release it while that process was under way, given the urgency of the topic.

Knowing that effective IT procurement is not just key to the success of individual digital projects but is also essential to effective modern public administration more broadly, our goal with the research was to better diagnose the extent to which the Government of Canada adheres to widely accepted best practice in IT procurement. We suspected, given previous research and a fairly thick body of anecdotal evidence, that the federal government wasn't following the rules for good IT procurement, but we wanted to test that assumption with stronger data.

To do so, we turned to the proactive disclosure of contracts dataset that is published by the Government of Canada. A fair amount of work went into cleaning those data. If you're interested in that, we outline how we did that on our website and also in the paper we're presenting.

To evaluate that data—in hand, cleaned and ready to go—we created a framework looking at international experience to outline a set of sort of rules for modern public sector IT contracting. Then we assessed the extent to which the Government of Canada follows those rules. What did we find? The main punchline is that the federal government breaks almost all globally accepted best practice for modern public sector IT procurement. I'll give a high-level summary here.

First, federal IT contracts are generally too big, in terms of both length and dollar value, to succeed. That conclusion rests on a strong body of evidence showing that for software projects in particular, contracts need to be small—to allow the project to adjust based on regular and early user feedback, to avoid pooling risk and dependencies in a small number of large contracts, to make it easy to dispense with vendors that are underperforming, and to open up competition to a broad range of vendors, not just those capable of bidding for and winning large contracts. Despite all the evidence that smaller contracts are far more likely to lead to project success, we find that the majority, 53%, of IT spending in the Government of Canada is allocated to contracts that break the threshold dollar value for likely project success. That's the first big finding.

The second big finding looks at the diversity of the number of vendors winning government contracts. We know from basic economics that the more competitive and pluralistic the market, the more likely you are to have success in buying. We looked at the supplier market. We identified a small number of prominent IT vendors where three vendors received over $100 million in contracts annually, making up 23% of government IT contract spending. This is alongside a really long tail of thousands of smaller IT vendors and contractors. We note in the paper that one of the things we can't identify with the data we have is how many of those are pass-through vendors that you've been looking at in something like the ArriveCAN study.

Third, we looked to the importance of building in-house IT expertise, which is something the committee has heard several times. There are reasons that you want to build that in-house IT expertise. You can be a smart shopper. You can build in-house when it makes more sense to do so. You can kind of hold those contractors to account. We looked at the ratios for contractors to in-house staff in this part of the analysis and found that in some Government of Canada departments, the number of contracted IT workers greatly outnumbered in-house IT staff. There is nuance to explore in what that right ratio is, which I hope we can get into in our discussions.

Fourth, again breaching global best practice, in a frankly shocking betrayal of responsible stewardship of public funds, current government policies favour vendor ownership of intellectual property and data and do not prioritize adoption of open source solutions. This is despite strong evidence showing that open source generates more cost-effective, secure, publicly accountable and higher-quality digital services.

These policies on IP represent a clear recipe for ongoing lock in to vendors who produce custom software for government, reducing departments' abilities to share and reuse software, likely resulting in frequent cases in which the Government of Canada is paying for the same or comparable software multiple times over.

We conclude the paper with a series of policy recommendations, which are also detailed in a brief that we presented to the committee on an earlier occasion. We also note several limitations to our analysis, which we'd like to really get into today as well, resulting in large part from the limited data we have. For us, this is really an area that is ripe for immediate attention because, as the committee will know all too well, it's very difficult to get a clear picture of IT contracting patterns in Canada, so this research is one attempt to do that. We really look forward to discussing our research process, the findings and their implications with the committee.

[The Chair, Conservative, Kelly McCauley]

Thanks very much. I hope that, when the paper is published, we'll be able to have the two of you back to discuss it in length.

Mr. Boots, please, the floor is yours. Go ahead, sir.

[Sean Boots, Former Federal Public Servant, As an Individual]

Thanks so much, Mr. Chair.

Thanks to all of you for having me here. I think it's been about a year and a half since Professor Clarke and I were here. It's really kind of you all to invite us back to talk about the research. As Professor Clarke said, I think it dovetails well with a number of the studies this committee has undertaken—the ArriveCAN study, the McKinsey study, this study on the outsourcing of contracts. Such themes as the deskilling of public sector workers, especially IT staff, and the government's dependency on outsourcing and consultants all connect as a thread throughout each of these studies. I'm glad you're doing the work to examine this.

Professor Clarke and I have spoken here before. She gave a great overview of our research in her opening remarks. All the number crunching, if you want to go back and look at it, is on the govcanadacontracts.ca website, along with the guide to reforming IT procurement that we spoke about on the previous occasion we were here.

The research paper that's just gone in for peer review is sort of the final stage of this research. You can read the preprint version on Professor Clarke's website. We'll definitely get the final version over your way once it's published. If the preprint version seems dense—classic academia—I'd say to skip to the charts. They're pretty eye-opening. On page 24 of the paper, you'll see who the biggest players are in the federal government IT space. On page 27, setting aside things like software licensing and computer devices and telephones, you'll see the big names in specifically IT consulting services year by year, which I think is of particular interest.

I think the main take-away is that situations like ArriveCAN aren't isolated cases. We're looking at systemic issues in how the federal public service conducts IT procurement work. Looking at the research landscape and other jurisdictions, it's clear just how much Canada has fallen behind its peers. The policy recommendations we put forward at the end of the paper aren't that earth-shattering. They're basically best practices that other governments around the world have been doing for years. The question is, why haven't we made any progress on them in the Canadian federal government?

There have been some baby steps over the past year or two. This committee's work probably helped move some of those forward. There's updated guidance on procurement that isn't bad, but it's very timid. There are new attestation requirements for business owners in Treasury Board policy that take effect in September, but ultimately, the interventions we've seen from the federal government over the past year, including this latest edition from September, amount to basically “follow the rules harder”. There's a great piece from Paul Craig, who's a government technologist, on his website, Federal Field Notes, that talks about why this isn't good enough.

Here's what we haven't seen. We haven't seen fundamental changes in process, regulatory or legislative changes around procurement or efforts to make procurement simpler and easier for small companies to be part of. “Follow the rules harder” isn't a viable strategy when part of the problem is that there are too many rules. This creates a lopsided environment where the only companies that can win government contracts are ones like GC Strategies but are also really large consulting firms that specialize in navigating complicated procurement processes and in building relationships with public sector IT executives. That's what they're good at and that's why they win contracts. They don't win because they're good at building technology products, which is probably why we often have so many IT failures.

On the other hand, from the public service side, if you're a senior IT manager or a senior public service leader, going to work for a large consulting firm or IT vendor is a frequent post-retirement career strategy. That's something referred to anecdotally quite a bit. It means that no one involved is incentivized to change the system.

Ultimately, what the IT procurement system does best is shovel taxpayer money towards large, established vendors and IT consulting firms. That's what the policy on title to intellectual property arising under Crown procurement contracts calls “economic growth and job creation”, which is why vendors are supposed to own the IP for software that they create for the government. That is truly astonishing on multiple levels. Producing good software and effective government services is a secondary priority. That's a major problem. The effects of that show up years later in the frankly mediocre and unreliable government websites, software and services that we see across the federal public service today.

“Follow the rules harder” isn't going to work. What does it take instead? It takes a dramatic rethink of how procurement works, a dramatic rethink of how the public service handles tech talent and a dramatic rethink of governance processes, policies and oversight mechanisms. If you like, I can list off a whole series of examples of these in our discussion today.

Ultimately, though, I'm not confident that the federal public service is internally capable of the kinds of dramatic rethinks that are necessary. It's possible that an external independent review or some future royal commission on the public service could. If those bodies were to do their work well, most of their recommendations would involve getting rid of things—getting rid of processes, getting rid of rules and getting rid of all the barriers to doing good work in the public service, such as getting feedback, making sure you can get to decision-makers and actually learning and reacting and building things quickly enough for it to matter.

Within the federal public service, there are people doing tireless and inspiring work everywhere. I'm really grateful to have worked with many of them. They're held back by outdated processes, old technology and overly traditional ways of working.

Really, in the IT field especially, contractors and consultants don't face the same barriers, even though all those barriers are self-inflicted by the public service on its own staff.

It's easy to be a critic, especially now that I've left the federal public service and I work for a territorial jurisdiction, but ultimately what I want is for the federal public service to be excellent. It could be so much better, and Canadians in need depend on it.

I'm really happy to chat, and I'm looking forward to your questions.

Thank you so much.

[The Chair, Conservative, Kelly McCauley]

Great. Thanks, Mr. Boots, and we extend the same invitation to you. I hope we'll see you back once the paper is published. We'll have you both back, as well as the other two people from Carleton who assisted you on that. We look forward to it and sincerely appreciate you taking time to help out OGGO and Canadian taxpayers in the end.

We'll start with Mr. Brock for six minutes, please.

Go ahead, Mr. Brock.

[Larry Brock, Conservative, Brantford—Brant, ON]

Thank you, Chair.

I'd like to welcome both Professor Clarke and Mr. Boots to the government operations committee, also known as the mighty OGGO.

I'd like to frame my first round of questions to around two news articles I was able to research. One is from the National Post written by Christopher Nardi, which I understand resulted in an interview between Mr. Nardi and both you, Ms. Clarke, and Mr. Boots, as well as a Policy Options piece that both of you authored and was dated February 16, 2024.

I guess I'll start by making an obvious assumption that the ArriveCAN scam or debacle, however you want to frame it, certainly didn't come as a surprise to you, Professor Clarke, or to you, Mr. Boots.

Would that be a fair statement to make?

[Dr. Amanda Clarke]

Yeah, I think it was the premise of the Policy Options article that this is something that we should anticipate.

[Larry Brock, Conservative, Brantford—Brant, ON]

Right, and we all know what the Auditor General had to say about the whole situation. It was a clear picture of mismanagement around the app. She's guessing at the cost of the app, which we believe to be just shy of $60 million; it could be much higher, but we don't have the proper documentation. The departments were so rushed and hurried to put together the app that they did not retain proper documentation.

To you, professor, and to you, Mr. Boots, that brought to mind the challenges of improper documentation that you found in your 2022 research paper.

The first question I will put to you is based on the Policy Options piece, in which you wrote:

What should be done in response to the findings? A classic response from Ottawa to this kind of report would be to add more rules, more oversight mechanisms, and more internal processes to prevent more scandals. But following this age-old pattern will all but ensure that failures like ArriveCAN and its IT scandal predecessor Phoenix continue.

Can you elaborate on that for me, please?

[Dr. Amanda Clarke]

Yes, and this echoes a lot of what Mr. Boots offered in his opening remarks. There has been a tendency in the Government of Canada, I think historically, to layer on more rules and oversight to create new parliamentary officers, new external scrutineers when there's been some sort of scandal. While, of course, we're clearly not advocating for no rules and, in fact, the research in clean, high quality IT procurement focuses a lot on what the guardrails should be and on building a culture of responsible public service around that to avoid things like conflict of interest, for example, I think the habit we've had in Canadian public administration—layering on more rules as a way of ensuring accountability—has actually had this perverse effect of undermining accountability and seriously undermining the effectiveness of public servants.

There are tons of examples that you can find. A classic one that people loved to talk about, maybe 10 years ago, was that, when the federal government first started using social media, there were, in some cases, these 20-step approval processes to release a 140-character tweet. You can also look to the Federal Field Notes website written by Paul Craig, which Mr. Boots referenced, to find some great examples of this sort of internal administrative burden. In one case, the documentation required to publish a five-page website basically had more words than the entire edition of The Great Gatsby. We mire public servants in so many rules and compliance requirements, and the reporting burden—which is really well-documented, not just in IT but across the study of Canadian governance—that it has two effects that are relevant to this question of IT contracting.

One, it means that when it makes sense to build in-house and to try to adopt modern service design practices like user research or agile multidisciplinary teams, public servants actually can't do it. It's really difficult to do the right thing. We add so many rules that they can't be nimble enough. Streamlining those rules would, I think, create space for public servants to do some more of this work internally.

The second piece of it is that when you have those rules in place, it actually becomes difficult for vendors in some cases to work in modern ways with the federal public service because there are tight rules around things like “project gating” or the way that money flows, and that's because they can't pull together a multidisciplinary team of internal public servants because HR rules don't allow it. That's why I think the focus of this latest spotlight on the problems of IT contracting should meaningfully lead to a reset of policy with a focus on enabling good public service and a focus on what matters, which is conflict of interest and the responsible bidding processes, not creating documentation burdens for public servants. That's not going to help. In fact, it will make it worse.

[Larry Brock, Conservative, Brantford—Brant, ON]

Thank you for that thorough response.

Mr. Boots, do you have anything to add?

[Sean Boots]

To build on Professor Clarke's remarks, I think the pattern you see in a lot of public sector IT work is that if you imagine a large project that has 100 public servants working on it, 90 of them will be writing Word documents that are project management, oversight compliance reports, all sorts of things that are not actually building the software. If you have 100 people and only, maybe, five of them are actually writing software code, configuring systems, that's a really odd ratio that is very normal in public sector IT but just completely foreign if you work at Shopify, Google or another mature tech company. Trying to reduce those barriers that public servants face—oversight and compliance mechanisms that are really outdated—means that you spend less money having 90 people write meaningless Word documents and more people actually building software code.

One understated scandal of public sector IT is that it's very normal for the public service to undertake a $100-million IT project that could have been done for $10 million, or a $30-million IT project that could have been done for $2 million, and so there's this expectation that it's normal to have a $50-million IT project to build an online forum or an interactive website that could be done for a fraction of the cost.

There's some really great writing from Waldo Jaquith, who's a technologist in the United States, about how software is so much cheaper—it's not free, but it's much cheaper than public sector organizations expect—but the tendency is to say, “Oh, yeah, this project is similar to this previous project our department did. The last one was $50 million, so this one's probably $50 million or $60 million,” when a really strong team could build it for $2 million. That's tricky to dig into because it all has to do with how public servants are doing the work of IT projects, how 90 out of 100 people are just writing Word documents instead of actually building.

[The Chair, Conservative, Kelly McCauley]

Mr. Boots, I'm afraid I have to interrupt you because we're past our time, but perhaps during Mr. Jowhari's round you can continue.

Go ahead, Mr. Jowhari.

[Majid Jowhari, Liberal, Richmond Hill, ON]

Thank you, Mr. Chair.

Welcome back, Professor Clarke and Mr. Boots. It's good to have you here. Thank you for being open to sharing the paper you're preparing, which is under peer review, and thank you for acknowledging that.

Naturally, I am very interested because my background is in IT, in consulting and in delivering transformational large projects enabled by technology. I was very keen when I saw the report. I listened to your opening remarks. You focused on four key areas, and you opened up by talking about how government IT projects have been too big for too long, and you suggested they should be shorter and much smaller. Why is this the case, and what are the best practices?

[Dr. Amanda Clarke]

To understand, why is it the case that smaller is better, or why is it the case that they're so—

[Majid Jowhari, Liberal, Richmond Hill, ON]

Why is it the case with the Government of Canada? Have you looked into why the Government of Canada's projects are so big and take too long?

[Dr. Amanda Clarke]

Yes. That's such a good question.

One of the reasons public servants will often offer when explaining why contracts are so big—as Mr. Boots referred to—that there's a habituation to large-scale projects and a misperception, frankly, that we need to be spending in the tens or hundreds of millions of dollars. In some cases, I think, there are vendors that the federal government is used to turning to, and those vendors know that they can charge those amounts of money to deliver on these projects.

This gets to the question around what the rules are. Partially, the administrative burdens internally imposed on public servants to put up a request for proposals and to go through a contracting process are so high that you can be incentivized to go big because, “Well, we want to get as much money as we may need for this project, and we don't want to have to do it over and over again,” so reducing those internal burdens would be a really big driver of incentivizing smaller contracting.

[Majid Jowhari, Liberal, Richmond Hill, ON]

Yes, you talked about reducing those internal barriers.

Is it possible that they make the scope so big because the transformation that's needed is so big, after many decades of lack of investment, that the government is trying to move the needle so far to the other direction so that they believe this is a massive IT transformation they have to do? Therefore, if you're going to go...and you have only, for example, four years to do it, it's “Let's go big and complex, and let's get it done.” Is that a possibility?

[Dr. Amanda Clarke]

I think there's an intuition and a sense that it's the way to go, but the data are extremely strong, showing that software projects should really not exceed.... Well, the limits that we give in our paper, which borrows from the U.S.'s General Services Administration, the suggested rule is a maximum of $2 million U.S. per year for no more than three years, and with no extensions beyond that. The reason software projects in particular demand that small scope relative to, say, big infrastructure projects or something, is that, when you're talking about building software and services that are built out of that software, you don't really know what you need until you test early with users.

There was a shift in how we thought about software development in the private sector, with what's called the “agile manifesto”—which you can find online—and it changed how the private sector and leading public sector jurisdictions think about software projects. You start small, perhaps with many contracts at once, and you bring these vendors together, in part, because you're not pooling and making tons of unfounded assumptions about what the end product's going to be.

Now, to enable that way of contracting, you have to look at how money flows through Treasury Board and how budget submissions are done. You have to create space for public servants to get that early feedback and adjust. However, it has happened in many other jurisdictions. It's really remarkable how far behind the Government of Canada is in moving their software development practices to what is well-supported in the data in both private and public sector corporations, which is that you have to keep it small and test and adjust as you go.

[Majid Jowhari, Liberal, Richmond Hill, ON]

Personally, I understand the concept of a road map. Usually, road maps can be anywhere from two years to five years. I get that. I understand breaking that road map into much smaller projects, anywhere from six months to, probably, 12 months maximum—nine months as the average. I get that, but around the scope and the dollar value, when we're talking about $2 million, if it's an application that's going to get rolled across the government and to at least 23 or 24 departments, if you do the simple calculation, I'm not sure whether $2 million is really the right number or benchmark. What are some of the other best practices that we could probably use as benchmarks to improve our procurement processes so we don't get caught in, for example, “pass-through situations”, as you call them?

[Dr. Amanda Clarke]

I should clarify that it's not that an individual project or initiative would only cost $2 million a year over three years. We know you can't revamp and upgrade all of the benefits delivery programs, which is something currently under way for $6 million. It's that individual project components and those individual contracts shouldn't exceed those amounts.

Part of this is just that if a vendor underperforms, you can say “bye-bye” very easily. You're not locked in, and you also create scope to change what the deliverables are by having the opportunity to create new contracts as you go. It's by no means saying that you can deliver some of these large projects for that low dollar amount. It's that individual contracts shouldn't exceed that amount. This is where the idea of modular contracting comes in and of bringing together smaller pieces of a project and putting them together.

I don't know if I'm allowed to pass it to Sean, but he has lots to say about this, because I know he has thought quite a lot about how to implement modular contracting.

Sean, did you want to add ideas to this?

[Sean Boots]

Sure, yes.

[The Chair, Conservative, Kelly McCauley]

I'm sorry, Mr. Boots, let me interrupt. We are past our time, but I'm letting everyone go, as you can see in the first round, just because the answers are so interesting. If you could keep it to about a minute, Mr. Boots, I'm sure we'll be able to get back to you.

[Sean Boots]

It's just that modular contracting is the idea that you should break large projects into smaller ones. Often, especially in the public service, procurement folks will hear this and immediately think, “It's contract splitting. This is illegal.” Really, contract splitting by definition means breaking things into smaller pieces with the intention of getting just under regulatory or disclosure thresholds or contracting thresholds. Modular contracting or unbundling contracts means breaking it into smaller pieces so that it's more likely to succeed. The intention is different, and by definition, it's not contract splitting, which I think is something people often miss.

[The Chair, Conservative, Kelly McCauley]

Thank you very much.

Mrs. Vignola, please go ahead.

[Julie Vignola, Bloc, Beauport—Limoilou, QC]

Thank you very much, Mr. Chair.

Ms. Clarke and Mr. Boots, thank you for being with us.

Our party introduced a bill to protect public servants who disclose wrongdoing. It's currently being studied in the Senate. In your search for data and information, were cases of fraud such as those covered in the media directly disclosed to you by public servants, or did you have to seek out information using traditional methods?