Government Operations Committee on July 24th, 2024

[Ron McKinnon, Liberal, Coquitlam—Port Coquitlam, BC]

Thank you, Mr. Ehsassi.

Mr. Boots, earlier on in the meeting we heard that projects that are too big to succeed are a problem. We need smaller projects, particularly for software. You emphasized that it's not so much about the projects but about the contracts. We need smaller contracts, of less than $2 million or so in three years. It occurs to me, though, that this sidesteps the issue. If you have a large project in which you have some number of smaller subcontracts, you still have a large project, and someone has to define that project, analyze the components of it and then allocate those. Creating a whole number of subcontracts of less than $2 million and so forth doesn't really solve the problem that we will probably have a larger overall project that is substantially more.

[Sean Boots]

It's a good perspective. In some ways, that's an illustration of the burdensome internal barriers that exist for public servants who are trying to get a procurement or an RFP out the door. It is so much work and so time-consuming to go through all of the paperwork steps to get there. That's one of the reasons that public service teams are so incentivized to have, instead of five small contracts, just one enormous contract with one of the really large vendors, who then will probably get a bunch of subcontractors and do work that's really hard to keep accountable.

I think breaking things into smaller contracts, as Professor Clarke spoke about, is a way of being more accountable to you if those contracts are actually delivering good value. If it's a contract for $2 million for six months for some team and they do a bad job, you can drop them and move to the next vendor. But if you have a five-year-long contract for $30 million with one company, even if they're doing a terrible job two years in, you're probably still stuck with them. It's too hard to extricate yourself. Breaking a thing into smaller contracts is a way of improving the quality of outcomes.

Around the overall cost of even large IT projects, one thing the private sector technology industry shows us is that you can have a massively popular software product used by millions of people for a fraction of the cost more than if it were used by only a few people. For example, if you're the team that launched Instagram 10 or 15 years ago, you probably had a team of five software developers. You built Instagram. The cost of running the team that built Instagram is the same if it had two people using it or if it had 300 million people using it. The only differential cost is a little bit of cloud computing infrastructure, which doesn't really cost much money nowadays. So the team of people building it is the most expensive part regardless of how much it's used.

That way of thinking really hasn't internalized itself into government software, where the idea is that this is used by millions of people, so we need a thousand-person team of contractors working on it. The truth is that you could build an equally high-quality product with a team of 10 or 15 at a fraction of the cost.

There is some great writing from Waldo Jaquith in the United States. I don't know if we've mentioned his work before. He has a great piece about “scrum team years”, which is around this assumption that a large IT project in government surely must cost $50 million. But what are you actually getting for $50 million? A lot of paperwork.

To actually build the software that people will use, you might need one team. That might be $1 million a year. You might need two teams. That's $2 million a year. The costs are actually much lower than people are accustomed to in government IT. There's just this normalized idea that it's a large project affecting a lot of people, so it must cost a lot. It's hard to question that when that's established thinking on these types of projects.

[Ron McKinnon, Liberal, Coquitlam—Port Coquitlam, BC]

But are you still not committing to a large project that is substantially more than $2 million? Within that context, it will be up to the vendor to decide how to manage it and whether to break that down into small sub-projects.

[Sean Boots]

That's a great question. I think the thing that is a cautionary tale, once you try to break a large project into small ones, is this idea of false incrementalism. Sometimes you see an idea where you'll take a large project and you'll say, “Here's phase one, here's phase two, here's phase three and here's phase four”. The question that anyone in a leadership position should be asking is whether, when they did that, it was still useful if they only ever did phase one or two. If they just stopped there, would it still add public value?

Of course, if you're delivering software on a regular basis and actually shipping it out the door for the public to use and to get feedback so that people actually benefit from it, then it's still useful after only one phase or only two phases. If it's a five- or 10-phased project that's only useful at the very end, five years later, then you haven't actually broken it down. You've just given little labels to it. Actually shipping something out the door for the public to use—that's the real defining factor between genuinely breaking things into smaller pieces or false incrementalism where it looks like you did but it's not actually benefiting the public.

[The Chair, Conservative, Kelly McCauley]

Thanks very much.

