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.