Government Operations Committee on Oct. 17th, 2017

[The Chair, Conservative, Tom Lukiwski]

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.

[Brenda Shanahan, Liberal, Châteauguay—Lacolle, QC]

Full disclosure, right?

[Voices]

Oh, oh!

[The Chair, Conservative, Tom Lukiwski]

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.

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

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.

[The Chair, Conservative, Tom Lukiwski]

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.

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

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.

[Dan Murphy]

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.

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

Yes.

[Dan Murphy]

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?

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

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?

[Dan Murphy]

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.

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

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?

[The Chair, Conservative, Tom Lukiwski]

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

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

They are managing my time.

[Voices]

Oh, oh!

[Dan Murphy]

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?

[The Chair, Conservative, Tom Lukiwski]

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.

[Kelly McCauley, Conservative, Edmonton West, AB]

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.

[Dan Murphy]

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

[Kelly McCauley, Conservative, Edmonton West, AB]

Higher with government, I'm sure.

[Dan Murphy]

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

[Kelly McCauley, Conservative, Edmonton West, AB]

Right.

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

[Dan Murphy]

Yes.

[Kelly McCauley, Conservative, Edmonton West, AB]

Could you...?