We'll go to Mrs. Vignola, please.

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

Thank you very much, Mr. Chair.

Ms. Clarke, in 2022, it was estimated that at least 7,700 IT consultants worked in departments and earned an average of $1,400 a day. I believe it was you who made that estimate. Some were making as much as $2,800 a day.

First, do those rates match what the same IT consultants would earn in a private business, in your opinion?

[Dr. Amanda Clarke]

Do public sector salaries reflect the salaries that private sector consultants would make?

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

Those 7,700 IT consultants were making $1,400 a day on average as subcontractors for the government. If they worked for a private business, would they be paid the same rate, a lower rate or a higher rate?

[Dr. Amanda Clarke]

I don't actually have the data on that to know what the average consulting fee is for the private sector. It's a good question, though, to investigate whether it's more lucrative to work as a consultant with government versus contracting with a private firm.

We did find one thing really interesting. The Auditor General has been helpful in understanding how much we pay on average per day for a contractor versus an in-house government employee, and it is quite striking how much more expensive it is. Again, it's not to say that everything should be in-house; there's nuance there. Some roles should probably be in-house, like a product owner, for example. I mentioned Finland a few times. They don't have any coders in-house; they just outsource all of that. There's an efficiency in terms what type of role it is, as well.

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

Thank you very much. You answered my second question. Public servants don't make that much.

Can this difference between public servants and IT subcontractors be explained, in whole or in part, by the fact that there may be one or more layers of intermediaries—

[The Chair, Conservative, Kelly McCauley]

I'm sorry. We're going to pause the time. We're just having issues with the interpretation.

Could you go ahead and speak a bit, Mrs. Vignola?

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

Yes.

Can the difference in pay between consultants and public servants be explained, in whole or in part, by the fact that there are several layers of intermediaries, that is to say that subcontractors will select certain other subcontractors and divide the total amount among them?

[Dr. Amanda Clarke]

Possibly. We didn't look at that; we didn't have data around that in our research. It's a good question.

Mr. Boots, do you have any thoughts on that?

[Sean Boots]

One of the problems with the rate paid to the subcontractors is that if their daily rate is $2,000, for example, presumably a lot of that money goes to the company they work for, if it's a large consulting firm. It's difficult to know how these amounts are divided up if there are several intermediaries, as you said, between the subcontractor hired and the individual who actually does the work.

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

Thank you very much.

Ms. Clarke, you said that people who really had IT or programming skills, among other things, didn't necessarily want to have to fill out time sheets.

Would it be a good idea to have managers who specialize in monitoring technical contracts along with more traditional managers focused on human resources, and therefore have two categories of managers working hand in glove?

[Dr. Amanda Clarke]

I think we've often looked at it in terms of the career progression in the private sector and how you can continue to move up through the ranks in a tech firm, for example, getting more seniority and better pay while still doing the technical work.

Your point is, if I'm understanding it, whether there could be a more technical managerial route versus.... I hadn't thought about that.

Mr. Boots probably has, or at least has thoughts on how that could be operationalized based on what he has seen with his colleagues. He worked very closely with tech talent in government that could have run off to the private sector as well.

[Sean Boots]

It would be useful to have those two trajectories: human resource managers, on the one hand, and computer scientists at increasingly senior levels, on the other. A change like that would improve the quality of IT services in the public service.

The most important thing to note is that the IT occupational group in government includes both technical support officers, who are at the lower end of the scale, and cybersecurity or cloud computing experts, for example. We often hear IT officials suggest that the occupational group should be divided in two, so that there are experts in software development, cloud computing or cybersecurity, and then the more traditional IT positions, such as technical support officer, team manager and other services of that kind. There would be a great advantage to splitting that occupational group in two. It would make it easier to hire experts, who are not currently being offered a competitive salary.

[The Chair, Conservative, Kelly McCauley]

Thank you very much.

Ms. Blaney, you're batting cleanup for us today. The floor is yours, please, to finish us off.

[Rachel Blaney, NDP, North Island—Powell River, BC]

Thank you so much, Chair. I appreciate it.

This has just been so fascinating. As a member who isn't often on this committee, I have to say I've really enjoyed what I've learned.

