Government Operations Committee on Feb. 13th, 2018

[The Chair, Conservative, Tom Lukiwski]

Colleagues, I think I'll call the meeting to order, it being about one minute past 11 a.m.

I thank our witnesses for being with us today. Mr. Akrouche, I understand, is on his way, so he will be joining us in just a few moments.

We have a distinguished panel of guests with us today.

First we have Mr. Dan Murphy, who most of you, I believe, will have met before during his previous appearance discussing an agile approach to procurement.

We also have, from Ernst and Young, Ms. Kirsten Tisdale. As well, we have Mr. André Leduc, from the Information Technology Association of Canada.

Thank you so much for being here.

Mr. Akrouche is also joining us. He is from Strategic Relationships Solutions Incorporated.

Witnesses, if you haven't appeared before a committee before, the norm is that we will begin with seven-minute rounds of questioning from all of our colleagues, followed by five-minute interventions, and we will continue until approximately 12:50. I'd like to keep about 10 minutes for a very, very brief committee business update. It's just one piece of business and a calendar update. We'll try to suspend about 12:50.

With that brief introduction, Mr. Murphy, I have you first on my list.

Welcome again, sir, and the floor is yours.

[Dan Murphy, President, AdaptiveOrg Inc., As an Individual]

Thank you, Mr. Chair.

Thank you, honourable members of the committee.

I did a little research on the procurement side of SMEs before I came. My expertise, as you know, is more around Agile, and the adoption of agile methods.

With respect to a small and medium-sized enterprises, when I looked at the Public Works website, whether it's correct or not—I believe it is—it says that 40% of all the current procurement business in the government goes to Canadian small and medium-sized enterprises. I'm not sure what segment that is. Right off the bat, rather than the seven-minute presentation, I have a question for the committee. I would like to understand the specific problem the committee wishes to address. Three years from now, what would be the perfect outcome the committee wants to get?

The first thing we do in agile is say we need to understand the problem. I distributed the Amazon HQ2 RFP. It's for a very large investment from an Amazon perspective, in the billions. It's an opportunity for the winning city, and the RFP was written in eight pages. The RFP doesn't get into much detail about specifics, about how they want buildings made, or all the details around the construction; it just says they want a new headquarters, and they have this investment opportunity they're going to make. It's going to create this kind of employment opportunity for you. They articulate their problem and then they clearly articulate the opportunity for the bidders, and then it goes out. They don't get into all the detail.

Once we get into detail in a government procurement, the government is responsible for ensuring that all the detail is in the RFP. If you miss a detail, the government's accountable. This is what's happening in the bids. If we put a large bid forward, $40 million, there's a lot of risk in it just by the size. I have a procurement that might be 200 pages. I have a specification and a specification matrix that's laid out in a spreadsheet that might be four or five pages of details laying out exactly what I want.

What if I miss something, because the world's a little more complex than it used to be? The contract is based on this very complex spec. If you miss something, that's your problem. You didn't ask for it. What if you turn that around and tell the the vendor your problem, and then ask them for their solution?

The culture of the government is that as soon as they say RFP, they need a detailed requirements definition. That's in the culture. It's ingrained. The culture has to switch to saying they need business owners, not particularly IT, to say this is what the problem is, this is what you're trying to solve from a business perspective. It's not that you want a particular vendor's solution, but this is the business problem you're trying to solve, in the same way Amazon laid out their business problem.

There's no commitment on anyone when you lay out your business problem. Look at the last line in the Amazon RFP, which says they have no commitment to do business with anybody, although that is a standard clause in most of the government terms.

Then we have all these people coming to the table around an enormous opportunity. Everybody wants to get that bid because of the economic value. The government has those kinds of opportunities. They have a huge benefit opportunity for the private sector, so they will attract the best if they articulate their problem and its size. That's it. Don't do anything else. Don't put anything else in the bid. Put in your legal requirements. Take the policy and park it. Policy is over here.

Legal is required. It's compliance. As for policy, policy is supposed to drive the outcome you want. Let the vendor come back and tell you how he would do it. If no one responds, or no one is capable of responding, it's an indication that the skill set does not exist in the industry.

If the industry comes back with an extremely detailed response, it shows you their capability, and it should be part of your evaluation criteria, not whether they checked off everything on the....

The other thing is that the government would be off the hook from the point of view of accountability. It would hugely de-risk your procurements.

