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, 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.
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 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. 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.