One of the questions I'm asking both of you, because you have different expertise on this issue, is about finding the right balance between in-house and contracting out. That has come up a lot. How should we consider measuring that? What do we need to assess in that process?

I will say for the public service that they are on the precipice of defending taxpayer dollars and how they're spent. This is obviously not going very well right now, so what kind of policy do we need to really find that balance of in-house, and what is the justification behind it?

When we look at a lot of these issues, the problem is that, until there's a crisis, they are very hard to explain to people who vote in our country, and we want Canadians to have a better understanding of why we're doing what we're doing when we're in government. If you could give us a little bit of thoughtfulness around that, I would really appreciate it.

[Dr. Amanda Clarke]

It's a good question. There's some nuance, and I don't think there is a clear rule yet on what the ratio is between in-house versus outsourced. There are different approaches. As I mentioned, some governments really emphasize a fluid back-and-forth. Their focus is on a core of IT expertise in particular roles. The product ownership role is one, so it's something that is regularly cited to me as something that needs to be brought in-house.

Taking senior leadership and empowered proven technologists who've produced high-quality services and putting those folks into deputy minister-rank positions where they can actually influence how the rest of the work in their department unfolds seems to be an area where focusing on in-house is really important.

There's scope to think about this across departments. We work right now with the Canadian Digital Service, and that's something we haven't talked about yet today, but that is an important tool we could use more across the federal public service to bring in tech talent.

Many governments start out this journey of re-skilling or upskilling by creating these small digital service teams at the centre, and then, over time, departments create their own digital service teams with the idea that they can pass on these methods and try to retrain internally.

However, there is no golden rule for how much of the work should be sent out to others to do and what should be kept in-house, with the exception, as I said, of how regularly the product ownership role comes up. The other one that regularly comes up when I speak to public servants about this issue is they feel very strongly that policy, vision, strategy and the objectives of a digitization initiative should be internal, and then the footwork can be fruitfully outsourced.

There are certain other areas where it's just not going to be reasonable to keep that expertise on hand, like the latest expertise in artificial intelligence or cybersecurity. This might be something where we want to turn more to external advisors and have a sufficient base of knowledge internally to be able to ask good questions and really scrutinize the advice they provide.

[Sean Boots]

I would add that there are two principles, regardless of what that ratio is. I think we agree that there should be at least considerably more in-house tech talent than the current ratio. Regardless of what the perfect ratio might be, to me two principles come to mind. For technology products to succeed, you need better feedback loops. Part of that is public service culture. It's really hard, from the ground level on up, to share bad news up the chain. You can imagine stories about Phoenix, where people with their hands on the keyboards were like, “Wow, this is totally going to blow up.” Of course, as that goes up the chain, it gets watered down every time. The project manager above them is like, “We're dealing with some issues, but it will totally turn out better”, and then the layer above them says, “You know, aside from a few things, it seems great.” By the time it gets to the deputy minister, it's glowing green lights all across the board. So figuring out ways to short-circuit the lag time or the telephone tag that happens between the technology folks doing the work and the decision-makers eight or nine layers above them is really important.

The other angle, as Professor Clarke mentioned, is around ministerial accountability in technology products in the federal government. It is so diluted and so diffuse, where any given project has so many external dependencies. For example, you have the team building the product, you have their contractors, you have Shared Services doing some things and you have TBS needing to get reports on other things. It is so hard to say, “Here's the team that's ultimately accountable at the end of the day. Here's the director. Here's the ADM. Here's the deputy minister. Here's the minister.” It's just so diffuse. That is something where the more that you can reduce external dependencies, the more likely your project is to succeed. Cut SSC out of it and cut other groups out of it. Just have a good team and do the work. Fend off everyone else for as long as you can.

[The Chair, Conservative, Kelly McCauley]

Wonderful. That is our time.

Mr. Boots and Professor Clark, thank you sincerely for your time and your patience with us. If you have any reports, any links or any documents you wish to share, I do encourage you to send them in to the clerk, please. We'll get them translated and sent out to the members. I assure you that these would be very welcome. We look forward to perhaps welcoming you back again when your paper is published.

Again, thank you sincerely.

We are adjourned.