There's another point I want to make. There are some vehicles in the government that exist today. They're not perfect, but they could be renovated. They could be reworked. There's a procurement vehicle that PSPC has called the SBIPS, the solutions-based informatics professional services procurement vehicle. It's a standing arrangement for solution-based, outcomes-based procurements. The challenge, I think, is that most of the culture of the government doesn't know how to write that kind of bid. They don't know how to write a problem statement bid, so there's a capability issue, from what I can see, and this is early on.

The other part of the SBIPS thing that I think could be renovated.... I'm assuming this is about addressing the problem. Again, at your level, what is the desired outcome? It could be from a political point of view. It doesn't matter. What is it that you want to get at the end of the day? If it is to renovate the procurement vehicles for small and medium enterprises, the initial cut-off point for SBIPS is $2 million and under, so there's a lot of small....

I have a friend in Vancouver. His name is Colin McWhinnie. He runs a small company that helps start-ups get off the ground. One of the specialties he has is dealing with how to leverage government to get some benefit for a start-up to get going. He said that what used to be a 200-person company is now a one-to-10-person company. It's a totally different dynamic. A one-to-10-person company doesn't have time to spend three weeks filling out forms. A one-to-10-person company doesn't want to bid on a $2-million opportunity—$100,000 is fine. Something under the NAFTA limit would be great for them. If what you want to solve is to engage the micro-segment, the one-to-10 segment, it seems like the SMEs are getting a pretty good share of the pie, although you'd have to look at the details. If that's what you want to do, maybe you want to have ultralight procurements. Maybe you can renovate some of the existing things instead of starting from scratch. Just renovate what you have and make it work.

From an agile point of view, we would say you need a few people on the team. You need your procurement person; you need legal and policy on the team; you need your business owner, because the business owner has to define the problem; and you potentially would need IT if it's a technology solution. Then the next one you need on the team is the SME. You need to get more immediate feedback on what's working. You put a small team together for a very small-value bids, such as $50,000 bids, for a period of six to 12 months. It's almost like a sole source for that small vendor, but what they have to do is be on the team. They have to give you feedback, and then you can use that feedback to find out how you write the bid, how you lighten the process to make it work. Is that possible within the policy constraints of government?

That's my nine and a half minutes, I guess.

[The Chair, Conservative, Tom Lukiwski]

Thank you very much.

Next up we have Ms. Kirsten Tisdale.

[Kirsten Tisdale, Managing Partner, Government and Public Sector, Ernst and Young LLP]

Thank you very much.

There's a presentation that I think is in your packs that I'll just generally refer to. I'll mostly just speak, but there's some material in there that might be useful to you later on.

I very much appreciate the chance to come and speak with you today. When I look at the procurement function of government and at all the transformation agenda you have and what you're trying to achieve, this is such a fundamental building block. You can't do what you want to do as a government without getting this fixed.

When you look across the country, across the world, you see that Canada is looked to for so many things. I lead our global consulting practice for government, and everywhere I go they want to know what Canada's doing, but not in this area. We have fallen behind. They look to us for so much innovation, but procurement has become a blocker for what you're trying to do. It's time to get this right.

If you go to slide three, what I'm going to focus on is what's getting in the way and what you might do to try to fix it. I would echo a lot of what Mr. Murphy has said here.

There are a few things.

First of all, there's this focus on the lowest price. I think what we need to do as a government is focus on value and outcomes. The lowest price often becomes the highest price over the life of a contract or a relationship. We need to focus on enterprise value. Government doesn't have the corner on good ideas. Again, as Dan was just saying, if we sit in the backroom and we try to come up with the perfect set of requirements, we're always going to get it wrong. There's so much creativity out there. What we need to do is define the outcomes that we're looking for, let the private sector come to us with creative and innovative ideas, and give them the space to do that.

There are very rigid processes that don't allow for any flexibility. I think we've designed the procurement processes to protect against the exception, as opposed to creating an environment where people are going to come and be able to drive value for the government. We've dumbed it right down to the lowest common denominator from a risk aversion perspective. When we do that, we get in our own way. The business stakeholders, again to the point that Dan made, are not owning and leading the process. We need our business leaders in front of this.

The talent required to create these arrangements and to co-develop solutions with the private sector is not necessarily sitting in our procurement group today. We need to rethink the talent agenda, the career paths, the compensation, where we recruit, and how we develop procurement officers. I think you need to look at all the options around whether that's even a core competency of government or whether others could do it better.

