OGGO Committee Meeting

     Colleagues, I would like to call the meeting to order.

    I have a couple of housekeeping points beforehand. You will notice the screens in front of you. We had been attempting to get split screens with both English and French versions on each screen. We haven't been able to do that, so some of your screens will have French only and some will have English only. Hopefully we can adapt to that. If you want a hard copy of the presentations, our clerk can distribute copies to you, if that would assist you, but I hope we can navigate the screens in the format that has been set up.

    Furthermore, colleagues, just in the essence of full disclosure, I should let you know that even though Mr. Murphy and I have never met before today, for the last several months we have been communicating. I was first introduced to Mr. Murphy several months ago. Through a number of exchanges from that time, he informed me about an approach called “agile”, a methodological approach to IT transformation in government. Of course, as everyone knows, it's a massive, massive undertaking.

    I was intrigued by what he had to say. Subsequent to that, I then forwarded some of his information on to the government—Ministers Brison and Foote—with just a brief précis of what I had found out about agile. I indicated to both ministers that if they wished to contact Mr. Murphy and pursue any kind of perhaps contractual arrangement to assist the government in some IT transformation procedures, they could go ahead and do so.

    I understand, Mr. Murphy, that you are now doing some work with the government.

    I just wanted everyone to have a background of where I fit into this whole scheme. I do have a bit of a proprietary interest in Mr. Murphy's appearance here today.

    Full disclosure, right?

    Voices: Oh, oh!

    Full disclosure.

    With those brief words, Mr. Murphy, I understand you have about a 10-minute presentation, following which I know we will have a number of questions from all my colleagues. We have about an hour and a half set aside for this presentation and our Q and As.

    Mr. Murphy, without any further ado, the floor is yours.

     Thank you, Mr. Chair and committee members.

    I've been in government and around government and IT for 35 years. I spent about 10 years with IBM, then 10 years with Cisco, and for about the last 10 years I've been consulting. I kind of go in 10-year increments.

    I won't go through the deck in detail. What I want to do is tell you a few stories about how I came to the beliefs I have today and how we can transform the federal government.

    Back around 2000 or the late 1990s, I'm at Cisco. Cisco's doing 1,200 projects per quarter, and they have a 4% failure rate on their projects. A project can't be more than $500,000. If it's bigger than that, they break it up. For projects at Cisco, the whole initiative at Cisco to move to this kind of agile, iterative approach was driven by the CEO. It didn't come from the bottom up, it came from the top down, which is why I'm here today. I believe that this needs to be driven by the political level. Political staffers, DMs, ADMs, and DGs need to understand this in order to lead this kind of initiative correctly.

    In any case, Cisco had a 4% failure rate. A failure was defined as two weeks late on 90 days or 10% over budget on 90 days. The project I'll give you as an example was led by the CFO. He felt it would be good for Cisco if they could make executive decisions more quickly. At the time, they were closing their books in four weeks, and the CFO, not the CIO, said, “If we can close the books in two weeks, that will give us strategic advantage.” So Cisco started on these $500,000 quarterly initiatives in increments, and after a year they got it down to two weeks. The CFO said, “If we could close the books in one week, that would give us strategic advantage.” They kept pounding away for another year and a half to two years. They got it down to one week.

    Today Cisco closes its books across 130 countries daily. The strategic advantage is that whenever anything happens in the marketplace, they can quickly take advantage of it.

    You may say that can't happen in government, that government's not Cisco, and I agree that it's not. However, circa 2005 I was consulting at Public Works. Public Works was the predecessor of Shared Services. Public Works wasn't a monopoly. It had to create a service, and the service had to have defined value, which is one of the “win themes” you'll need for Shared Services.

    I put together a team of five people with the right leadership, DG and ADM, and within two years put together a service, a high-speed network service, that was 100 times more price-competitive than a commercial service from the telcos. I did that in government, with government people. Later on, I did the same kind of thing in telepresence.

    So I know that this is possible within government. There are lots of pockets of agile projects happening today in government. However, what they need now is portfolio-level and executive organizational-level leadership. There's a very different kind of of mindset around “agile” and the way you think. Agile is not something you can buy. It's not a piece of software. It's how you think about doing projects.

    Instead of thinking I'm going to do a $50-million project—those are a writeoff—I would set policy in the government saying that no projects can be larger than this amount. I can have a long-term vision like Cisco did to close the books in a single day, but on no quarter can I exceed $500,000. They're too big, too massive. At the initial point of these projects, which are very complex, the current state approach is to understand everything up front. We're going to do a plan. The whole system of government says, “I need a plan because I have to budget and I have to procure,” so they go through a three-year process of creating a plan. The plan is not a 10-page plan; the plan is a 200-page plan. The plan turns into an RFP, a 200-page RFP that articulates in detail how we are going to do Phoenix.

     That is impossible. You cannot write a plan, in the complexity of government and IT and technology today, which is changing.... At Cisco they said that one year is seven years. That was in 2000. The world is changing far too fast. By the time you've created the requirements and definition that says this is what I want, it's a two-year exercise.

    Effectively, the government is taking two to three years, they're creating documents, and they're not testing or validating any of the detail in the plan or the documents until contract award. After contract award, we start to implement and we go, “Oh, my God, I never saw that. I didn't realize this little detail was important.” But it is important, and they completely mess up the projects.

    The average $40-million project will come in at two to three times the budget and two to three times the schedule. That is not a Government of Canada statistic. That's industry-wide, global. If you try to do these big massive projects up front, and have all the planning material in detail, and they're large like that, you will come in at three times the budget. If you look historically through the Auditor General's reports back to 2000, you'll see all the large IT project failures in the federal government.

    I don't want to focus on that. All I want to say is that there's another way to do it. The way this agile approach works is that small teams of five to eight people, in small segments of time, work on a project. They are not to write documents and create how they're going to do something. They want to implement, and they want to implement immediately. If they make a little mistake on the $500,000 project, that's called learning. On the next iteration, in the next quarter, they're not going to make the mistake again.

    That's a lot better than three times $40 million. Three times $40 million, three years late, is a lot.

    In an agile project, we recognize up front that we don't know everything. Our first thing is to find out what we don't know. We know that the only way you can validate on a project, especially an IT or technology project, or a complex project, is to implement. We mitigate risk by implementing small, with a very tight time frame, so that we learn up front about our mistakes, we feed them back in, and then, as we move forward, we get better and better. There's a whole piece here around the HR component of government—building capability and capacity internally, and building up skills.

    A lot of this stuff is happening. If you do look at my slide deck here, I have a slide on JTF2. JTF2 was an agile team, and they're probably one of the best in the world. They follow all the principles.

    Turning to the next slide, there are three levels that we designated. At the project initiative level, which is the bottom level, there are agile projects happening and going on. At the program/portfolio and organizational level, that's where we believe the gap is. What we're missing here, I think, at the first step, is education at this level.

    I'll just go down a bit more to this next slide, titled “Call to Action”. I don't want to take all your time, but everybody's in the boat. This isn't something you can delegate and walk away from. It's something where everybody has to get engaged.

    The reason I came in front of the committee today was to ask for engagement, to ask for engagement at the political level and at the EX level across government. That's the real call to action. I was specifically interested in talking to this committee because it's an all-party committee. The effort that's required for this will go beyond the election window, so all parties really need to understand this.

     It is even about your own political viability, because it's very difficult to implement programs in the federal government without the capability to implement your project or your initiative. At the top is program delivery, in the department, and below that are a whole bunch of infrastructure components. One of these is Shared Services, another one is procurement, and we have HR and finance. Everything comes down in program delivery to getting resource out of those things, and they become bottlenecks.

    You know, in terms of the leadership approach for this, leaders in government and anywhere in any organization should never tell their organization “how” to do something. They should stay focused on “why”. Why are we in business? Who are we in business for? Let the organization and the team figure it out through small iterations. Once we get into how, we get far too prescriptive, and all our thinking and all our psychology around how we approach business is around very prescriptive detail.

    I'll give you the example of policy directives. In my opinion, I don't think there should be policy directives. They're too prescriptive. I have a whole organization following rules instead of trying to drive value. The whole thing is why are we in business? We're in business for citizens. What do we have to do for them? We have to drive value.

    The stuff that Treasury Board is starting to do now is very good. The Honourable Minister Scott Brison understands it. He took the two-day course, and when he came out he said he thought we had to change everything. I think he's right. We're not going to change it in a big project, we're going to change it in small increments. If you try to do it in a big project, it will fail.

    I don't want to blab anymore. I'd like to get some engagement and questions from you guys.

    Thank you very much. I appreciate your economy of words. This is a huge undertaking.

    We'll start with questions from the government side.

    Francis, you're up.

    Thank you, Mr. Chair.

    Thank you, Mr. Murphy, for coming to share some of your thoughts with this committee.

    I want to circle back, and I'm curious to know your thoughts. I remember a pre-Shared Services model, where there was a Shared Services but it wasn't mandatory for departments. Then 2011 came around. I think August 4 there was an order in council, and Shared Services was officially created. Two years later they had the email, they had the data centres and the networks, and then two years later they had the workplace technology devices; they were dumped. There were a lot of responsibilities for an organization that hadn't accomplished anything yet. A lot of the role was just keeping the lights on, to start with, and transferring T-shirts over to other employees.

    I want to talk about the readiness of departments. We've heard this from previous witnesses. Some departments were ready to implement email transformation. Some were not even close to being ready. In your model, how would you have addressed that, understanding the readiness of departments? They were responsible for I think 43 departments at the time. We've heard from a former CIO that his department was fully on board, but other departments were not ready. How realistic was it for the email transformation initiative to happen so quickly? And as we learned from the Auditor General last year, the capital budget was cut early on in the process as well.

     Let me go back to SSC and some fundamentals around SSC. I don't think the model was correct. However, let me give you an example. SSC is like 43 automotive companies. They all have their own manufacturing set up, all in different locations, all with different people and different processes. They all produce their own car. It's a good car. The car does the same thing: it gets people from A to B. Very good. Now you do a merger. In the private sector a merger is challenging. In government it's really challenging.

    So you do a merger of 43 automotive companies, and then you say, “We want you to produce one bus that's going to be shared.” Who's going to get the job? What manufacturing centre is going to get it?

    We had this conflict. It's been structured into it. I'm not here today to blame anyone in particular in government. The issue that we have around this is systemic, and the solution that's required is systemic.

    As for email, why did we do email? What value did we want to derive from email? I was on the initiation process of the email project, and it was unclear.

     Yes.

    We were told it was to save money, but there were no money savings in it. Then they went in a big swoop, and we've being trying to understand the details. You could see where the problems were going to be. Again, they got way too prescriptive.

    We would go back and say, “Why are you doing email? Why do you want to consolidate email? Can you not communicate today? What's the reason? Is it just that you want to have the end of the email the same so people can find you?”

    That's the part that doesn't happen in government. The “why” part doesn't happen. What happens is that everybody jumps to “how”, and that becomes problematic. At a leadership level, it's extremely important to stay focused on the why and the who. Who was Shared Services set up for?

    Yes, but we have examples where a different shared services model worked. In Ontario, for example, they switched emails very easily. They had no major problems. The difference that we've learned, again, from testimony by David Nicholl, is that he spends most of his time thinking about the business of his CIO community. I am not convinced Shared Services does that on a regular basis—understanding what the business of their CIO community is.

    Do you find there is some truth to that?

    There is some truth to that. I think there was mixed messaging on the structure of SSC when it was set up. Part of the messaging was that we need to standardize everything. If you are all my customers and you are all on different systems, and I need to standardize something, well, what's more important—for me to give you the service or standardize? There was a message there, initially, saying that we need to standardize. There has to be some clarity around why. Why does Shared Services exist? Is it to standardize? Is it to create good service value so that departments can deliver programs that they want to do?

    It's clear now that there is a traffic jam there. There is a constraint there. I think there should be some clarity around why.

    I have another question I want to ask. You talked about getting good at making small projects happen. I've heard a lot from the IT community, especially the SMEs, saying that they can no longer participate with the Government of Canada, because the Government of Canada decided to go with prime contractors.

    Part of the rationale back then was to say that we want to save money on procurement. We don't have to deal with a thousand SMEs, as opposed to just one guy or five prime contractors. Small contracts are going to increase the costs of procurement, probably—hopefully not, but it would be a bigger management issue for the procurement branch at SSC to deal with multiple contractors.

    What would you say to them? If we all agree today and say that we're moving with agile, but they come back and say that it's going to increase the costs of procurement, how would you respond to them?

    If you could possibly do that in about a minute, I'd appreciate it.

    They are managing my time.

    Voices: Oh, oh!

    Procurement is another constraint. It's a bottleneck, because I'm asking them to manage a 200-page RFP, which takes, on average, a year and a half to create.

    We don't have to do RFPs that way. We don't have to specify how exactly everything is going to work. We have to say, look, Shared Services wants to create this desired outcome. That's what I want. Now tell me how to do it. You tell me, in the bid, how to do it. I'm not going to tell you how to do it, because I can't get all the details. You tell me how.

    Then, you know what? Instead of awarding it to one, let's award it to a couple. You can come in; you're so smart, you've told us how we can do it, so now implement it. But don't implement it for 350,000 people. Implement it for 50 people. And we need you to do that in the next three months. I might have three vendors that are short-listed doing that.

    I love all the vendors. I think they are wonderful. But I wouldn't believe them. They can't look at a prescriptive RFP and actually bid on it and know what's going to happen, so they try to contain the scope. If they don't bid, they are out $40 million for 10 years. So they have to bid, and then they get in this situation. Of course they know that as soon as they bid, they are going to be in change control right after the tender is let. They're going to say, “Well, you didn't specify that.” The government, every time, says, “Gee, so how much does that cost?” It's $300—or $3 million. That's because you can't get it all, right?

     I think we'll have to stop there.

    It's a good conversation, and Mr. McCauley may want to pick up on that. I'm going to give everyone a little bit of latitude just because of the subject material here.

    Mr. McCauley, please go ahead.

    I appreciate it.

    Yes, it was a great direction that Mr. Drouin was taking us in. Just sticking with, say, Phoenix and Shared Services, we know where we're at. Without pointing fingers, because we could do that all day with each other, with them now both being in trouble, could you use agile to tackle the troubles that we have right now with Phoenix and Shared Services? Walk us through “agile for dummies”, on how you would do that.

    I have 50 other questions, so perhaps you can do that in, like, 30 seconds.

    On the question of Phoenix, I'm not sure if agile can save that. I'd have to look at it in more detail. However, I would say that there may be another 20 or 30 projects in queue that are large projects. The correlation of large projects to failure is more than 85%.

    Higher with government, I'm sure.

    It would be good to review any large projects in queue, which is part of my recommendations. Review anything large and say, whoa, if you're digging a hole, stop digging. That's the first thing. But the Phoenix thing, the hole is so deep now....

    Right.

    What about Shared Services? We're in a similar deep hole, I think.

    Yes.

    Could you...?

     I don't think the current structure at Shared Services will lend itself to producing new services because the conflicts are so high. I think what you need to do is create another small, very small, organization, an agile organization, and that would be not more than 10 people. With five or six people, I rolled out effectively a million-dollar-a-month run rate business, a high-speed network. It took a couple of years, because I was in that organization, but if I had a small team, a very skilled small team that had authority to the right level to clear the path, then we could move pretty fast. Shared Services is in this conflict, though, where they have competing interests. They're well positioned to keep the lights on, but I don't think they're well positioned to create new services.

    Could we set up an agile team to start tackling some of those, whether it's the email transformation or the others, and tackle it bit by bit over the years?

    Yes, there's a very small subset of services that are holding up the whole line.

    Getting back to procurement, we look at something like shipbuilding at $60 billion, $50 billion, and you talk about $500,000. The RFP is going to be 40,000 pages long, and we're still going to get sued because we left something out.

    Yes.

    How do we use agile to address issues with procurement? The ombudsman report for procurement just came out. If we don't have enough details, the losing bidder sues us—i.e., you weren't fair. How do we use something like agile to get around that or address massive projects like the shipbuilding or purchasing—

    The shipbuilding ones are a little tougher, because there's a certain amount of capital commitment that's required to build a ship, but in most technology projects there's not a huge commitment of funds, especially these days, with the services that are available monthly, by the hour, or by the minute. You don't have to spend millions of dollars to get things done.

    The focus needs to be around value. How do we create value, and what does value mean? You need to work backwards from there. You start with value, and then you say, who's this for? And then after that it's, okay, so what's our capability and capacity? Can we actually do this? You have to start small, and you have to start incrementally. This program is not going to happen fast, but it will create value immediately. It just won't do it on a large scale. It needs to be scaled, but capacity needs to be built first—in education, understanding, and leadership capability.

    You mentioned that Cisco started with $500,000 projects.

    Yes.

    Do you know what they're at now? What would you suggest for government if we could wave a magic wand and we could roll out agile today? What would the value be at for government?

    Yes: $250,000 to $500,000 over a 90-day period and not more. Not more than that because you can't spend that much more in 90 days. What can I do in the next 90 days that produces value? That doesn't mean I'm going to produce a requirements document or an RFP or some document or study. We're going to implement something in 90 days. We're going to implement it with 10 people. We're going to implement email with 10 people and see if it works, and see what the issues are. The issues quickly rise to the surface when you start to implement.

    The standard approach—and I've been in this situation—is a team of people sitting around in a room, going, “I wonder what we really need there. I don't know, but we've got to get it done. We have to finish this document by the end of the month. Okay, well, let's put something in.” They fill it with assumptions, and the first test of assumptions is at implementation, which is too late, because the implementation is always after contract award.

     In your experience, have you seen other governments, whether provincial, municipal, or out of country, successfully using agile, or a version of it ?

    Most countries around the world now are starting.... Well, a lot of them have already been at it. The U.K. has been at it for four or five years. The U.S. has been at it: same thing.

    With regard to the U.S. or the U.K., where did they start? Was it a whole-of-government rollout, or did they focus on one department? I'm just trying to think of how we would do it with ours.

    TBS brought over Olivia Neal from the U.K., who did a lot of work on theirs. They set standards and stats for project management and portfolio management. That was good, and it's good that they brought her in, and it's good that they are starting. However, I think the starting point is executive leadership, education, and understanding so that they get their head around what this is, because it's a change in how you approach a problem. If you don't understand how to approach the problem in a different way, you will drop back to the “how” we're going to do this, and all the details. Then you're into multiple documents that nine times out of 10 are not correct, and they are expensive when they are not correct.

    Who's the gold standard right now? Is it the U.K. or U.S., or who?

    The gold standard in the world is Amazon. Amazon has 1,000 teams.

    Sorry, I mean for government.

    For government, the U.K. is pretty good. Estonia is small, but Estonia is quite exceptional. They have looked at everything from policy down, and it's been a very pragmatic outcomes-based approach. Estonia is a good one to look at. They are going to be at the “forward 50” show, FWD50. Someone from Estonia will be presenting.

    The thing is that it's really doable, and it's a systemic solution that needs to be applied. It's going to take some time. It's an evolution, it's not a transformation. A transformation, again, is that with “we're going to do a big project”, just don't go there. That would be my recommendation.

    With government there are big projects.

    Yes.

    Do we just break them down and break them down to a slew of small ones?

    Yes, break them down until they are $500,000 or less.

    Okay. Thanks, Mr. Murphy.

    We have to stop it there. Again, I'm giving a little more latitude, but I'm sure these questions will continue.

    Mr. Weir, it's up to you.

    Well, perhaps great minds think alike, because I was going to pick up more or less where Mr. McCauley left off and ask if there are any projects that are dealing with such large interconnected systems, or where economies of scale are so great, that agile would not be appropriate.

    I think if you're looking at something where you need a large capital investment, it's going to be difficult there. Those are risky. Any time you have to bet the farm, it's risky. I would say that, unless you really have to, stay away from “bet the farm” projects as much as possible. I would have to look at the detailed context of the project to give you better advice on it, but there's so much you can do with what's in queue and what you have on your plate today to apply this approach and this methodology.

    If you're doing a project that you have done a million times and it's going to be exactly the same, it's complete cookie-cutter—you know, it takes two days and it's two cups of flour—you put that in and you're going to get that outcome. But nine times out of 10 in government projects today, and with the complexity of the world today, you can't do that. You can't see that.

    It sounds like what you're telling us is that essentially any big government IT project could be broken down into smaller chunks that would be conducive to agile.

    I believe it must be. It should be policy, I believe, that projects should not be large. They should be broken down into quarterly increments. You can have a long-term goal like Cisco did to close the books in a day, but realize it might take five years.

    Sure.

    Now, if you're the executive, and you say I want you to close the books in a day, and you have a year, you're going to create a real problem, because they don't know what their capacity and their capability is. They have to kind of go through this process of getting empirical evidence, what you would call “substantive”, but substantive can only be gained from actual implementation. These projects go to contract with indicative estimates, and they are really expensive.

    When Mr. McCauley asked you about using agile to fix Phoenix, you expressed some doubt. To ask you a more hypothetical question, if someone were trying to implement something like Phoenix using agile, can you talk about what that would look like, starting from square one?

     Absolutely. There you would start to do a payroll project, and you would implement the payroll project with 10 people, at one department. You would uncover some learning, and then you would apply that to the next 20 people. After a while you'd say, “I think we've got this. Let's try another department—maybe the RCMP. They're a little different. They have some security rules and stuff. Let's try 10 or 20 people at the RCMP.” And so on and so forth.

    You can see it in the team, because the team will start to say, “We've got this.” But in the traditional approach today, the team's going, “We're in big trouble.” They don't want to say anything because they have a deadline. They've been told by their superiors that they must do this and by that time.

    The leadership approach is to clear the path. I want you to implement a payroll system. Come and see me when you have anything that gets in the way, and I will clear the path. The leadership approach is clear-the-path leadership. It's not “this is how you will do it, this is when you will do it, and this is how much it will cost”. When you do that you're setting artificial boundaries and constraints on the project, and the team doesn't know yet. The bureaucrats know that they don't know, and that's just called stress.

    In general with these government-wide IT projects, you think it would make sense to roll them out department by department, or agency by agency. That would be a logical way of breaking them up into more manageable chunks.

    Incrementally, for sure. Again, I won't get into the “how”. I'm going to leave that to the team.

    Sure.

    The goal I want to achieve is a payroll system for the federal government. That's where I stay focused as a leader. Then the team comes and they say they're going to try it with these 10 people, and I say, “Great. Tell me how it goes.” Then they say, “This is a problem”, and I say, “Let's clear that out of the way for you. Now go and do another 90 days.”

    The increments in agile projects are often done in a two-week period, but where we actually release something of value is usually in 90 days. In a 90-day window, I would do the same kind of thing for the government that Cisco did. I would have multiple projects running in parallel, and they would sync up on the quarter. The other thing that happens in IT is that there are a whole bunch of projects that are prerequisite and co-requisite. You start doing these projects and you find out you need the Shared Services server for all of these. Well, then, the Shared Services server project needs to move up to the top, because it's the constraint. Then you start to move. So the quarterly sync, if I can call it that, is extremely important.

    I don't want to get into the weeds here. The important thing at this level, this committee, is the leadership style and approach that agile represents, and the agile principles that you would find in the deck in terms of JTF2. JTF2 is right inside DND. They did that because people are dying, and they need to save their guys as much as possible. It's a small, cross-functional team. They're empowered. They get a plan when they go in, but the plan is that the guys will probably be shooting from the north. If there are guys shooting from the south, there's no plan for that. In the field those guys have to be ready; they have to adapt and make their own plan. They have to be capable of doing that. That's what the government needs to do. It needs to become adaptable.

    The other thing that's major here is the cyber-threat piece. The cyber-threat people are adaptable. They're agile and they're adaptable. They're small teams. They're moving away from government in their capability. They're accelerating.

    So we're falling behind, and that's scary.

    Indeed. You've talked about the idea of establishing a small agile team within the government. I'm struggling a little bit to imagine where it would fit in Shared Services or in executive government more generally. Do you think there's a case to be made to have an IT commissioner who might be an officer of Parliament with a small staff?

    I'm not sure about that. I think the most important thing is that vision is set and the “why” is clearly laid out and understood and agreed upon, as well as who we're doing it for. Is Shared Services in place to create a standard, or are they in place to provide service to departments that are providing programs to Canadians? I think it's the latter. Let's start with that. What do we need to do to get that outcome? Instead of “you will do this, and you will do that”, we should be asking what we need to do to get the outcome. Let the team come back and say what they need, and then clear the path.

    It's really a reversal, which is why this mindset thing is what agile really is. It's changing the way you think. It's not something you buy down at the store. You know, I'm nervous about it coming out and being misinterpreted.

     Thank you very much.

    Thank you very much.

    Monsieur Ayoub.

    Thank you, Mr. Chair.

    Mr. Murphy, I listened to your presentation carefully. I have read about your background, your work experience, and so on. My career was in telecommunications, and I worked in a Canadian company that is well known in the sector and that I will not name. A variety of project management models and standards govern the multiple ways of doing things, such as ISO 9000 and ISO 8000 certifications. Great sayings, such as “if you find yourself in a hole, stop digging”, have emerged. I completely agree with all that.

    However, the peculiarity of large projects is that sellers, designers, integrators and promoters of solutions provide options only for the entire project. Few companies, such as Cisco or IBM, are willing to sell only a portion of a program or project. They want to sell global solutions only, even if the projects require funding of $50 million or $1 billion. I'm sure of that. The approach is different if the project management model incorporates ways to bring the projects to completion. Project management is a major undertaking, and there is no quick fix.

    So I am wondering about the Agile project management model, which has been around since the 1990s, as I understand it. Quite frankly, in my short career of just around 20 years in telecommunications, I have never heard of Agile. Perhaps I was following another school of thought, or we had to manage other types of projects. However, we managed small projects that were part of larger ones. In a way, the idea is to manage big projects by splitting them—that's not new.

    How does Agile differ from other models, apart from being guided by a particular management philosophy that is less focused on note-taking? We understand that the concept of paperless management unfortunately does not exist. Although, in practice, technology has invaded all our activities, paper is still very present. How can we be persuaded to trust this method? How can I be sure that this is not a trial and error process for larger projects, especially given the difference between private companies and the government sector? You briefly touched on the complexity of the projects, but I think there is a huge difference between projects undertaken by various companies and those undertaken by a government, particularly the sizeable Canadian government. Can you clarify that? You may not want to go into too much detail, but can you still explain how this management method is different from another?

    Yes, sure. There is a lot of stuff there.

    The large integration projects are the most complex. They are actually the ones that are at the most risk with the current approach. I agree that you can break them down into smaller pieces, but the issue is the latency from the beginning of the project. In government, if we spend three years collecting requirements, and the first time we actually validate requirements, design, or architecture is after contract award, then it's the most risky approach that you can take. If you have a huge government project, you can still implement it in small pieces. IBM could still get a big contract, or some big integrator could get a contract. There's no problem about that. But what I'm going to do in my procurement is that instead of spending a year writing requirements for it, I'm going to say that the outcome I want is this, and I'm going to invite vendors to come to the table, and we're going to start. Give us a plan in the next three months, not the next three years, as to how you're going to do it, and then at the end of that three months we're going to start to implement it.

    Vendors are spending millions of dollars on the procurement process and they know that it's wrong. If you go to the IBMs of the world, they'll know that it's wrong.

    Speaking of a large telco, I implemented a telecommunications service for Public Works. It took about six months to get the service together and put it out. We went directly to clients and asked them, “What do you want?” What's really interesting is that they will tell you. If you ask them directly, they'll tell you. First, they asked me, “Where are you guys from? You can't be from government, because you're actually asking me what I want.” Then we said, “No, we're with Public Works. I'm a contractor, but these guys aren't, and we want to know what you want in this service.” They told us and we went back and figured it out. We bought our own infrastructure and everything else and we put together the service. It was a service; it wasn't technology, per se. It was to give them the connectivity or whatever.

    So it's doable, but I didn't go and implement across 350,000 users. We implemented with Public Works first, because that was the home department, and we validated all our assumptions. We had a business case; it was indicative. We did the architecture and it was indicative. We had requirements, and the requirements were what the customer said they wanted. Those are indicative, because most customers in technology don't really know what they want until they start using it. Then they go, “Gee, now that I see it, I don't want this, I want that”, or “Can you put the knob over here instead of over there?” Yes, we can do that. Those things you have to go through, the user has to learn too. When you bring a user in like that in the engagement, which is part of this process, you're bringing in a reference customer. They love you just because you're asking and then you're delivering it for them, so they go, “Wow. I can't believe it.” So there's a whole other piece to that, which is important.

    Large telcos in Canada are still coming around to that. Telus is probably the lead telecommunications company with respect to implementing agile. I'm sure Bell has some going as well, and maybe the smaller ones too, but I don't know because I haven't done a study. I know Telus has a VP and everything focused on it.

    It's out there, and everybody is adopting this now and are using it. This methodology is the reason Elon Musk is disrupting the automotive industry and disrupting the space industry. Amazon is not a mistake. Uber and Airbnb aren't mistakes. Those companies are disrupting industries, not the next company, and they're industries that have been around for a long time. Blockchain is going to disrupt the financial industry.

    I believe the government has to become adaptive, and I believe this is the approach to do it. There needs to be an education on this, and then, of course, when you implement it, you're implementing it in small pieces. It's a method for risk mitigation. The government is a sensitive organization, so this is a much better fit.

    Thank you.

    We're going to Mr. Shipley now.

    Try to keep it to around five or six minutes, colleagues, and we'll see if we can get in as many questions as possible before our time is up.

    Thank you.

    You have a quote in here, that if you find yourself in a hole, “stop digging”, which is likely one of the quotes that many of us use. Then sometimes it comes back to bite us a little bit, because we have trouble sometimes recognizing, one, the hole, and two, that we're actually still digging.

     I'm interested in the process. You focus only on the “why”. To go back to some of the comments of our colleagues, that then takes a lot of trust—

    Yes.

    —because now we don't have a thought process of how to do it, when to do it, and so on. It's just tell me why you need it and I'll go ahead, and it'll come together.

    How does that work? Maybe I'm offstream, but Kelly talked about shipbuilding, for example. Let's start back on a large project. This hasn't anything to do with any party. When we were looking at the procurement for jets, for example—the only reason I mention it is that it's a huge one—how do you break that into little ones? In the private sector, you can kind of control the how, the who, the media, and everything that comes out. In government, you can't just say the how, and the why, and we'll figure it all out, because at every stage there's government, the political, and so on. This is what happens.

    How do you deal with that, to break it into little ones, and get to a large project? Maybe that's not a good example—

    No, that's a good question.

    —but there are large ones. We can do it for the renovations, for example, of our government buildings. It's the same thing. How do we do that?

    That's a very good question. In terms of the initial piece of these projects, if you're doing a $500-million project, then you're going to need a big plan. But I just finished one at SSC where we put in a financial forecasting system that did forecasting of budget against actual. In three months, for $125,000, we created the beta version. If you rolled that across all of government, that would be a huge project. But for $125,000, I can bet that money to learn and discover the nuances of that particular kind of application that would help me on the next iteration and the next iteration. If you bet the farm, yes, you have to know everything and it takes a lot of trust. But if you're not betting the farm, if you're just doing initial trials and test runs....

    Now, in this environment, we do them in production, but we do them at such a small scale initially that we mitigate risk by the scale at which we do them. The normal thinking is “I have to do the whole thing, and I have to do it in one shot because I have to budget for it and I have to allocate and I have to procure for it.” But there are ways to do it. There are standing arrangements where I can buy pieces and components and I can build stuff and test and validate stuff. I can do it in production. I can talk to users directly, and I can talk to citizens directly, which is part of this whole open government thing, which is extremely good. If you're going to send an UI cheque to somebody, ask him, “Did you get it? How did it work? Were you happy? Are you using a new online system from the government?” You need to talk directly to citizens who are using it and get their feedback.

    Risk mitigation is through project size and through the period. The periods are timeboxed into very small iterations. Usually in a 90-day period, I would do six or seven iterations where I would create just a small component. For most projects, like the one for SSC that I just did, the first iteration is how to log in. You create the log-in the first two weeks and come back. You say, “Try it”, so the user tries it, and you get the feedback. What's the next piece you have do? You do it in components like that.

    Then am I wrong in this assumption that it can't be used for large projects of procurement of physical product? For example, you had said that the United States, the U.K., and Estonia are examples. The U.K. just did a major renovation of its government buildings.

    Yes.

     They did it in a third of the time and at a third of the cost. Anybody who has seen them knows they're huge.

    Would they have used an agile protocol in terms of moving it forward? If so, how did they start? Where would you start, and how far ahead would you start before you got to where the shovels show up or whatever has to happen physically?

    I can't say about that project particularly, but generally the shovel shows up pretty close to the beginning.

    If I were doing a departmental-wide transformation, there would be a 90-day period where we would have the planning stuff set up. After that, we would start implementing, but very small projects that are designed to create value around program delivery.

    I'll stop you there. I know we're going to probably get to continue this line.

    Thank you very much.

    We'll go to Madam Ratansi now, please.

    Thank you very much.

    I come from the consulting environment. When we did project management, there were so many iterations. There were flavours of the day that then moved on. Agile is not a flavour of the day, I hope.

    It's not.

    You've been through the private and public sector, and there is a total difference in the mindset. In the private sector, you are encouraged to take risks, and you are rewarded or fired for risk-taking. Has anybody been fired for the fiascos of SSC or Phoenix?

    I don't think so.

    Good. Okay. That's okay.

    The reason I ask you this is that the public sector is risk-averse.

    Yes.

    Being risk-averse, they are there for the long term. Their political masters come and go, so they are the most consistent ones, and they know how to manage themselves. Within that environment, within that hierarchical structure, how do you see agile meeting the needs of the government? In what area, for example, was SSC weak in its planning? Was it in its planning process, was it in its scope, or was it in its quality? When you do not plan properly, the process does not happen, and then everybody says, “I'll run away from this.” Deputy ministers change or whatever happens. How do we, as politicians who take responsibility for all the fiascos that take place, mitigate the risk?

    As I mentioned to Francis, the structure of SSC—the way it is now and the way it was when it started—is not conducive to creating something new, a new shared service. The structure of the organization is combative. I think it's very difficult for them to do that, because they have so many different manufacturing centres that have their own way of doing business. They're trying to merge that, but that's a huge project in itself.

    Say there was a new project coming forth. How would you advise government, within the environment you've already been in, within the hierarchy you have been in, to use a methodology like agile to mitigate their risks?

    Get outside of the hierarchy.

    How? I mean, that's the bureaucracy that works.

    Again, what is the purpose of policy? A policy's purpose is to create some value for citizens.

    I'll ask you right up front, does current policy create that, or does current policy get in the way of that? If I have a policy that tells exactly how to do something in extreme detail, it just becomes a process in the government, which means I have to spend a whole bunch more time following the process and creating a big plan, because I have to create a plan before I do anything.

    But the policy is created. I've been through RFP processes in the provincial government. The 200-page RFP was created because the bureaucracy did not want anything to fall on its face because it would be a risk, so they would mitigate it by saying “A, B, C”, and being very prescriptive. How do you change that mindset?

    What the U.K. did was they had gates, but the gates proved that they were following an agile approach, so the gates did not say, at the end of gate one, “I want you to have a great big document.” It said, at the end of gate one, “I want you to have implemented it with 10 people, tested, and validated.”

    The project methodology says, “I want empirical data. I don't want an analysis paralysis. I don't want to follow process, I want to create value.” Today the processes in government are not creating value for us.

     I'm coming back to SSC, because there are lessons to be learned. What would you have advised somebody starting SSC on what their scope should be?

    Their scope could stay the same as it is. However, I would say that you need to start with a brand new organization that isn't a merger of 43 existing ones. You need to start with SSC 2.0, and you don't need a huge bureaucracy for that. I would start with 10 people. I would start with a JTF2. You have 10 guys, highly trained. They have a very specific mission, and they accomplish it.

    What would your timing be? You know in government—

    Again, you're asking questions that I would call the “traditional approach” questions. I would say you put the team together, you visit them every 90 days, and you ask them what progress they're making toward their goal. Instead of telling them to make the goal in 90 days, you come back and ask them what they've done, what progress they're making towards their goal.

    That's why this is a two-day course.

    So you would change the mindset of the people who have been there for 30 years, who have been taught that this is what they should do to protect themselves.

    Yes.

    I did mergers and acquisitions. When you do mergers and acquisitions, you eliminate a lot of people as well. In SSC's mergers and acquisitions, there was a merger of 43 departments.

    Yes.

    Did anything streamline?

    I don't think they got rid of people, but I don't know exactly what happened. There may have been stuff on the retirement side where they didn't rehire, but I don't know. The structure of the organization isn't conducive to it. If they're going to do a merger, it will take a long time. In six months, I could create some key services with a JTF2 team that would unlock some bottlenecks and allow program delivery.

    Would you do this—

    I'm sorry, we'll have to stop you there.

    Mr. McCauley.

    If you can finish quickly, I'd like to hear the end of that.

    I just wanted to know if he would do the same for Phoenix, because it's the planning process that's the problematic thing.

    Not that question.

    Voices: Oh, oh!

    You allowed me, so—

    No, I allowed him to finish that question. Shame on you for taking my time.

    Voices: Oh, oh!

    Well, Phoenix is a deep hole, but SSC.... Phoenix is difficult because the commitments had been made. It's a messy ball. SSC, however, still has an organization that is effectively keeping the lights on, but they can't create anything new because of the conflict in the structure. So with SSC, I would create a tiger team and I would give them authority, very high-level authority. It would not be the authority to tell them what to do but the authority to clear the path around the goal to be attained. It would be their goal; they would own the goal. The team would have to deliver on the goal. Everybody's accountable. We'd come back every 90 days and ask them how it went. There's an out for everybody from a risk point of view. If we see that the team isn't working, and we need to change some dynamics to make it work, then we do another 90 days and assess whether we're making progress, whether we're creating the value we want. After that, we look at how fast we're creating the value. When we get to that point, we can consider doing some forecasting.

    Thanks for finishing that.

    I want to get back to RFPs. You talked about giving the suppliers the outcome, and how Cisco has smaller RFPs, whereas ours are 200 pages for a pencil. How would you see RFPs not for ships but for regular items? Currently we pack every little detail in there so that we're not sued for unfairness. We put out our RFP, and tell them we're going to choose the lowest bidder. How would agile look there?

    I'm having chats with Vincent Robitaille in modernization and procurement. I think there are procurement vehicles that could be leveraged immediately. There are standing arrangements where I can say, “Look, I just need to get some people who have this skill.” I put them on a team and they're going to go for 90 days. I have another vehicle where I need to buy a few components, or where I need to buy some services. So I can go get those. The procurement process itself is a little heavy. It requires a lot of documentation.

    Extremely so, yes.

    We do a lot of work on visualizing projects. Instead of having a 10-page plans and priorities document, we would have it all on a couple of pages. We call it a canvas, and it's more like a map. It takes the essentials out of plans and priorities. If we did flip charts of the plans and priorities for department A, and we'd have about five flip charts, we'd put them together on a page. Anybody could look at it and know immediately what they're in business for. They'd know what they're doing, why they're doing it, and who they're doing it for. Again, plans and priorities shouldn't get into the “how” of it.

     Big capital-intensive projects that you mentioned do not lend themselves well to the agile system for purchasing. What within government do you think would be a good cut-off?

    If you're going to buy something like a boat, it's probably more difficult, but Elon Musk is—

    The reason I ask is that there's this great story about buying knapsacks for the army. It's taking us longer to procure them than it took us to win the Second World War.

    Right. Well, that's the value question. How much does it cost to do something, and what value do you get in return?

    It costs me $300 to do something that gives me a $20 value return. On procurement, I have a $25,000 max. Okay: so it goes through a whole process over $25,000, and the process costs $100,000. Why don't we lift the...? Especially now that NAFTA is probably going, we might have a little bit more room.

    It's about empowering. You would put a bit more in the departments, but you would have these checks and inspection points much more frequently. The inspection points for sure are every 90 days. We gave you a little bit of money. Then we had an inspection. What did you do? Instead of giving me a big plan that you think might happen, I want you to implement some stuff. We'll see what happens in 90 days. We mitigate risk by keeping it small.

    How would agile change our RFP process, though? In even the smallest things, we end up with a 100-page RFP.

    No, no, I think you can do RFPs with a much tighter and more light approach, where you say, “We're trying to get these outcomes”, and industry, who's going to provide the solution, can come back and say how. That process doesn't have to take long. If I'm not telling you exactly how to do everything, then it's not going to take me three months to create the RFP: “I want to have this outcome.”

    So it would be a very simple, “Here's our outcome.”

    Very simple.

    It might have to be Canadian-made, or you might need—

    Yes. They'll come back with the plan, and we'll say, “Okay, now we want to implement it. But we're not going to implement something for $500 million, we're going with $50,000.” And you know what? For the vendors, that's cheaper than having a team engaged for a year writing a response to an RFP, which costs $1 million.

    Right.

    Thank you.

    Mr. Peterson.

     Thank you, Mr. Chair.

    Thanks, Mr. Murphy, for joining us. It has been very informative. I have a few questions to ask in the five minutes I have here.

    My understanding, from your presentation and my brief introduction to the agile concept, is that it's far more about people and way less about process.

    Yes.

    From your experience, is there a certain type of person, do you think, who would be more willing to participate in an agile workspace than another person would? Are there skill sets that you need? Is it easy to identify those people when you want to change a workforce?

    The transformation is the transformation of the people. When you start thinking differently about how you approach projects, that's the transformation. There are skills required around collaboration. When you go into an agile meeting, you don't tell everybody how you're going to do stuff. When you go into a team meeting you ask them, “We have this problem, how are we going to do it?” Then the ideas start coming forward, because if one person takes over.... There's all this training down at the implementation level, which exists today.

    From a “people person” point of view, it's higher up the Maslow hierarchy where we're going to achieve outcomes. There's a video that I reference here from David Marquet, who used to be a naval officer. He ran submarines. It took a year for a captain of a submarine to understand every detail. You had to know everything about the submarine to run it. He was switched over to a new submarine. He didn't know anything about it. All of the team knew exactly what to do, but they were waiting for him to give them orders. He said, “I'm going to submerge the submarine now, what do you think?” And they'd say, “Sir, I don't know if that's a good idea.” Then he'd say, “Well, why?” They'd tell him. He turned it around. You can watch the video. It's excellent.

    That's the kind of change. People who are involved in agile projects are getting things done. It's a much nicer place to work. It's less stressful. People are achieving outcomes, so they're rewarded. I've seen too many guys in government and the bureaucracy who run the soccer league, because that's where they get their sense of accomplishment.

    Right.

    Does agile need to be an enterprise-wide concept? Does it need to be enterprise-wide? I'm sure Cisco was. Are there ways to put this process into maybe one project in one organization? Would that work?

     Yes to both. I think it has to be enterprise-wide and I think you need to start with one. The whole thing is that you start and it's a growth thing. You start with a seed, but after you start scaling up, you can run as Cisco did. You can run multiple initiatives in parallel. We would change the whole concept of the project management office into the value enablement office, because projects generally deliver scope, but in this case, with agile, we want to deliver value. We can see where we deliver scope in a lot of projects, but we don't get the value.

    Let's say a project is under way and an agile team is implementing it. They're realizing that what they're doing is not going to get them to where they want to be. They need to change. This might mean that they're going to be late now, or they're going to be into a cost overrun.

    If you're on an agile team, every two weeks there is a thing called a retrospective. At the end of two weeks, we have a little Lego block of value that we deliver and the team gets together and asks if they delivered the value they thought they were going to deliver. The answer is yes or no, and then they ask if they can do anything better on the next iteration to deliver a bit more. They have that discussion and then they go for another two weeks.

    At the end of the quarter, we have a bigger retrospective, at maybe a more senior level, that asks, “Did we deliver the value and the outcomes that you were looking for? If not, why not? How are we doing on budget?”

    The other thing I'll say about budget is that it's extremely predictable. I know that I have a team of five or six people running this. I know that this three months and the next three months will be probably within 10%. I get very predictable flow rates of budget allocation.

    My understanding, from reading the briefing materials that I've had a chance to read, is that the client is engaged in the process throughout under the agile method. You'd be reporting back to the client and getting their input at any stage you need to. How does that work in the government setting, when there's not necessarily a clearly identifiable client?

    Oh, there's always the citizen. In the case of SSC, there's a department. When I did the network for Public Works, I talked to all the department network guys and asked how they liked their service. They said it was expensive. They'd like to get more bang for the same dollar. I asked if there was anything else. They said everything else was okay. So we went and did that, and then they all bought.

    So it's quite possible to implement here.

    It's possible. The whole open government thing is to have direct dialogue with citizens through social media or whatever. Just get the dialogue so that you're not stabbing in the dark about what you're trying to do.

    Right.

     Thank you very much.

    Thank you very much.

    Mr. Weir.

    Just to pick up on the point about open government, my sense of agile is that it's a very iterative approach. I can see at one level how that is consistent with the concept of open government, but I wonder if an emphasis on those kinds of face-to-face interactions as opposed to documentation would fit with the transparency and access to information requirements that exist within government.

    We don't eliminate documentation completely. My ideal thing would be to have the user on the team at my team meeting, because there I have all the cross-functional components. I have operational people and developers and all the people I need to create the solution. Then we sit around and ask if the system that we built last week works. They're either ecstatic or they're not. We get that feedback and then we build some more.

    I think whenever possible it's an absolutely mandatory requirement for agile that you have strong interface with the user or the payer of the system, the person who's buying or using it. They have to be on the team and engaged, and I think government can do that.

    Sure.

    I'd also like to ask you about agile in the context of contracting out. Phoenix was a contract with IBM, so one might argue that the problem wasn't just the lack of agile approaches in government but within IBM. I'm wondering, first, if agile is compatible with contracting out, and if the government should be looking to contract with firms that are already using agile.

    If I'm IBM—and I was there—and we get a large bid, and the bid's a 10-year bid worth $40 million to $50 million, we're going to bid on it. If we don't bid, we're out for 10 years. Then you look at the thing and ask if this bid makes any sense.

    The vendors are really smart. They can't see all the requirements in this. We know there is a whole bunch of things they can't contractually get into this requirements document. So they go down to headquarters and say, “Here's the deal. This is a $40-million bid, but we know it's going to be $150 million. We either bid on it or we're out. But we can bid on it as a $150-million deal instead of a $50-million deal, which will allow us to bid at a lower rate.”

     It's not that the vendors are evil. It's just that this is the environment you're giving them to respond to. If you ask them to respond to a national environment, they will.

     I'm certainly not suggesting that IBM is evil—

    Voices: Oh, oh!

    No, not at all.

    —but should it not perhaps have broken the project down into...?

    Don't get me wrong: no, IBM is extremely smart, but that's the environment they're in.

    Sure, but I guess I'm wondering, should IBM not have broken down the Phoenix project into smaller components that were conducive to agile?

    Oh. No, because they were asked—although maybe they did on their side—to respond to a tender. There are mandatories and there are desirables. They want the lowest cost per point, right? They have to play the procurement game. But if you put in agile...if you do that, you're betting the farm on those bids. So don't bet the farm. Implement in increments, and as you go along the procurement people might learn a few more things as well.

    Industry right now, through ITAC, is reaching out to procurement, to work in collaboration with procurement, through some implementations to figure out how they can do procurement better so that it's a win-win, and everybody gets a fair shot.

    Again, we're looking at what outcomes are being set for procurement. What are the outcomes that procurement wants to get? Is it the lowest price or is it the best value? In a lot of cases, you'll get the lowest price but you won't get the best value. There's a big difference.

    Given a choice between contracting out in these small increments versus having an agile team working within government, what would be the better model, or would it depend on circumstances?

    I think you can do both. I think you can contract out. You can use existing procurements and buy people, or you can say, “We're trying to get this outcome,” and you can write a procurement around that outcome and then implement it in increments. You can say, “We want you to come in, but we have an out every 90 days. We're going to have three vendors and you're going to go for the first 90 days. If you're pathetic, we're going to go to vendor number two.” Vendors might push back a bit and say, “Well, you're pathetic on the government side”, and you could have some of that. But I think this would work a lot better and it would mitigate risk.

    The stakes aren't as high. It's not $50 million, where stakes are really high. If the stakes are $100,000, maybe in the long term, if I perform as a vendor, I will get that big prize over time. But I'm only going to get $250,000 in the first 90 days.

    Thank you very much.

    Colleagues, I was planning to suspend around 12:30 to go into committee business. If there's still interest, we perhaps have time for two more five-minute interventions.

    Mr. Whalen, would you like to take a stab at firing out a question?

    Absolutely.

    It sounds as though, if you try to get yourself into an agile mindset in order to implement agile itself, you'll have to do that using an agile approach. If people are used to doing $40-million contracts, getting them down to $1-million capped contracts can't happen overnight. It's going to take some type of an approach.

    When you're adopting agile to cultural change like this, what types of percentage change are we looking at doing in each iteration? Are we looking at a situation where, for example, we're going to shorten the length by 5% every quarter for the next 10 quarters, or are we going to reduce the dollar value by 20% every quarter? How much do you bite off in terms of growing the teams? How many teams are you going to try to build, and what team rate of growth are we looking at in order to implement this type of a cultural shift across government? How does that look?

    All of that stuff comes out in the retrospectives at the end of the quarter. We do an assessment at that point of how things went.

    Effectively, it's the same planning process we've always had, except we're going back to revisit inside the release every two weeks. At the end of the release, you're going back every three months to revisit your planning, to check if your assumptions were correct.

    In terms of that planning process, they have a thing in agile called “velocity”, which means how fast are we moving? How much are we providing? How much value are we creating? The team's getting a sense as they go along of how much they can create. They'll get to a certain point where they'll find their steady state, and then it becomes very predictable. We know this team can produce about this much every quarter, and if everybody's happy with that we can keep going; or we consider whether there is anything else we can do to produce a bit more, or to do less. But it's not driven top-down; it's driven by the team. It's not the top saying, “Now you have to do it two weeks quicker”—

     Dan, is it driven by the team or is it driven by the data that arises out of their performance?

    Both. Effectively what you're creating is a discovery and learning organization that's building capability, and credibility and capacity internally. It's not about getting an outside contractor to do all this. You really need to build this capability inside the government.

    I guess maybe related to this, one of the things I found surprising about the SSC approach and the Phoenix approach is that it's really sole-sourced. With such a broad organization, you'd like to see a competitive spirit help drive some success. Does agile allow us through its metrics to approximate or to create some type of a cultural competition or a culture of excellence, or does it provide opportunities for actual competition where other people can more frequently come in and bid on projects? How does that interplay work in agile?

    You can absolutely create an environment of competition, but again, I'd go back to this: Is value your number one driver? Do you want value or do you want competition? Does competition drive value? Yes. Okay, so let's do more competition.

    You can always set it up and structure it. If I have to be in an environment where I have to have competition, because that's part of my mandate, that's the world I live in, okay, then we do it. However, too often the outcome is driven by internal requirements versus the value that we want to drive for citizens.

    A citizen says, “I want to get my cheque.” You say you can't do that, because you have to be competitive. Well, maybe you do, but underlying the real thing you're trying to do is create value for the citizen through program delivery. If you stay focused on that, then everything else comes into perspective underneath it. If you lose track of that, then competition or the lowest price becomes the most...then you're going to run into trouble, I think.

    You have less than a minute left.

    Is there an opportunity for people who work in government already to take this two-day course that Minister Brison is taking? For instance, how do I take it?

    It's through ITAC. You can contact ITAC. They have the stuff up.

    It's important to understand this, and there is a lot of stuff going on from an education point of view on how to run an iteration and how to run a team and get the team dynamics, but for the leadership part across the industry, there is a bit of a gap there. It's still maturing. That's why we want to come forward with this through ITAC, so it's industry and not representing one vendor but all kinds of vendors.

    Regardless, just dive into it and understand it. If you take the course, great.

    Mr. Nick Whalen: Thank you.

    Finally, Mr. McCauley.

    Thanks again.

    You really summed it up when you talked about how we focus on internal requirements, not outcome. I'm sure as long as we have all the boxes ticked, if the bus drives off the cliff it doesn't matter—as long as we get the boxes ticked.

    Right.

    I can imagine how difficult it must be to change just the whole attitude and the way we think within government. I want to go back to, say, Estonia or the U.S. or Britain. Are they approaching it as a department-by-department focus, or is every department trying to tackle a small bit internally?

    Government in the U.K., from what I've seen, is focusing on the initiative or at the project level, and that's good. Anything is good, because we're learning.

    Is that across the whole government?

    Yes, they have a whole-of-government approach.

    Whether in procurement or DND, or tiny little bits in every department—

    Yes, it's driven out of their Treasury Board equivalent. Basically it has a new project management approach, which has gates around completing agile milestones instead of “We have our requirements document complete.” It's good in that way, but I don't see it from an organizational point of view as much.

    What I would recommend in government is that they try an organizational pathfinder project where we start trying to move an organization toward this type of approach, like a Treasury Board. Policy is great, but policy is subservient to what your outcome is. It's supposed to deliver that, and then underneath are directives. The directives, I feel, are just too prescriptive. It takes a long time to create directives, and a lot of work and a lot of people. There is a whole bunch of money savings on the time we take to go into detail about how exactly you're going to do something, when in the end we find out we really didn't know anyway. When it comes to the implementation, the moment of truth, it doesn't pan out.

    I'm wondering what the RFP would look like that we would publish to hire agile—

     The U.S. government has an organization called 18F, because that's their address on some street in Washington, and they're a bunch of kids out of Google. They have template RFPs and everything that.... The leverage is small. There's stuff out there, and we can leverage a lot of that. The important thing is that you have to jump in, you have to get your hands dirty and start doing this stuff, but don't bet the farm.

    What other large private corporations in Canada are using this? Obviously Cisco is.

    Shopify is. They have 2,500 teams. I had the Shopify guys come in—phenomenal story—and they're getting a lot done. If you go to Shopify, you'll be the only guy with a jacket and tie on.

    Voices: Oh, oh!

    Mr. Dan Murphy: You won't find anybody over 40.

    Are there any other institutional organizations that you're aware of?

    Scotiabank has a huge program. They split off a piece of Scotiabank that doesn't follow the same governance as the bank. They call it their Digital Factory. The reason was that they were getting competition from Tangerine. I think they ended up buying Tangerine, but these online banking things were a big scare for them. So was Bitcoin. That was a huge scare for them. Bitcoin is a point-to-point “we do the transaction, I don't need the bank” company. The stuff is coming so fast, it's extremely difficult to keep up with it. The banks are all moving....

    The VP at Scotiabank is coming to the Shaw Centre tomorrow to talk, not about agile per se but about why they split off and did separate governance. We basically said to him, look, we don't want you to come and talk about agile, we want you to talk about why you have a separate governance for this and why you couldn't operate this within the bank.

    I guess it was probably regulations.

    Thank you very much.

    Mr. Murphy, on behalf of all my colleagues, thank you very much. I found it fascinating and extremely informative. I wish you the best of success. I know that governments are governments and they do what they do. Time will tell exactly how successful this government, or future governments, may be in adopting the type of culture you're speaking of. You certainly opened my eyes, and I think the eyes of a lot of us around here, that perhaps we have to start thinking in a different manner if we want to get the results that you're suggesting are out there.

    Again, thank you so very much.

    Colleagues, we'll suspend for a couple of moments and we'll go in camera immediately after that.

    [Proceedings continue in camera]