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