Create the ability to co-develop and communicate with vendors throughout the procurement process. I've been on every side of the government procurement process. I've been a vendor and I've been an adviser. I'm thinking about a process that we've been involved with very recently. From the time we were told we were the lead incumbent to the next conversation was 18 months. It was 18 months of hiding behind we don't know what, not being allowed to talk to a human being. Your business has changed dramatically in 18 months' time, so what you're originally trying to procure compared to current-day needs is almost unrecognizable. If a conversation had been allowed through the life of that process, we could have continued to evolve our solution so that it stayed current. That's the kind of thing that we need to be able to build in.

On slides four and five, I've gone through, on the left-hand side, some of the problems, and I've put some of the specific ideas that you might want to consider as you're contemplating reform on the right.

In terms of rigidity, the processes need to create the space for co-development, engagement, and communication with the vendors. Whether those are large or small, we need to have a much more open process that allows that communication back and forth.

I used to lead the transformation program for the Province of British Columbia. I was a deputy minister there about 10 years ago, actually. I worked with Joyce Murray at one point in time. We developed a process called joint solution procurement. You will have probably heard about this. This isn't for every project that you would do, but it's for those large, complex ones. If we think about Phoenix, about the e-procurement process, and about what you're trying to do in terms of a lot of the digital agenda, you have an outcome you're trying to achieve. You define that, and you define the constraints you're operating under, and then you put it out there and let the vendors come through. It's a very competitive process. It's very transparent. It follows all the rules. It requires a very smart government team to manage this process, but what you get at the end of it is a co-developed solution that's going to ideally meet your needs. That process has been well established, and it works exceedingly well, but you need to have the talent on the government side to really pull that off.

We can provide lots of information on joint solution procurement.

Value gets lost over the life of the deal, and we talked a little bit about this earlier. It's one thing to actually sign a contract, and everyone has a “Yahoo!” moment, but the value over the next three years, five years, or 10 years tends to erode, so we need to put just as much energy, focus, and talent into the management of that long-term relationship, if this is a long-term type of thing, as we do into getting to the deal. Again, it's about making sure you have the talent, the incentives, and the capability to do that lifetime contract management, and also to make it flexible enough and to anticipate, when you do enter into some sort of solutioning relationship with a provider, that technology's going to change, business needs are going to change, and demographics are going to change. Things are going to happen, so you build regular checkpoints into that process so you can continue to evolve it so there's value on both sides.

We've talked a lot about contract flexibility and the ability to make sure you're inviting and allowing the participants in the process to propose alternative solutions and creative solutions. It's very difficult for them to do that right now, to fit that into those little ticky boxes that are impossible to manipulate. There's no incentive to do it. Most often in the procurement processes that happen today, there's no way of scoring that. What happens when people do come with a creative, higher-value solution is that they usually get disqualified, because the government doesn't know what to do with it. It either cancels the procurement process entirely and starts again, or it disqualifies the person who's put it in.

Again, when you're looking at all-of-government types of solutions, you often start with a few ministries or departments, and then it scales up over time. It's important, when you put your original procurement documents out there, that you anticipate and you encourage to allow the scaling so that you can onboard other parts of government, other parts of the broader public sector. That way you don't have to keep going back to the street over and over and over again to procure the same thing. If the provider is performing and exceeding the outcomes you set, and you put much more in place around a performance-based evaluation, it allows you to scale along with the provider.

Finally, I'll just spend a minute on talent. We talked a little bit about this. We could fix the processes and we could fix the documentation, but if you don't have the talent on the government side of the procurement group, you're not going to be able to get there. There is, I would say, an urgent need to look at the kinds of skills that are required, the career paths and compensation, and that needs to be completely revamped so that you can have the same level of talent on the government side of the table as you're hoping to attract from around the world.

I'll stop there.

[The Chair, Conservative, Tom Lukiwski]

Thank you very much.

Finally, we have Mr. Andy Akrouche. Welcome, sir. You have 10 minutes.

[Andy Akrouche, Managing Partner, Strategic Relationships Solutions Inc.]

Thank you very much. It's a pleasure to be here again.

What I'd like to talk about today is agile procurement. Obviously it's in the context of complex business arrangements, because it wouldn't need to be agile if it's not that complex.

It's not a secret that the majority of complex business arrangements fall short of meeting stakeholders' expectations in the long haul. There is no shortage of evidence out there that shows that there are two fundamental that this failure occurs.

The first one is what we believe to be the transactional orientation of these business arrangements. We seem to structure them as transactions and deals, rigid deals that don't respond well to change and evolution. Parties to the contract try to pursue certainty in the long haul based on an initial set of parameters.

