Government Operations Committee on Oct. 17th, 2017

[Erin Weir, NDP, Regina—Lewvan, SK]

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.

[Dan Murphy]

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.

[Erin Weir, NDP, Regina—Lewvan, SK]

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.

[Dan Murphy]

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.

[Erin Weir, NDP, Regina—Lewvan, SK]

Sure.

[Dan Murphy]

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.

[Erin Weir, NDP, Regina—Lewvan, SK]

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?

[Dan Murphy]

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.

[Erin Weir, NDP, Regina—Lewvan, SK]

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.

[Dan Murphy]

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

[Erin Weir, NDP, Regina—Lewvan, SK]

Sure.

[Dan Murphy]

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.

[Erin Weir, NDP, Regina—Lewvan, SK]

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?

[Dan Murphy]

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.

[Erin Weir, NDP, Regina—Lewvan, SK]

Thank you very much.

[The Chair, Conservative, Tom Lukiwski]

Thank you very much.

Monsieur Ayoub.

[Ramez Ayoub, Liberal, Thérèse-De Blainville, QC]

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?

[Dan Murphy]

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.

[The Chair, Conservative, Tom Lukiwski]

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.

[Bev Shipley, Conservative, Lambton—Kent—Middlesex, ON]

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—

[Dan Murphy]

Yes.

[Bev Shipley, Conservative, Lambton—Kent—Middlesex, ON]

—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—

[Dan Murphy]

No, that's a good question.

[Bev Shipley, Conservative, Lambton—Kent—Middlesex, ON]

—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?

[Dan Murphy]

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.