OGGO Committee Meeting

     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.

     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.

    Thank you very much.

    Next up we have Ms. Kirsten Tisdale.

     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.

    Thank you very much.

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

     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.

    Thank you very much.

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

    Monsieur Drouin, you have seven minutes, please.

    Thank you, Mr. Chair.

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

    We're all here for support.

    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?

    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.

     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.

    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!

    Mr. Francis Drouin: 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?

    Yes, I think—

    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.

    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?

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

    Yes, exactly.

    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.

    We've never encountered that.

    Voices: Oh, oh!

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

    The thing is that it's cultural.

    Well, the defining factor is the outcome.

    Mr. Kelly McCauley: Yes.

    Mr. Dan Murphy: The definition of collaboration is that we all agree on what the outcome is. If we don't have an agreement on that as an organization, then there is no collaboration. It's called competition, or contingent: I want a different outcome than you do.

     I think the U.K. is pursuing the agile approach. Have you looked at how they're doing that or at how they're rolling that out, and are there any lessons maybe for us?

    I haven't, not in a lot of detail. When they were rolling out their initial stuff, it was mostly on IT and it looked as if it was mostly on software. Instead of going through a phase for writing requirements, the first phase was to create an alpha product. The second phase was to create a beta product, and so on. However, when I look at the press releases, I see a whole bunch of press around agiles not working in the U.K. There's a whole bunch of agile-failed projects in the U.K.

    I would expect that. I would expect that you're going to get a high acceleration on this, and then you're going to get some plateaus as there's push-back.

    I was going to ask that question. In your experience have you seen any agile setbacks?

    Yes, we do see agile setbacks, because we see these cross-functional teams working, but they're working in isolation, without that clear leadership vision and without the authority for someone at the top to clear the path.

    Is that the biggest issue you've seen with the setbacks—

    Those are the biggest. In fact, in the engagements we get involved with, we have a charter—which is a contract, effectively, which is kind of against the agile principles. However, in a tough engagement where you're really trying to change culture, you need that executive to sign off.

    Were they able to overcome those challenges, or did their culture not allow them to tackle that and they just kind of flatlined?

    That's why I have the charter. If you can't overcome those issues of clarity of vision and authority to clear the path, you're going to have trouble, and it doesn't matter what you do or what approach you use.

    Ms. Tisdale, you talked about B.C. Can you give us some examples of some of the projects they would have worked on that perhaps we would have heard of?

    Sure. There were a bunch of them. There was the revenue collection system, for example. Revenue is collected in about 147 different places across government, and they're all different, disconnected systems. What we did was basically go out and define what outcome we were looking for. We had a provider come in and replace all of the solutions, at its cost, and we entered into a long-term service contract with it. That drove out a couple of hundred million dollars in savings. There was that.

    There was the modernization of health benefits, the MSP. There was connecting all of the first nations communities, schools, hospitals, towns, and libraries in the province to a high-speed network. That was by amalgamating government spend across—

    This was all led by that original secretariat?

    These were all led by that secretariat.

    Were they hired as contractors, or were they brought into the government? How was that done?

    It was a combination. I was hired as an independent who was brought in on a contract, but in a titled role as a deputy. Everybody else I hired on contract. I replaced those people with government people over a period of time.

    Is it still going on, or has it just expanded?

    It's a little bit of a sad story. It continued on for quite a few years, and it has morphed into something they call the Strategic Partnerships Office. However, they didn't sustain the funding for it and it has kind of lost its teeth, to be honest. It wasn't sustained.

    Generally when you give organizations strategic titles, it kills them off.

    They're now trying to restart it again. We're actually having conversations about that. They're trying to figure out how to get back and do it again.

    Thank you very much.

    Desktop services, all the technology, and payroll, all of those—

    We're out of time, I'm afraid.

    Sorry; I didn't see that.

    Thanks very much.

    Mr. Blaikie, welcome back to the committee. You have seven minutes.

     Thank you very much. I'm happy to be here. Thank you all for coming and offering your thoughts.

    It's hard to disagree with what's being said at the general level, and I don't. It's better to be more flexible. Obviously, you want to tap the best talent that's out there in order to be able to move projects forward, and you want to be outcome-focused because you want to ensure when you have a contract that you're actually getting to where you want to be. That sounds like a really obvious statement, but apparently it's not as obvious as one might like.

    There are some questions that come up for me. I think part of the way that you end up with the culture that has developed, one that is overly rigid and can get in the way of achieving the outcomes that we want, is to try to be able to compare apples to apples. Also, in government they are not spending their own money, as a private company does, which, if it fails—well, that's the market. You close up shop and move on. Maybe you start up something else, and maybe you don't.

    Here we're accountable to other people for the money that's spent, so we need to be able to make the case. If you can't make the case retroactively or if there's a lot of commercially protected information that you can't disclose to people, then what you can do up front in the procurement process is try to be very clear about what it is that you're asking companies to deliver so you have an apples-to-apples comparison.

    In order to avoid some of the pitfalls of overly comfortable relationships between particular governments and particular contractors and to not have that become an open-ended revenue stream for a private company, how do you combat that in the relational model? To me, transparency seems like your best bet in order to be able to have a long-term, dynamic, changing relationship in terms of what government is expecting to get out of the contractors it's working with.

    I wonder to what extent an adequate level of transparency, in order to have the public be able to evaluate value for money, is going to be resisted by the very people who we would want to recruit under that model, and I wonder if any of you would like to speak to that aspect of the problem.

     I'll start. I don't disagree with Kirsten in terms of bringing in the right talent, although reports suggest that Canada has some of the most talented people within the public sector, with more than 60% having university or college degrees. We've got a ton of smart people who really want to work.

    What we are lacking, I think, is.... It's a cultural issue, and in all the discussions I've been having for the last year around government procurement, as we start to chip away at the specific issues, it comes down to culture. Because of very prominent failures that we've had —a lot of them on the IT side, so it's part of the role ITAC continues to have in this conversation—the industry wants nothing more than to have a successful implementation of their solution with the federal government.

    The question then becomes, why are we having so many failures? You have a high level of risk aversion and everybody's right: we're not setting the problem statement at the front end. We're not setting the outcome and the goal. What government tends to do is to prescribe the technology that they want. If that's going to work, you have to believe that they're prescribing the right technology.

    What they can't do is access innovation when they do that, because you cannot, in a procurement process that takes 18 months, two years, three years, access innovation. You're telling an industry that has all of this expertise what exactly you want to the nth degree. How do you tackle that side of the equation when you have an environment that's set up as abundant silos throughout all of the departments, and a command and control regime? It's top down, it's command and control, and people are told what to do. If you have high levels of risk aversion and high levels of command and control, you won't be able to address that cultural issue.

    What you need to do is to have a little bit of leadership and vulnerability at the highest levels. If you have this problem, and your expected outcome or goal is here, you need to have a little bit of trust that you're going to partner with the industry to be able to head towards that outcome together. However, we have a high level of distrust. At this moment in time, risk aversion is at an all-time high, and we have a high level of distrust between the private sector and the public sector in the government. It really is going to come down to whether we just go about addressing the procedure and process elements, or whether we start having an honest conversation about how to address this cultural issue of the traditional client-vendor relationship, with the government trying to keep everybody at arm's length and trying to drive down to the lowest possible price, but it's not a negotiated partnership.

     On your issue of transparency, there are ways to make sure that you can level the playing field in terms of the information available: contracts, all sorts of procurement documents, all of the outcomes of previous levels of work. If you set the expectation up front that it's going to be publicly available, or at least available to the qualified bidders, it does help, coupled with the fact that the business owners need to be out engaging the private sector around what they need and make themselves accessible.

    People hide behind walls. It doesn't mean that it becomes a cozy relationship, but if two people can't talk about what the issue is and what they're trying to do.... Once you can do that in an open way—and there are formalities that you can do to make it all above board—trying to open the tent a bit wider and having more open discussions with people will bring everyone up to the same level of knowledge and let them compete.

    You then start to avoid “only so-and-so knows”. You open it up and try to level it from a knowledge perspective. It's particularly important if you're going to be renewing contacts or rebidding work over a certain period of time.

    Do you think that's something industry is really interested in or willing to do?

    Yes.

    Thank you.

    Go ahead, Mr. Peterson, please. You have seven minutes.

    Thank you, Mr. Chair.

    Thank you, everyone, for being here. It's almost an all-star cast. Most of you have been here before. It's like the TV show, Celebrity Survivor. Everybody comes back for the last round to see who still goes on.

    I'm a celebrity. Get me off the committee.

    I appreciate how you've taken your time to be here with us again today.

    There is so much in common. Everyone is coming from a very similar perspective. There's not much daylight between the opinions you guys are expressing today, and that means those opinions are heard a little better on this side, because there is some corroboration.

    Mr. Leduc, you said that there are a ton of smart people in the public sector, and over 60% have university degrees. That leads one to think there must be a problem with the culture. Maybe it's not a problem, but maybe the culture needs to be improved or changed, or let's say “adapted”, without trying to put a negative spin on it.

    I was taught when I was studying that if you want to change behaviour in an enterprise, you have to measure and reward the behaviour you want. Is part of the problem that we're not measuring the right things and we're not rewarding the behaviour we want? Isn't that what it comes down to?

    I'd love to comment on that.

    You're 100% right. There's no downside for not making a decision, and there's no downside for making the safest decision. There is no upside for experimenting, so we do have to create the ability and the incentives so that people are actually able to experiment and over time can experiment on bigger scales. However, right now it's status quo, doing nothing. Sometimes you can do that all day for the rest of your career.

    You're right. Where are those performance metrics that link performance to the outcomes we are trying to achieve?

    As well, it's to create a safe place. Not every experiment is going to be successful, but let's try for that first viable product. Try things, iterate, be agile. Agility is all based on failing fast and failing small, and that has to be okay, because then you'll get better at the bigger things. That's a key point.

    I'm happy to hear other people's perspectives.

     There's a culture of big in the government, which means that any time we do anything, it has to be big. As a result of that, there's a great fear in the bureaucracy. The more we can tone things down to much smaller chunks and allow for some failure in the smaller chunks, the more the fear goes away.

    There's fear and distrust in the public service. There's not a lot of change. It's a risk-averse culture. There's some work to be done to build the trust. The way that has to be done is to have some consistent leadership, with very clear outcomes, and then going with very small implementations that aren't prescriptive and that allow the downstream teams to make the call.

    There's so much oversight now. That's another part of the distrust: there's so much oversight. There's oversight on oversight. There's oversight in my stovepipe, and there's oversight from three other stovepipes over there. All that is constraint. All that is overhead. Knowledge in the organization is at the bottom of the stovepipe right across, and don't forget that I'm at the bottom of the stovepipe, in stovepipe number five over here. I'm knowledgeable in five, and I speak the “five” dialect. It's a little different dialect than maybe the legal dialect or the procurement dialect. I'm in the IT, and I talk about IT stuff, and people don't understand me. When those teams come together, we get communication. When they don't come together, I have somebody who's perceiving the world from his perspective, and he perceives the solution of the problem that way. It goes up through the hierarchy, and as it goes up it's filtered, and it gets skewed. By the time it gets to you, it can sometimes be bizarre. Then what happens is they say to you, “Well, now you have to make a decision.” Am I resonating a bit with you?

    An hon. member: Hear, hear!

    Mr. Dan Murphy: You have to make a decision. There you are. You're in a situation. You're at the top of the organization and you're getting all this information that's coming up, and it's not the information you need to make an informed choice.

    The first thing is to create a cross-functional team that brings all these dialects together and forms the United Nations of how we create a solution in your organization. That team down there needs to talk to you directly, not through seven filters, and say, “Hey”, and that team needs to have authority. “Steve, I need you to clear the path.” “Kyle, I need you to get this thing solved” if it's the DM or whoever. It has to go sometimes that high.

    Right. Good.

    I have a bit of time, Mr. Chair?

    The Chair: Yes.

    Mr. Kyle Peterson: Okay.

    Mr. Akrouche, picking up on that point, you mentioned there's this dynamic between oversight and insight. I think that's how you put it. We all agree, I think, that at least some oversight is necessary, but not at the expense of insight. Can you elaborate on that?

    Coming back to the question about an open-book framework, transparency is really key to this. The whole thing is really about openness and transparency. Without that, you can't gain that insight. To gain insight, you need to have mechanisms to gain that insight. You can't gain that insight by standing behind a wall. You need to be working with your partner in some form, within a structure, using a set of processes to be able to gain that insight. You're not going to gain that insight through an audit process. In fact, the audit processes that we've seen in the past, that are embedded in all those contracts, even added more fuel to that adversarial fire. People come in and do an audit, a technical audit, or this or that. A lot of these contracts call for that.

    Gaining insight gives you the catalyst or the platform to be able to adjust what you want to do and understand in a mutual way what needs to be done and how you're going to do it, because you didn't have that certainty in the beginning. You need to gain that certainty over time, and you can only gain it if you work together in a collaborative way.

    Thank you very much.

    We now going into our five-minute rounds of intervention, starting with Mr. Kelly.

     Thank you.

    My questions or comments are in a similar vein. I would like to start with Mr. Akrouche.

    You mentioned the problems associated with compliance-based oversight. That phrase sort of caught my attention. I'm aware that in many organizations or many industries, compliance overtakes the actual result or goal.

    This isn't just limited to government. Even in private industry, when one becomes so seized with the simple act of “butt covering” by complying with a regulation or complying with internal corporate requirements, actually serving the customer—or serving the public, in the case of government—is lost.

    At the same time, Parliament exists to oversee and authorize the expenditures of the government, so how do you reconcile the problems of compliance-based oversight with the necessity of oversight?

    We shouldn't confuse two things, compliance and performance management.

    You need to have a good performance management system in place, but compliance-based oversight has always been, “Okay, you've signed the contract, and there are these 25 KPIs. There are these things you're supposed to do, and all I'm going to do right now is sit and watch you do that. If you don't do that, then I'm going to report that you didn't do that.”

    I'm not spending any effort, really, to try to improve the outcome as things change over time. Since I'm a watchdog, I'm just watching to make sure. I'm going to hold your feet to the fire, and all this other stuff. It's a very non-collaborative approach.

    In a good relationship management framework, you would see a good performance management component to it. You need to have KPIs. You need to have those metrics. You need to have them as targets so that you can both work together towards achieving those, because when they fail, you fail too.

    Together, you need to really realign those KPIs from time to time, and that's the problem with performance-based contracts these days. They tie the continuity of the contract to meeting the KPIs, but everybody knows as soon as they sign that deal that 18 months or two years later, those KPIs are no longer good anyway.

    If I had a project, for example, and the Auditor General came in five years later to tell me why it went wrong after the project was done, my question would be, “Why didn't we bring him in on day one, ask him what the requirement was for compliance, and whether it was actually required?” Then we could have built those compliance requirements in at the very beginning in an iterative way.

    It's the same thing with government. A classic would be security.

     André and I have had this chat about risk. The risk in government is binary. It's no risk. Push the risk to the private sector.

    In the private sector, risk is dealt with through an actuary, and they put a dollar amount on it. Can we do that in government? I don't know, but risk and that kind of thing is very challenging.

    Compliance we can do, though. Compliance we run into in the private sector, and we just bring the people in on the team. Instead of being the road blocker at the end, they also have to pursue the same goal, not to stop the project but to enable it and to ensure that it complies.

     You have less than a minute.

    Okay. Well, I'm still struggling for a solution that I can understand as to how we obtain this shift in mindset. Do you want to add something, Mr. Akrouche?

    Very briefly.

    Yes, I thought I'd provide a little bit of an answer to that.

    Really, you need to bake into your business arrangement a relationship and strategic management framework that addresses this, one that says that we are going to measure the performance of this relationship, and not just the performance of the vendor but the performance of the relationship as a whole.

    What does that mean over time? You need to align that as time changes. You need to have the mechanisms within your relationship management framework, as part of your contract, to actually do this. That's the answer. That's the right answer.

    Thank you very much.

    Madam Mendès, you have five minutes, please.

     Thank you very much, Mr. Chair.

    Thank you all for being here.

    I'll follow this conversation about where to take into account the accountability and the performance measure. Would your suggestion, Ms. Tisdale, about the SWAT team that needs to be created include somebody from the Auditor General's office, for example, who would be part of the compliance and the measurement process?

    That could work well.

    When we did it, we had somebody from the Ministry of Finance. We had to build the internal capability to look at risk differently, so we had them engaged, almost designated, on our team. We'd involve them right from the beginning around the inception of the solution. If it was the Privacy Commissioner, it meant various risk things, and we involved them from the beginning.

    The other thing kind of connects with the two points here. It is that the governors—the MPs, the cabinet, Treasury Board—need to agree to what the outcomes are up front, and then allow the team to get there. They need to say, “Okay, here are the goalposts, and you have to come in between them. We empower you, as long as you stay between these two goalposts. Come back and tell us when it's done.” They won't have to go back and forth. You have very robust discussions up front about what the risks are, what the goalposts are that they're comfortable in. Then the team is delegated with all the right people to make it so, and then they come back and report how they're going to track that going forward. However, they don't have to come back. As long as they stay within the parameters that are agreed to up front, they're empowered to deliver.

    Go ahead, Mr. Murphy, please.

    They do have to come back, because when you say, “Go between these two goalposts”, that's your intention as a leader, based initially on what I would think would be a very challenging amount of data that you'll use to make that choice.

    Initially the leader will say, “This is my intention, to go between these two goalposts”, but when the team starts to execute, you may learn something. Maybe it's not those two goalposts, maybe it's these two goalposts over here, or there might be a slight deviation as you go. That's called learning, and that's the reason—

    Just for my understanding, when we're talking about goalposts, we're talking about the outcomes that we are expecting.

    Yes. You have a specific outcome you want to reach and you have this intention, but you need to exercise the team and go through an iteration. We usually run on about a 90-day window. In a 90-day window, we want feedback to come to strategy again to say, “Was my strategic intent correct, or do I need to tack the sailboat just a little bit? Am I right on and do I just keep going, or is this a stupid project, and we need to stop it because it's just not working and it just didn't make any sense?”

    You need to have that. That's where the de-risking of the project comes, because every 90 days there should be an out. You could have a long-term engagement for three years, but every 90 days there should be an out: are we doing the right thing? Do we need to adjust? Do we need to keep going, or do we just need to stop?

    That comes back to Mr. Akrouche's point about the relationships, and that's where I see it would be extremely important to have that.

    Mr. Leduc, I think you have something to say.

    I spent 17 years in the bureaucracy, and I've led some major projects. Undoubtedly, we have some of the mechanisms in place. We have interdepartmental meetings. We have central agency meetings. We have to go through the process.

    The issue, when you get to that table, is the interpretation of the policies and the procedures by everybody around the table. I'd say, “I have this project. I need to go in this direction”, and 19 out of the 20 people would give me reasons I couldn't do it, rather than how to do it. There are a couple of senior bureaucrats I've been discussing this with who are new to the federal portfolio, and they can't believe that there is this culture that just says, “You can't do it for this reason, for this reason, and for this reason.” The risk aversion is there, and it's at an all-time high.

     I started to challenge the process. I said, “This can't be right. I'll never get this done in a month of Sundays. I will never get this done if I have to comply with what everybody has said.” I started to ask them for the written rule, and nine times out of 10, there was no written policy.

    It comes back down to a cultural issue. We have done agile procurements in the government, and we've had success—not enough, but there's been success there. We've had multidisciplinary teams that work when there is a strategic goal.

    The Syrian group was an interdepartmental, multidisciplinary team that had a set of milestones to meet. It wasn't one department that was overseeing all of it. We had an interdepartmental working group. They moved mountains in months. They met targets, and it was really impressive.

    Government has done this, but the default culture is to avoid risk at all cost.

     I'm going to have to stop you there, unfortunately. You will have another opportunity though.

    For a five-minute round, go ahead, Mr. McCauley.

    There's some fascinating stuff here, a lot of issues.

    Mr. Murphy, you asked at the very beginning what we hope to achieve. It originally started out as a conversation around the SMEs. I've had a couple of very good conversations with our procurement ombudsman, but if you read his report, it's quite disheartening. Small business people encounter a lot of issues with the government around billing, mostly around difficulties with RFPs for procurement. That's what we've heard from a lot of our witnesses.

    To go back to that subject, if tomorrow you were head of the government, how would you tackle the issue of government procurement for our SMEs? Where would you start?

    The right answer to that is that I don't know. To give a prescriptive response and say that this is the solution—

    Ballpark it.

    Well, no, because I think it's a process. It's a process of direct engagement. As Andy was saying, it's about building a relationship. It's about the direct engagement, because the SME has to give me feedback on my bureaucracy. If that happens every three years, well, we're not going to fix it.

    We could fix it annually with the ombudsman's report.

    I'd say it should be quarterly, but in order to do stuff quarterly, you have to make it lighter. I don't need a 400-page report. I want a few pages. Also, I don't need a $3 million RFP. I need something under $100,000, maybe under the NAFTA limit, because that gives us more capability to manage.

    It should be a very small, quick procurement with small teams and direct engagement to get feedback so they can come back to you with a really intelligent answer.

    For example, “The ombudsman was right. When we looked at our process and how we did it, we have some flexibility here. We didn't think we had flexibility over here, but when we escalated it up, they said that we could bypass policy around that because the policy is not giving us the outcome we want, or we need to change the policy. We need to do something. Over here, is this legal? No, you can't get around that.”

    It's this ongoing engagement and feedback. It's not, “Hey, we're going to do a program across government.” That will be a failure for sure, because there are so many variables.

    That's fair.

    Mr. Leduc, do you want to add anything?

    It's simplification. At the end of the day, why are we still pumping out 200-plus-page RFPs for something as simple as Wi-Fi? Why can the government not procure Wi-Fi simply by saying we need a public and a private Wi-Fi that meet these 10 requirements? Why can't it be five pages long?

    It's because in order to avoid any potential risk of any kind, we mandate 78 different mandatory criteria. We mandate security up the yingyang rather than saying we need a public network.

    When you go to a meeting in 90% of the buildings around this city, you don't have access to Wi-Fi. They'll bring in industry, and industry will say, “We'd like to present this. What's your Wi-Fi code?” and you'll say, “We don't have Wi-Fi.”

    Why are we stuck in the Dark Ages? Simplify it. From an SME perspective, they're not going to spend three years on an RFP process, ever.

    No, and that's the feedback I've had as well when we've done seminars back in Edmonton and northern Ontario, but also here.

    Ms. Tisdale, would you comment?

    I think some of the rules around limitations of liability are also a real impediment, so just keep it very simple.

    We heard that a lot last week.

    The U.S. government is even doing things like paying for providers with a credit card. They're using reverse auctions. If they want some development done, they put it out there. You just go online and you bid for it. You get paid with a credit card. It's simple, simple and easy. There's no procurement process, just an online auction.

    Okay.

    It's all challenge-based procurement. In the U.S., there's a company called Wipro that used to be a software developer. They have a community of 1.4 million developers worldwide. They basically pull the challenges together through a portal and send them out, and they are bid on.

    We're out of time, but just getting back to the SMEs, from what Mr. Leduc and you were saying, simplification is the first big step we need to tackle.

    Thank you.

    Mr. Ayoub, you have five minutes.

    Thank you, Mr. Chair.

    What the Agile method does is very interesting, but I would like to look at the other side of the coin. You all seem convinced, but for my part, I have serious doubts. I feel some resistance to change. I am more and more comfortable with this idea of resistance when I read on the Internet that, according to some, the Agile method is a cancer that must be eradicated. That's what somebody said a few years ago, especially about the development of infrastructure, technologies, software, and so on. It has been said that this was a waste of time during the scrums and that nothing concrete came of it.

     That being said, from what I can see, you consider this method to be a panacea that we should have adopted a long time ago. You wonder why we did not do so, when the benefits are so clear. But I wonder whether it's not just trendy. Every manager needs measurable results, whether in the government or in a private company. They really need to have compelling results to prove to their shareholders or to the citizens, as the case may be, that they have made the right choices and that everyone is reassured about those choices.

    The idea of reducing the 400-page tenders to 10 pages is appealing, but it's certainly not that simple. I have worked in the field of information technology in the past and I can tell you that there are many details to consider. I would like to see WiFi, but we are talking about the Canadian government and it should be implemented from coast to coast to coast. Right now, we are in a vacuum, way up in the air, in a sense. Could you give me concrete, specific examples of how this method would change our lives as managers? You could tell us how long it takes to implement—three to five years, for example—and whether we need to hire adequate staff if our resources are insufficient.

     My question is very broad and I leave it open, but I need reassurance. I am still looking for solutions.

    In my opinion, the reason why the private sector is so keen on the Agile method is because it has significantly contributed to its success. Our banks, for example, which are very large companies, have found that adopting the Agile processes had a direct effect on the ability to save a lot of money.

    If we bring the whole team together from the outset in a room to make a decision, we avoid any problems that may arise. The idea is to bring together all the members of the team—lawyers, engineers, procurement officials, and so on—for half a day to determine our objectives and procurement needs.

    Was that not being done before?

    No. This is what makes things more challenging, even today. In the government, for example, when an operational unit needs something, it submits a request to the technology group, which then goes to procurement officials. They turn to the lawyers to see whether they have the right to proceed with the procurement. If lawyers conclude that it is problematic, the request goes back to the technology group and then to the operational unit. The process then starts all over again from the beginning.

     There was no meeting with the entire team in one room at the same time, and as a result, there are new delays when, for example, lawyers come back three months later, saying that there is a small problem and it is impossible to proceed. If that had been brought up at a meeting at the outset of the process, the situation could have been very different.

    Is it not a leadership problem to begin with?

    The leadership, not the method, is the issue. Whether it's the ISO 9001:2000 or ISO 9000:2015 method, the idea is to bring everyone together. We proceed step by step. However, I can tell you that everything is written down with ISO methods. This seems to be less so in the case of the Agile method.

    Do you want to make any comments, Ms. Tisdale?

     I'm sorry; I can't.

    Unfortunately, at this point we don't have time for an answer.

     Go ahead, Mr. Blaikie.

     I'm going to come back to the theme of accountability, because I'm interested in this problem. The language is great. If it's in the private sector and people want to take a certain kind of risk, then they take that risk and they are responsible for the consequences. In the public sector, you need a way of reporting on why you think it's a reasonable risk. You need some evidence on what you expect to get back for that risk, and you need to be able to quantify it for people.

    On top of that—and you guys can correct me if I'm wrong, because you're the industry experts—it seems to me that private companies relate differently to other private companies as clients, when they're providing services to other private companies, than they do with government. The partnership model within the private sector can work, but this model doesn't necessarily transfer to the public sector, because the public sector can be seen by some companies as an unlimited source of income. If you're building a relationship and you're on a team and you can lead some of those government folks on the team to think they need to go down one road a little more, or down another road, and in the end it doesn't work out, then you can just keep working at it, because the problem has to be solved and you're never going to run out of money.

    How does that affect the dynamic of trying to implement this kind of solution with a public sector partner as opposed to private sector partners?

    Go ahead, Madam Tisdale.

    That's a lack of discipline, and it's inexcusable. It doesn't matter whether it's private sector or public sector. An agile approach still has to be disciplined. In a way, it would reduce your risk, because after every 30 days or 90 days you have to prove you have delivered value. You have to prove what you're going to accomplish in the next 30 days. You either do it or you don't. If you don't, you probably need to shut it down.

    There is a lot more accountability in a process like that. You're clear about what you're going to deliver and you have to do it on regular tight intervals. This way, you can only go a month off the rails, whereas on an 18-month or five-year waterfall project, you don't know whether you're even close until the switch goes on. It has to be a disciplined process.

    People think agile is just making it up as you go along. It's not meant to be like that.

    In Winnipeg, we see some design-build contracts with the city where the make-it-up-as-we-go-along approach was essentially what it was, and it cost a lot.

    That's not agile's fault. That's just poor discipline.

    Colleagues, if there is a willingness, we certainly have enough time for three more interventions. Otherwise, we can go straight to committee business and excuse the witnesses. Is there willingness for more questions from the government side?

    A voice: Yes.

    The Chair: In that case, Mr. Jowhari, you're up.

    Thank you, Mr. Chair.

    I'd like to welcome you all back.

    By way of background, I've implemented a lot of large business transformations, whether focused on procurement, the human chain, or the supply chain. I have an extensive background in supply chain business transformations, and I'm familiar with a lot of the challenges that have been raised.

    Business transformations take on a life of their own. They could be up to five years. You break them into smaller chunks and you have projects. At the outset, you define your requirements. You establish a set of risks and you mitigate risk as the person who is overseeing everything, so that the challenges raised, whether they're prescriptive, whether they're rigid, are all valid.

    One of the points raised was along the lines of what I had done before with some success. It was the strategic fitness assessment mentioned by Mr. Akrouche. I'd like to see whether we can apply some of that concept to agile, specifically on risk management. At the end of the day, whether we simplify the process or make it collaborative and get the talent, government is going to make sure the risk is managed.

    Mr. Akrouche, can you tell us how to use this strategic fitness assessment to focus on prescriptive outcomes rather than prescriptive requirements? This would be a help in achieving a successful outcome at the end.

     The idea really stems from the fact that the vendor that is going to do the best job is the vendor that has its corporate strategy, its capabilities, its resources, its assets, its soft skills, and its management preference in a much better alignment with your stated outcome than the other vendors. The idea is to assess these against your strategic outcome.

    By the way, we talk about outcomes as if they're static. Your outcomes within themselves are not static, but maybe you have some target outcomes based on your current understanding of what you want done.

    The strategic fitness assessment is only focused on the vendor, not the group as the agile concept support that will bring the legal and the procurement officers, the business, the SMEs, and the vendor—

    No, it's not about that. It's not about how we work together. That's in the relationship management framework. The strategic fitness assessment assesses the....

    During the evaluation, how are you going to know whether this vendor is better than this vendor or that vendor, and in relation to what? In the past, we've used the rear-view mirror. We said, “You must have done this before somewhere else.” We used past experience as an indicator of future performance, which is not always true.

    What we want to do is be able to evaluate the ability of a consortium or a vendor to deliver on our expected outcomes. It's one thing to write a one-pager, but we need to be able to test their abilities, and it's not apples to apples, because they're not apples to apples. Vendor A has a different solution. This guy has an orange, and that one has an apple. You need to have a mechanism to be able to say that this apple is better than that orange for your outcome.

    Sure.

    I think it's agreed that it's people who deliver projects, not firms. It's going to come down to the 10 critical people on that team, or however many there are, so it's about making sure that you've spent the time doing your due diligence on the people, on the cultural fit, on the alignment of values, and on whether they're going to show up week after week. If they don't, then you may need to switch teams. I would really take a long, hard look at the individuals, not only the ones you're putting on your home team, but also the ones you're going to be partnering with externally, because at the end of the day, if you get that right, that's 90% of it.

    Mr. Leduc, you wanted to add something.

    There's a perception that industry is constantly trying to milk the public sector for funding. Vendor performance allows you to evaluate based on performance in past projects, and that should be taken into account when you're doing an assessment of a future project. The way we go about it now is that there is no vendor performance evaluation, so the same company that has potentially milked the government six or seven times gets a fair chance at bidding for the next one. If he has the lowest price, he wins.

    One thing I can say, having actually implemented source to procure to pay, is that a lot of the discussion we're having is more on the sourcing side, on making sure that we are really doing our due diligence during the sourcing. The procurement is actually the act of cutting a purchase requisition or purchase order and then measuring the outcome. Most of our challenges are on the sourcing side at the outset, making sure that we are ready to take on the initiative as a government, as well as making sure that we find the right partner through the proper sourcing. This could lead to the strategic fitness assessment and also an internal look at how we do it. Do we have the culture already? Do we have the talent? Is our process streamlined? What do we have as key performance indicators, or do we have a milestone with clear deliverables that we could measure?

    The teams should be lined up so that the incentives for your vendors should also be lined up with the incentives for your internal team. You're right that the sourcing piece is important. However, the stewardship after the deal is signed is where your value is either going to be created or lost. It's probably 40:60 or 20:80 in terms of effort, but very little effort goes into the stewardship of the relationship and the management of it.

    Mr. Murphy, would you like to add something?

    Give a very brief answer, Dan, if you could. We only have a few seconds.

    Sure. I'd just say that the most important thing in the evaluation process is that if you're doing an outcome-based bid, you can certainly derive a short list from that, based on evaluation criteria. After that, the most important thing is to implement it, especially in technology projects. Implementation is the validation. It validates everything—architecture, capability of the vendor, finances. The way we do contracts now is that the contract is signed and the validation is after contract award. That's like buying a house and then inviting the inspector in the day after to tell you that your foundation is broken.

    If you have a short list of four or five vendors and you have a very small.... If you take a payroll system, for example, take three or four small instances of a payroll system and put them in with three or four different vendors and see what happens, see what the performance is.

     Go ahead, Mr. McCauley.

    Ms. Tisdale, I want to get back to your work with that secretariat. Is there anything you would have done differently on how it was formed and how they attacked the projects? As a follow-up, if you were to apply something similar to the federal government, which of course is a much larger beast, how would you do it? Would you break it up into separate secretariats—one for PSPC, one for DND—or would you have an overall one?

    That was 10-plus years ago, so I think now I would have applied a little more of the agile approach in making the contracts smaller, because we had billion-dollar deals going on. That was the thing of the day.

    You'd have smaller contracts working up to larger ones?

    Exactly—scalable, the same without having to go back, but more flexible; rather than winner takes all, I'd have several. If you're doing workstation support, for example, have several vendors involved so you have the ability to move work back and forth, depending on performance. I would try to have a bigger ecosystem of suppliers.

    I tried very hard to get government to continue to invest in its ongoing institutionalization. They chose not to, at the end of the day, and I think they're paying for that decision, because they have to restart everything now. Make sure you're taking that knowledge and embedding it inside a government over time. Working on that stream is critically important.

    If I were going to look at the federal government now, and I think it's an enormous opportunity, I wouldn't try to replicate it. I would still start with a central group. Defence might have its own just because of its size, and then everyone else would have a centralized group.

     There's a co-accountability between the leader of that group and whatever deputy minister's running a project. If it's health, if it's tax, whatever, it's a dual accountability, so that both parties are dependent on each other for delivering it and getting it done.

    I would start with one central group for most of core government and I would make its use mandatory and I would give them veto power over the enterprise, because if it becomes voluntary, it won't get used. They need to be funded; they need to be free for the departments so that they're adding value to those departments, but the departments shouldn't have to be taxed to do it right. Then over time you become greatly in demand, but at the beginning, I wouldn't make it a tax on projects. I would fund it centrally, but I would make it mandatory.

    Mr. Murphy or any of you, how does agile survive a world of political interference with procurement projects? This is not necessarily directed at the Liberals, because our government was probably just as guilty as the current government. The only one not guilty, of course, is the NDP, because they won't be in government.

    We haven't been.

    But whether it's shipbuilding or other issues, can agile survive in that world where this is a reality, unfortunately? I wish it weren't.

    There's a choice. No, the political interference, if you call it that, creates a lack of clarity in the goal and creates confusion. That distorts collaboration. It doesn't matter whether you continue with the current state or you go to agile; if you don't have clarity around that, if you don't maintain it and have it consistent, it will end up being a problem.

     Of course, this goes back to the Ross rifle issue 100 years ago, and we still see it.

    Okay, that's all I have.

    We'll have time for a brief question from Madam Ratansi.

    Thank you.

    Thank you for being here.

    I've been listening carefully, and all of you have been talking about a cultural change. That's an interesting concept, because change management requires leadership to drive that change and then using change champions.

    As a deputy minister when you did the joint venture, what were some of the challenges you faced? How did you overcome them, and what are some of the lessons you learned that could be applicable to a larger environment like the government?

     There are probably three things.

    First of all, the first people to get on board were cabinet and Treasury Board. The leadership needed to be backstopped and supported there, because there was going to be learning going on, so I spent a lot of time educating and getting them engaged and getting them comfortable with the concept. Then at the next level down were my deputy colleagues. We spent a lot of time as a leadership team, and every one of those deputy ministers had performance measures tied to the success of that group.

    Again, it would have been very hard for me to do my job without the political support and without their being incented and committed to doing it.

    Then it was blocking and tackling, quite frankly. You would start in areas where you thought you could get some wins, and you would prove it out. There's nothing like success to get other people interested, right? So we carefully picked the first four or five projects or the programs that we went after, and we worked exceedingly hard to get them right. We got some wins and we got a lot of public support, and then it got easier to do.

    Some of the people who just weren't getting it got moved on, quite frankly. The clerk was 100% committed to it, and he was clear with his deputies what his expectations were. If people won't play ball or try to sabotage it, you have to make some examples.

    It was a bit of “We're going to try this, we're going to do it together, and we're going to support each other.” Then you work at people one at a time.

    That's the only way I've ever seen it done, with lots of support across the board.

    Normally when you do change management, the leadership is the top, but was there any instance when bottom-up ideas came? You talked about not everybody being bright and not everybody owning the ideas. If bottom-up ideas come in a public sector, how are they treated in a culture where the bureaucracy—deputy ministers and ADMs—are risk-averse?

    I think you have to get the right people in charge of the program, right? Alex Benay, for example, is working very hard at trying to get some things going on around innovative procurement. He needs some support and airtime. Involve people up and down the chain so you have some of those bright young sparks as part of the program, because the ideas can come from anywhere.

    If you put systems in place that allow you to capture them, and then you have some listening posts, that's how I would see it happening. However, it does require good, strong leadership that is open to the ideas, wherever they come from, and you need some processes to harness them. Cross-pollinate the teams from top to bottom, not just senior folks.

    Was there any poaching of your teams by anybody?

    Oh, yes. The teams were poached continuously. They were poached by other departments. They were poached by industry. They've gone on and they've worked for governments across the country. I'm not there anymore. We were all poached eventually, right?

    There's a reason I did it. There was a program that Anderson Consulting was doing with the provincial government in trying to get their shared services. Then they started poaching people, so there was no transference of knowledge. When there's no transference of knowledge, then bureaucrats.... You have to see where they are resisting change, because then bureaucrats say, “Okay, fine.” They're taking away our people and making us reliant on the IBMs or the Andersons of the world, or whatever.

    Well, I still look back at those four or five years as the best years of my career, because you can get something in the public sector that you can't get from any private sector organization, and that's the ability to make that kind of impact. You will find the people who are motivated by that. They can always make more money somewhere else—of course they can—but they're motivated by the ability to make impacts,. You'll nurture them and you'll grow them. You'll lose some, but you have to plan on that. You'll always lose some.

    Thank you.

    I have a question for Mr. Murphy, which you'll have to answer in 30 seconds, I presume.

    The Phoenix system, which is the elephant in the room—

    Good luck with this one.

    An hon. member: How can you answer that in 30 seconds?

    I'm down to 15 seconds now.

    No, no, I don't want to lose time.

    Your suggestion was to go small or to tell the company that this is what you want: 143 systems streamlined into one. How many people would have bid if they didn't have a 500-page RFP?

    I don't think I would have done a 500-page RFP.

    I know we don't like it either.

    I would say we want to do a system that pays people, a payroll system. Often, though, we end up starting with the solution. We say we want this specific solution. No, it's that we want to pay people, and what are the most important things? Well, they have to be paid on time, and extremely reliably.

    In government we have about—

     I guess the political interference was that we wanted savings, because if we streamlined this, we'd get $70 million a year or whatever.

    So now do we want savings?

    Think about it. Now that we've implemented, do we want savings? No. We want reliable paycheques that come on time.

    Consider all of the variety in the government on policy for all the different departments. RCMP and DND are vastly different. Everybody is vastly different. Maybe over time you wanted standardization, but again it comes back to what you are trying to get. What is it that you want? That clarity of vision up front is extremely important, especially in government.

    Then, as Mr. McCauley said, to have that interfered with politically really throws a wrench into the machinery.

    Perfect. Thank you.

    Thank you all again for being here. Thank you for your contributions, your observations, your recommendations.

    It's been interesting. This has been a fairly exhaustive study, but we're starting to get a fair amount of clarity and commonality about what all of our expert witnesses have suggested as the SME approach that the government should be taking. I'm quite confident that our final report, when it is tabled in government, will have a pretty clear road map of recommendations for this government, and hopefully future governments as well, when it comes to procurement and SMEs.

    Should you have any additional information that you think would be of benefit to this committee as we continue our deliberations, I would suggest that you make those recommendations directly to our clerk. I can assure you that we'll have them incorporated into our final report in some fashion.

     Once again, thank you so much for your contributions. You are excused.

    Colleagues, we will suspend for only two or three minutes and come back for a very quick piece of committee business.

    [Proceedings continue in camera]