The second thing is really the oversight models we use to manage those complex business arrangements. We use top-down, command and control, compliance-based models that have been counterproductive to people working together to achieve improved outcomes.

Needless to say, the combination of these two has created a culture of mistrust, if you like, and some adversarial walls that impede progress.

What's happening in the industry is that there is a push towards relationships management. I think you've touched on that. Really, there is recognition that no number of procurement specialists and lawyers and accountants can create certainty in the long haul.

Then what can we do? There are three things. One is that the contract must become a platform to manage the inevitable change, not to pursue certainty based on the initial deal. The second thing we can do is think about how we think about risk, because the public sector, really, cannot transfer risk. This whole idea of transferring risk to the private sector hasn't worked very well, because ultimately it's your risk. At best what you can do is lend risk.

The third thing you need to have is more insight into your governance, not just oversight. Oversight is good, and you need oversight, but without insight, your oversight is superficial and will lead to wrong conclusions over time.

The third thing that's happening in the industry is that there is wide recognition that there is a dependent relationship between complexity of these complex arrangements and collaboration. The more complex it is, the more collaborative you need to be. It's not hands-off kind of stuff. The more complex it is, the more collaboration is needed, and that collaboration is needed to resolve ambiguity in the business arrangements to arrive at certainty together over time.

What's also happening is the emergence of standards. We have ISO 44002 right now that really speaks to this issue—sorry, that's ISO 44001, and now 44002 is actually being launched. It talks to exactly the same problem, and it provides common language and standards for arriving at really good solutions in this space.

Overall what's happening in the industry is that there is wide recognition that managing the relationships among stakeholders is the most critical aspect of a successful initiative.

It's against this backdrop that I want to talk a little bit about agile procurement. I'm here to talk about that. Agile is a software development methodology in which integrated product teams representing all stakeholders work very closely together to develop a product or deliver a project. From a procurement perspective, these teams would work together, utilizing a very similar approach, an iterative process, to define a certain set of requirements and work together on a solution and arrive at the outcome that way.

It's not the same as the waterfall approach of the past. It's really a series of small waterfalls, if you like, that allow people to build on what they have already done by going back and reworking or adjusting, as required, on a go-forward basis.

My question really is, which part of this agile procurement have we not tried before? I recall, for those of us who are old enough, the BDP process, the benefit-driven procurement process. Does anybody remember that? Sure, this was back in 1994. It was an outcome-based process, exactly the same stuff we're talking about here. You needed to have a solid business case and a robust risk assessment, and that was all you needed to do.

Next we came up with something called CPP, which is a common-purpose procurement, which is exactly the same stuff. In the style of Dragons' Den or Shark Tank, people came in and 90% of the evaluation was about how well they presented or how slick the marketing team was.

Of course, we have the JSP, which is joint solution procurement, which really comes down to a very competitive process between the final two vendors. Again, it's a very collaborative process, through engaging the vendors. They have access to the management team and all this other stuff. I've studied it in great detail.

We have performance-based contracting, which came into the federal government from Australia and which we actually do right now. Most of the contracts that are coming out of DND are all performance-based contracts.

We have smart procurement, as of a few years ago. Smart procurement was designed to really increase this collaboration throughout the whole competitive process, from planning to procurement to contracting. You have heavy-duty engagement with industry groups. We've done all that.

Now we have commissioning, which is really another form of performance-based contracting, the old ASD model in a combination with the JSP. Now we call it commissioning.

If all we want to talk about is having agile procurement, which is really a combination of all these different things that we've done in the past, my view is that they haven't really worked very well. The outcome we've been looking for has been very elusive, because I think we're not addressing the real problem.

The real problem lies in the relationship management, not in the procurement. It's not a procurement problem. It's a relationship management problem. The key to success really lies in focusing on the relationship as the pivotal point at which procurement and contract management actually occurs. In recognizing this pivotal role, we need to, if you like, source relationships instead of deals or transactions. Relationships is the first approach. In this relationships-first approach, the priorities actually shift to the need for establishing a management framework to manage the stakeholder relationships very early in the process, during the procurement process, and after the procurement process.

Sourcing relationships really means three things.

It means that you need to select vendors. We can't just write one page and say, “Okay, that's the requirement.” We need to know how to evaluate these things. We need to really understand if we are getting a chicken or a turkey here.

