That's a great question.
I didn't have time to bring it up in my remarks. I think that, if you're focusing on the question of digital service, design and delivery, procurement is a huge part of that conversation.
I think there are two interesting things happening in the procurement space right now. One, as I mentioned in my remarks, is that, early on, a lot of digital government enthusiasts, particularly with the dawn of open data, thought that governments wouldn't have to produce a lot of their digital services. That model didn't pan out, for a number of reasons. One of the big ones was that there are a lot of core services that governments are going to have to continue to develop, both citizen-facing but also internal corporate systems such as pay systems or email systems. In response to that, one of the things we've seen is an interesting return to the state on the procurement front, where we're seeing leading digital governments investing quite a lot in their internal capacity to be smart shoppers in this space.
I would say that both Sidewalk Toronto and the example of the Phoenix pay system originated in part from the same problem. In the case of Toronto, the waterfront board—and in the case of the Government of Canada, I guess it would have been Public Works—didn't have sufficient expertise to make smart choices about what systems they needed. This is part of what something like the Canadian digital service is attempting to remedy by bringing people in-house in government who can design contracts sensibly to procure what they need.
The other interesting thing that I think is happening in this space is how we originally ask what we need from the system. This is moving away from designing, in particular, citizen-facing services around government structures and internal government needs. Instead, it is borrowing from a field of work called design thinking to begin early on with deep research into users and how they're going to use the service. You would then structure any procurement you might need to do and any service design around that.
Something like Phoenix could have been prevented in many ways by doing that kind of work early on and realizing the complexities of the system and what you would have needed. That user testing allows you, in particular, to experiment on a small scale before you sign onto a long-term contract—what we call legacy contract—which often anticipates what you're going to need from a digital service before you've even tried it. If you look historically and globally at the big IT failures, you see that it's these legacy contracts that didn't begin with small-scale user testing that lead to the big failures we see. HealthCare.gov was mentioned, for example.