How do we know that? That's what's been missing. What's been missing is our ability to assess the vendor's corporate abilities and capabilities to do the job. There are a lot of analytical tools out there to do this. We call this strategic fit assessment, which is the ability to objectively assess whether there is a match between what we're trying to achieve in terms of outcomes and benefit realization factors and the capabilities, strategies, and management structures of this vendor.

The second thing we need to do is measure the internal processes and systems that organizations have and their ability to collaborate. ISO 44001 is a good start for an evaluation to see whether those organizations actually meet the standard. Do they have the internal systems and processes to collaborate and work with each other or work with others?

The difference is very stark. In the traditional contract model, the contract governs the relationship of the parties. In the relationship-based model, using the relationship management framework, the relationship actually governs the contract. That's really the difference. One is that you do a contract and you're handcuffed by that contract. The other is at the relationship management framework governs that contract and its evolution over time.

The good thing is that PSPC and DND have recognized the importance of relationships. In 2014, they launched a new procurement regime. It's called a relational contracting model or relational contracting management. It recognizes that the contract is incomplete when you sign it and it needs to be influenced by the relationship of the parties. It is a complete framework that DND has adopted for all of their in-service support business arrangements. I think they've launched one of them already. They're launching a bunch of these.

That's really what I wanted to say.

[The Chair, Conservative, Tom Lukiwski]

Thank you very much.

We'll start now with our seven-minute rounds.

Monsieur Drouin, you have seven minutes, please.

[Francis Drouin, Liberal, Glengarry—Prescott—Russell, ON]

Thank you, Mr. Chair.

We're not hearing from Mr. Leduc, I guess.

[The Chair, Conservative, Tom Lukiwski]

We're all here for support.

[Francis Drouin, Liberal, Glengarry—Prescott—Russell, ON]

Okay.

Thanks for being here, and thanks to some of you for coming back here.

I have a quick question for Kirsten. You've mentioned talent. I want to say I completely agree with you. I have seen planning phases from competitors that were very thick in plans that were supposed to happen, and here's how you do it, but in those documents I never saw anything about assessing whether or not the government had the talent to do this.

That was part of the data centres. We've talked about reducing the number of data centres for almost 10 years now. Obviously, both governments have not reached the initial target that was set out by SSC, Shared Services Canada, but in this, I didn't see anything about talent.

Andy, you've talked about JSP, CPP, and smart procurement. Essentially what I'm hearing from you is that we can talk about any strategy we want, but at the same time, we need to ensure that the talent is in place.

What would you recommend to the government? What would you recommend to us that we can recommend the government do in terms of talent and ensuring there is the talent in place to perform whatever strategy we put into place?

[Kirsten Tisdale]

I think there are two things. When we were facing this problem in British Columbia, what we recognized very quickly was that we didn't have the talent in-house and that it would take too long to grow it, so we put in place something almost like a SWAT team, a very small, smart, hand-picked group of the best people we could find from the private sector. It was not a firm. We didn't go out and contract with a firm. We hand-picked the individuals, and we brought them in-house, and we had them basically be... It was just 12 people, not huge, for the entire province.

We hand-picked them. We had solution architects, we had expert legal, we had HR, we had labour, we had smart financial minds, and we had people who had deep experience in terms of putting together complex deals and managing relationships. That secretariat served out to government, and we had the focus of....

I would suggest creating a centralized, funded capability. The role of that capability would be twofold. One is to model how one does these deals, so they would go out and they'd do the first 12 or 15 or 20, or whatever it is, pulling the public sector in behind them.

You would also create a program whereby you would be training and institutionalizing how one does this, but that's going to take, I would say, three to five-plus years. I think that's the first piece you need to do. You need to bring it in and create it, very consciously and carefully.

Part of the job is to support these projects right across government; the other part of the job is to build the capability in-house. There are two parts.

I think the other piece in parallel that you would need to do is look at the procurement officer of the future. Treasury Board started this piece of work and then stopped it. I don't understand why they never went forward with it. What they wanted to do was look at the skills required for modernized procurement. What are the capabilities? What are the career paths? Where do we find these people, and how do we develop these people? How do we pay these people? It was basically to create an HR framework for the development, maintenance, retention, and future-state function for procurement.

I think you need to do both, but if you just do the first one, you're going to be waiting too long, so I would create your SWAT team, and in parallel with that, I would create your procurement function of the future, and then start to really build it.

It will take a generational change. Don't be afraid to bring people from the outside in who have done it before to seed that effort and get it started. Over time they'll move out and you'll have created a capability, but you need it kick-started.

You need some people who have no territorial turf to defend. Their whole job is to be the change agents that you need to break through the doors that they don't even know are there. You need to create that capacity, and it's very difficult to do it in-house because the inertia is just overwhelming.

[Andy Akrouche]

May I add to that? I totally agree. I think it's a journey. It's not something that you're going to be able to change over the next few years. It's a change in culture, in how the procurement officers actually view the vendors and the contract managers view their partners. They don't view them in a lens as if they are a partner and they want to work with them. It's a major culture change.

What you can do, though, is a lot of training. There are a lot of training programs out there. We have a three-day training program on relationships management, and complex contracting. The ICW, the Institute for Collaborative Working, offers three or four really good programs, such as ISO 44001 and 44002.

In terms of a training program, I know that here in town, we helped Telfer, for example, to set up their relational contracting program. There are a lot of things that the government is doing in partnership with Telfer and other academia to promote the idea that you need to have flexible business arrangements and you need to manage those complex relationships. There are a lot of training programs out there. That's what you need to do.

[Francis Drouin, Liberal, Glengarry—Prescott—Russell, ON]

Do you get the sense that the procurement officer engages at a very early stage when the department is writing their SOW, for instance? Going back to the DND examples we heard about, one of my favourites was always the one about the snowshoes. At the time, PSPC was saying, “Well, they're just snowshoes, and you can buy those anywhere.” Then one of the army guys brought them out into the field, and the procurement officer realized, “Oops, I guess they're not just snowshoes, so we might want to...”.

[Voices]

Oh, oh!

[Francis Drouin, Liberal, Glengarry—Prescott—Russell, ON]

They were specialized snowshoes. Essentially, he couldn't walk in them. To me, that was a very simple lesson. Do you get the sense that right now procurement officers are engaged early in the process so that they understand the business of their departments?

[Andy Akrouche]

Yes, I think—

[The Chair, Conservative, Tom Lukiwski]

Unfortunately, we're going to have to get that answer with the next round here, perhaps, because we're completely out of time, but I'm sure the information will be transferred over the course of the next hour or so.

Mr. McCauley is next.

[Kelly McCauley, Conservative, Edmonton West, AB]

Thanks.

Welcome back, Mr. Akrouche, and welcome to the three of you.

Mr. Murphy, welcome back as well. I attended the one-day course that you did on agile procurement at the Shaw Centre. A lot of it was focused on IT procurement and developing programs. How easily do you see it rolling out to our procurement world?

[Dan Murphy]

What do you mean by “our procurement”? Broader than IT?

[Kelly McCauley, Conservative, Edmonton West, AB]

Yes, exactly.

[Dan Murphy]

I think I agree with Andy. Its complexity is the key. There are three mandatory elements for me to get engaged and have a successful outcome. First of all, you need the cross-functional team, as Kirsten suggested, the slot team, the tiger team. The number one before that, I think, is that you need to have a really clear description of the outcome you want—a clear articulation of the problem, and a clear definition of the outcome.

As a leader, you have to do that, and it's difficult sometimes for leaders to get that right on the first go-round. We refer to it as a “strategic intent”: we start with something called strategic intent and we say that we intend to get this outcome. Then you engage this high-calibre team and you see if you can get that outcome.

The next thing you need is a very fast feedback loop. You need to do something small with a fast feedback loop to get that outcome.

The next thing that we'll run into in government is authorization or enablement of the team. We've done a whole bunch of procurements, so we've seen all the different procurement types, all the stuff we've done for the last 20 years. We put a label on it, but when you throw it into that culture, it all comes out the same. You do a common procurement process. The vendor comes in and works with the government, and what they do is create a requirements definition, so you're still back in the old game. You still haven't defined your problem up front and you haven't defined the outcome. You're just going right to a requirements definition.

There are three pieces for me. One is authority: who's in charge? Because I'm in a stovepipe organization and I have this stovepipe and that stovepipe, if I want to get something done inside the stovepipe, I need authorization at the top of that stovepipe. If that's a director general and I can do everything within that DG realm, I can complete the project. If, however, I have to deal with another DG or another ADM, I need to get up to a DM and get across in order to clear the path, because there are always constraints. There are people in government who come out of the woodwork when life changes.

[Kelly McCauley, Conservative, Edmonton West, AB]

We've never encountered that.

[Voices]

Oh, oh!

[Dan Murphy]

When that happens, then you say, well, okay, now what is the—

[Kelly McCauley, Conservative, Edmonton West, AB]

The thing is that it's cultural.