Notices of Meeting include information about the subject matter to be examined by the committee and date, time and place of the meeting, as well as a list of any witnesses scheduled to appear. The Evidence is the edited and revised transcript of what is said before a committee. The Minutes of Proceedings are the official record of the business conducted by the committee at a sitting.
Colleagues, if I can gavel us in a few moments early, I'll go over a couple of things for your benefit before we turn our attention to the witness in front of us.
Colleagues, we will be conducting this meeting between the hours of 3:30 and 5. For those members on the subcommittee on agenda, we had been scheduled to meet from 5 to 6, but we will of course be interrupted by bells. When the subcommittee does meet, we'll discuss how long we can meet before we have to get back to Centre Block to make it in time for the votes.
The second thing I want to point out is that we had discussed at one time having two separate panels at this meeting. The first would be a panel of three former SSC officials, and the second panel, which would be half an hour, would be with the equivalent ministry in the Ontario government. Mr. Nicholl has graciously accepted our invitation to attend, but my feeling and that of the clerk is that since Mr. Nicholl has come here from Toronto, it might be a bit of an insult to have him appear for only 30 minutes. We have asked whether he can appear as part of the entire panel, which we will have for 90 minutes. I believe you have questions for all of the witnesses, mostly for three former employees and Mr. Nicholl. Hopefully, colleagues, that won't be problematic for any of you, but they will all be appearing as one panel rather than two separate panels.
With that, we'll convene the meeting. My understanding, lady and gentlemen, is that neither of you has any opening comments. We can go directly into questions.
The reason we agreed to 45 minutes and then half an hour was that Mr. Nicholl would have been alone. I thought it was enough for all of us to ask him questions. I know he's only here for half an hour, as opposed to 45 minutes, but now he has spoken with the other witnesses. We weren't aware of any changes to that plan, and had we been, we would have requested continuing with the previous agreed plan of having 45 minutes and a half an hour.
I appreciate that. I'm in agreement with the chair and the clerk that, seeing as we have him here, it might be of value to have him available for the full hour and a half in case we were to spend more time on Ontario and focus on an area where it went right rather than dwelling in the past.
I would like to ask Mr. Nicholl if he's comfortable being here, because he might have things that he might want to say. I think the agreement was that he would come alone and present alone for his personal reasons, or whatever. If he's comfortable sitting here, then we are comfortable. If he is not, then we would be willing to accommodate your wishes.
I agree with the chair on this one. I don't see the purpose of making Mr. Nicholl sit outside for 45 minutes. If members of the committee don't want to ask him questions until the last half hour, that's our prerogative, but it seems to make sense to have all the witnesses available, so that we can ask them questions as appropriate.
Lady and gentleman, this is a bit unusual, but I've always taken the approach of trying to get a consensus among the committee. Sometimes if consensus is not available, we do go to votes. I'm always at the will of the committee. In this case I will ask a simple question. Who would be in favour of Mr. Nicholl remaining for the full 90 minutes?
Mr. Nicholl, I would ask if you could please excuse yourself.
Francis, do you want Mr. Nicholl to physically be outside of the room, or just not sitting at the panel table?
Thank you very much to the witnesses for being here with us today.
My understanding is that you have all been with Shared Services Canada at different times in the past. I'd like you to take us back. Maybe I'll address my question to Madame Forand.
Just take us back to the early days. Talk about the strategic plan and also the funding model. How was it bringing together these 43 departments under one roof with the three business areas that you had to address? How was that going to happen?
I was appointed to be the first president of Shared Services Canada in August 2011. I had been, as a deputy minister, a member of the advisory committee to the Clerk of the Privy Council Office, in advance of that establishment, on the whole administrative services review work, which included the consideration of consolidating IT infrastructure. It was a little bit of a surprise to me in June 2011 when I was invited to be appointed as the president, which happened in August.
It was a big change. As for the rationale behind it, there had been a lot of work done. Mr. Long can tell you all about that, because he was on the administrative services review team and did a lot of the analysis and thinking in advance. Essentially, we were patterning it on work that had been done in the private sector. When Mr. Westcott was at the Canadian Imperial Bank of Commerce, he did something similar in the private sector. One of the reasons that Grant came and joined our team was to help us out with that.
The idea was that the planned consolidation of the IT infrastructure was consolidating at the most generic level of IT. We're not talking about business applications that are different for all departments, but more about a kind of utility. You could consider IT infrastructure to be like the electricity in the walls. It doesn't matter if it's blue, green, red, or purple; if it all works together, is of good quality, and is well integrated, that has a lot of benefits, obviously.
Of course, there are benefits in terms of cost savings. That was a desired outcome from the exercise, but beyond that, there are a lot of other benefits that this exercise continues to seek to achieve. These include the tremendous enabling capacity of a standardized infrastructure to enable a single organization to be inter-operative, to network, and to build the capacity for large amounts of data and for rapid transmission of that data. If you look at private sector companies like IBM, HP, CIBC, and the banks, they have all done this so they can work together as a group. In government, that becomes very important.
That was the rationale behind it. There was a tremendous amount of planning done. Still, it's a huge exercise to take 40 parts of 43 departments and bring them together into a single entity. One of the things that I constantly said in the first year was that 43 was a big number. No matter what you're talking about, 43 is a big number.
Initially, there was a large group of 12,000 employees from what was then Public Works and Government Services, which was the IT shared services branch. They were the initial component of Shared Services Canada in August. Then we spent September, October, and November planning for the rest of the IT people from the other 42 organizations to join us. We had a little bit of time to plan there.
In the first year, the number one priority, absolutely, was maintaining operations. After November 15, when the 5,000 other IT employees were transferred, our main job was making sure that everything kept working, and we were successful in doing that. It was a seamless transition.
The people stayed where they were. They continued to do what they were doing. The only thing that changed was that they were now SSC employees. Our message to them was, please, just keep staying where you are, doing what you're doing, running the same IT infrastructure that you had, the way that you know how to do it.
When people asked me what was a surprise through this initiative, I would often say it was how wonderful the employees were.
We changed so much about the name of their department. We put them what in French you would say l'incertitude la plus totale on November 15. They didn't know this was coming to them individually and yet they continued to come to work, continued to do their best, and continued to work hard on what they had to do. That was our first priority, maintaining operations.
Our second priority was engaging with the employees. We gave 99% of our employees the opportunity for a face-to-face meeting—or for those really remotely located, a meeting by video conference—with Grant and me and the ADMs. We engaged with the industry. We set up a whole process to meet all of the industry associations.
I was just about to mention our third priority. Our first was keeping everything working, the second was engaging with everybody, and our third key priority was developing a transformation plan.
We had a plan for moving into the consolidation, but we were not created with the transformation plan already in place, because to do that, to do a transformation plan, we needed to know, first of all, what we had. So we spent a year counting things. There was no data in departments for how many servers they had, what kind they were, and when the contracts were up. People, equipment, contracts—we had to go out and count everything that we had.
For a CIO branch, if you consider their budget in any department as 100%, about 40% of that was transferred to us to reflect the infrastructure component of what they had. But, yes, in 2011-12, there was a process in government called the strategic and operating review, and as part of that, in our first months, we were asked to identify potential savings of 10%. These were to be taken over three years.
First of all, I would like to thank the witnesses who are appearing here today, especially since they are here of their own accord. I have the greatest respect for public servants, in particular those who had major responsibilities.
Ms. Forand, it is fascinating listening to you. You are describing the start of this adventure to us.
My question is very open. I will let you continue talking about implementation and the lessons learned. If any of my colleagues would like to add something, please go ahead.
It is true that we are passionate about this. We spent four years together setting it all up. That said, I will return to the third priority, the implementation of a transformation plan.
First, we had to determine the state of what we had inherited. There was no inventory as such in the departments, unfortunately.
I accept what you said about lessons learned. The first one that occurred to me over time, and which I have often thought about since then, is as follows. In a similar context in the private sector, if there had been an amalgamation as is the case with mergers or acquisitions, the first thing that would have been done before things were set up would have been a due diligence exercise, with solid teams of highly qualified people. This exercise would not have been assigned to just anyone.
The company tasked with this exercise would have brought in its best people. It might even have set up shifts so that work was done around the clock, for a month or two, or however long it took. We did not have that advantage and over time we saw the resulting difficulties. Service standards and procedures were not written down anywhere. Our employees' point of view was very valuable and that is all we had. There was nothing at all on paper.
We wanted to re-create the way things were done in the private sector, but we could not always do that. For me, that was the first lesson learned.
If I may, Mr. Chair, I would like to add something to what Ms. Forand just said.
As she stated, I worked for Privy Council before the organization was created. The data available to us was very important. If we had had access to that data through the departments, that would have given us an advantage and helped us develop somewhat more detailed plans. We had permission to look at global data from all departments, but it was highly variable. The data from some departments was very good data, but not so good from others.
Looking back, it is hard to understand why that was the case. At the time, it was spread out everywhere and there were different approaches, different versions of data and different definitions of what IT was. As a result, we could not consolidate the data at the time, aggregate it, and develop much more detailed plans than those that Shared Services Canada had inherited. I'm talking about high-level plans and business cases. The consolidation and standardization approach had been used elsewhere, in the private and public sector alike.
At the time, searching for data was also important. As Ms. Forand indicated—Mr. Nicholl will be able to speak to this since they gathered data—, it took a number of months to do this even though the Government of Canada is not like a private corporation, whose data is less accessible. In any case, it was not accessible at the time. So we expected that it would take a number of months and we did not have much time.
The objective was to develop high-level business plans and implementation plans. Then, once the delivery team was in place—I moved with the team at that time—, more detailed plans would be created. We had to look for all the data, and we searched for nearly a year. We counted every server and every data centre.
To give you an idea, when I was at Privy Council, we thought there might be about 200 data centres in government. We based this number on interviews with chief information officers, officials from each department, and DM and ADM committees. We thought there might be 200 or so, but after a year we had counted 495, and I am still discovering others today.
When did you complete your due diligence with regard to creating the organization, which was in 2011? We know what we were getting into, but now we have perspective. Were there grey areas in August 2011?
In the first 10 or 12 months, we had a fairly clear idea of what the big aggregate pieces were. We were confident in the plans we were developing. As Ms. Forand stated, my role was to develop the first transformation plan, together with my colleagues, the private sector, and the chief information officers of all departments. It took 10 months to develop our first business plans.
Just to pick up on the challenge you had in accounting for what existed in terms of servers and equipment, do you see that as primarily a problem with how Shared Services Canada was organized, or a problem with how IT was organized in various departments and agencies prior to Shared Services Canada?
Just to recap, I'll go back to what Liseanne mentioned. There were 43 departments that which had been organized that way since the beginning of IT. So for approximately 50 years, there had been largely independent decision-making with respect to how IT was run, how IT architecture was structured, how IT was organized. It was all done departmentally. Some departments were exceptionally well organized in their processes and their administrative prowess. You would in some departments that, yes, knew exactly where everything was, and it was all accounted for, and you could find it.
On the other hand, there were a great number of departments in which that was not the case whatsoever, particularly with respect to such things as service management and problem or incident management. These were things that in some respects, when we first started—this was primarily in my area of activity, and I think Kevin Radford, whom you talked to before, alluded to it.... Right at the very beginning, one of our fundamental mandates was to maintain service. Well, how do you actually do that? We started right from the outset and suggested that the one process intervention we had was to organize, among the groups working with us who had been initially transferred, a system whereby, if anything went wrong, they had to alert us in a systematic way throughout the entire management chain, so that we knew there had been an incident, which we could then in turn track, and which we could in turn make sure that remediation was done and that the metrics started to form.
It was at that point, after about six months, that we started to realize that, my goodness, there was a huge variability in the capabilities of the organizations. Some were very good; some were quite shocking, quite frankly, given the size and magnitude of some of the budgets that we were talking about and some of the people who had been there. This was the start of our developing the metrics and the standards by which we could actually gauge what kinds of problems we were trying to deal with.
That's just the fact. It's just what we encountered. Part of our job was then to figure out how we could normalize this and raise the quality of what we were doing. At the same time—and this is part of the set of inherent issues we had to work with—we knew we had to build a transformation program. Part of our mandate was to figure out how we were going to rebuild the Government of Canada's infrastructure to modernize it and make it suitable for an organization of this size and capability.
At the same time, we had the huge inherent infrastructure that we had to keep running. We could invest in the old or we could invest in the new, and part of what we had to balance was how much investment to put into the old while at the same time reserving sufficient capability to find funding to do the new. We had to find that fine balance.
That's what we did, but also, there was a pretty well-developed set of processes in the industry around managing large-scale organizations such as this. There were things such as ITIL and other things. I won't bore you with all the technical terms, but things had evolved after a great number of years, and part of what we were trying to do was to say, let's do these things in a much more standardized way so that we can get standardized measurement and standardized execution and standardized results.
Yes, I guess what I'm trying to get at a little bit is the extent to which Shared Services was bringing an approach from the private sector into government, or to what extent it was taking best practices from within government and applying them across government, or probably using some combination of both.
It was a combination of both. Some departments had proceduralized things very well. There is no shame in plagiarism, so in many respects, as we were putting it together, we would take the procedures that had already been developed and just change the name to Shared Services Canada, that this how we do it, as opposed to department A or department B. In many respects, that is what we did.
I think the most fundamental issue of all is that the creation of Shared Services Canada had a huge impact on all of the people who work in IT in government—not just the folks who were transferred to Shared Services Canada, but also the CIOs and their organizations that were left behind.
In many respects, we did not do, as a government writ large, enough work on understanding the HR consequence and what it actually meant to the CIOs. Many CIOs lost huge amounts of their organizations as we created Shared Services Canada, and there were many CIOs of whom it was the case in many respects, and I don't mean to say this in a callous way, that for the most part all they did was work on infrastructure. When you transferred all the infrastructure to Shared Services Canada, many of them were actually left with a very marginal mandate. That has consequences. I don't think we understood that as well as we could have.
I know some of you are here on your own time, or all of you. Some are in other departments.
I want to get back to the creation of Shared Services Canada in 2011. There was an order in council. In previous testimony, we've heard some arguments for having procurement within SSC, and then we've heard from another witness an argument for having procurement outside SSC. I'm trying to understand, given your testimony as to all the things you have to do, what the rationale was for bringing procurement within SSC at the time.
I'll take a crack at that initially. Grant or Benoît may want to add to it.
We were created in 2011 and we received our procurement authority in 2012, when the legislation was passed. As I mentioned, one of our priorities was engaging with the industry. It was one of the first things we did through the fall and winter of 2011-12. We did it by approaching all seven national IT industry associations in Canada and talking to them about the relationship they had with government and how it was going for them.
We had some knowledge of it. Grant in particular had worked extensively in that area. We knew that it was checkered. We knew that there were big issues; that there had been big issues with large-scale IT investments in government over the years and lots of finger-pointing. There was lots of litigation. We wanted to avoid as much of that as we could.
We thought a way of doing it was really to ask them how we can make sure we have a relationship that works, that we're all working together towards something.
Among the other things that we heard from them was that we need to involve them early in what we are doing, that we couldn't sit back and write up an RFP, drop it over the transom, and then they would get it and it's something that is impossible to do. We need to work together on what their needs were and to find a way of doing that. We had looked at that also.
We concluded, through this exercise and through other thinking that we did, and by looking at other jurisdictions and how they had proceeded, and at the private sector and how it had proceeded, that it was really important to be able to develop a strategic relationship with the industry. I don't mean by that being friends with them and going for lunch; I mean just having a relationship in terms of what our needs were, what they could provide.
We established a round table with some advisory committees, but we also came to the view, given the area in which we were purchasing, which was in a pretty narrow band—it's IT infrastructure, not pencils, not F-35s, but just that IT infrastructure band—that we could be very deep and skilful in that area. We had now all the experts in government in our department. They were not anywhere else anymore.
We could work with the subject matter experts and make sure that our procurements were aiming to get the best result—not the cleanest. We wanted a clean process, but the process wasn't our objective. The objective was to get the best quality at a good price for the whole government. We were able to make a good and convincing argument to the effect that we could do that more efficiently, but more importantly more effectively in terms of the results, by working directly on our own procurements.
We only achieved procurement authority for IT infrastructure, not for anything else. For everything else, we were like any other department and purchased through Public Works.
To us, that was important.
Also, there was a time factor. We'll come back to what went wrong or what's not working as well as we'd hoped. Time is a really difficult factor in government. There are lots of things that suck up time. Procurement had the potential to do that. There was no way we could do the transformation we were planning to do over the period we were given, if we were not able to manage procurement as effectively as we could.
You have mentioned, and I heard Mr. Long say, “Time was not on our side”. What was the motivation for not having the time? Was it just trying to get savings, or was it actually achieving a solid IT infrastructure? What was the timeline?
Well, everyone was anxious for this transformation to be done expeditiously, but not in a hurried way. We were of the view that when we brought forward our plans—what we created in 2011—we were aiming for 2020. That was a reasonable period of time, based on what we had heard. Some in the private sector would say that they could do it faster; others said that this was just about right. But it's in the implementation that, in government, and I'll say this quite candidly, “speed to delivery” is very difficult to achieve. I'm quoting my friend Grant Westcott, who was very focused on trying to achieve speed to delivery.
It's hard to put your finger on why that is. Is it the process? Is it the culture? Is it the decision making? What is it? We had difficulty with speed to delivery, I would say, just incrementally, and we were pushing all of the time. We did think it was a reasonable amount of time for us to get the work done, but as other witnesses have said to this committee, as you adjust the money, you also have a tendency to adjust the time as well. As money became scarcer—and I'll stop after this—there was a bit of a vicious circle. As you're not going as fast as you should, that means that your old equipment has to last longer, and so you have to invest more in your old equipment, which leaves you less for your transformation, which slows you down, and then it's a bit of a vicious circle.
I think the other thing that we came to realize two or three years in was that it was absolutely essential to have enterprise IT planning for this to succeed. We started off, we had this great big program, and people tended to think of it as the SSC program, but really it was for the whole government.
But at the same time the Treasury Board Secretariat had a big program that they were doing. They were consolidating websites, they wanted to consolidate financial systems and consolidate HR systems, and do all of this.
Meanwhile, the DRAP process, which a member mentioned, meant that a lot of departments were re-engineering their own things, which meant that they had a lot of IT projects in order to do so. When we did an inventory of the projects that were in flight, were underway when we were created, there were more than 1,000 of them across the 43 departments.
There was no process, no governance to ask what the priority was. If Shared Services Canada is doing email transformation, should departments be investing in supporting that, in the first instance, or should they be supporting the consolidation of HR systems, or should they be supporting their own initiatives? It was an endless kind of dispute along those lines.
Enterprise planning, I would say, is something that should have been in place from the beginning.
We heard, I think two weeks ago, a gentleman from Transport Canada who was quite pointed in his comments. Are you in general agreement, or...more pointing out huge flaws in the system or more just pointing out that problems will happen, but these are the ones we ran into?
—in a department through this whole exercise would have been very different from our perspective.
Let me just add one more little piece in terms of how we were created. One of the ways we were created was that, obviously, we inherited 6,400 people or FTEs from departments. Departments identified the people to transfer.
I think that one of the additional learnings that Liseanne referred to was around enterprise planning. There's a recognition right now in the government that for this part of the equation, if SSC was really focused on the supply side of this equation, the demand side had to be worked through. There is a committee now of deputies and ADMs across the government that is looking at how to plan IT differently and much smarter than in the past. It takes those two parts to make a whole. I think that's a big gain that we didn't have at the time when SSC was created.
I think we mentioned the data side.
The other piece I would say is that from the very beginning, whenever we interacted with any jurisdiction or companies, the notion of harvesting benefits before transformations were complete was always put forward as a warning signal. The reason, of course, was that those savings generally are there to actually feed and help transformation; otherwise you have to find the resources from outside of the savings in order to transform, and that makes it very difficult. I think that's another powerful learning about which certainly SSC seems to be on the right track.
I would like to thank the witnesses for being here today.
Since I have just five minutes, I will move along quickly.
If I can provide some basic context, we are judging some of the work you did over the past four or five years. We have an auditor general's report and witnesses have already appeared in this regard. For our part, I hope our objective is to find solutions in order to make improvements and not to lay any blame.
You have already provided some context and I will not go over the same problems. I would like to know if the problems pertain to the business plan. You also spoke about human relations. When people are grouped together, you can try to reassure them, but I'm not sure if it is very helpful. People are smart and no doubt some of them realize over time that their jobs are threatened. I have witnessed this in many other organizations. That's what happens when services are reorganized.
Mr. Westcott spoke to us about this briefly, but I'd like to know the three main things that should be avoided and what we should do to achieve the expected savings?
I will start and perhaps my colleagues would like to add to my answer.
The exercise is always very valuable, to the extent that there are benefits over and above the financial ones.
Human resources are very important. We inherited staff who were able to maintain the current systems but who had not been trained in transformation. If I had known then what I learned later on, I would have launched a staff recruitment program much earlier, in 2012. We could have brought in people who could have provided more support with respect to transformation and new methods. We looked a lot to the way things were done in the private sector.
We did not have human resources data or systems. It took us a year and a half to identify the staff we had and to get job descriptions. The system in government to make this kind of change is complicated, but once it is in place, we can continue. There is no doubt that human resources are important.
There is an approach that could be taken so as not to repeat the same mistakes.
The basic mandate of Shared Services Canada was threefold: service improvement; cost savings; and security. From the outset, we learned, with the departments, that the security aspect and the tremendous benefits of centralizing certain functions would enable the government to operate as never before. That must be part of a balance and of constantly evolving plans. IT is a very robust sector that evolves quickly. These three aspects must be in balance. You cannot focus on just one aspect; you must focus on all three because they are always in balance. Mr. Westcott mentioned this. It is an ongoing strategic decision for management. You have to make investments and know how to use them to substantially improve services, services or security. You have to bear that in mind at all times.
Is there something that could be done midway in the process in order to determine that the objectives will not be reached, whether savings, restructuring or layoffs? Do you have a plan with guidelines that would show that another six months or a year would be needed to make the changes? You must have realized over time that you were perhaps not going in the direction you had wanted.
That is why, in the fall of 2014, we wanted to review the whole transformation plan and all the hypotheses we had made to see what changes were necessary. Then we made some changes. From what I have read of other witness testimony, that will happen again in 2016, and that's normal. In fact, that's what everyone was telling us, that we would have to adjust our plan as time went on. That is how we saw the implementation difficulties in terms of deadlines and how we tried to make course corrections.
Colleagues, before we continue, I'd just ask to have your collective opinion, a consensus if possible from the committee.
We've had our witnesses before us now for about 40 minutes. Would you like to continue with two more five-minute rounds with these witnesses and then go to Mr. Nicholl, or would you like to have Mr. Nicholl up now for approximately 40 to 45 minutes?
Having said that, I would like about five minutes of committee time before we adjourn at 5 p.m.
Five minutes was mentioned, and again, I know it's difficult because we've passed it on to Mr. Parker, who has had the unfortunate experience of being before us a few times.
Without stepping on his toes or judging what he's doing, can you say from the outside, now that you've stepped away, what a couple of priorities would be that as a committee or as a government we have to keep our eye on so that we're providing the proper support for Shared Services, but also so they perhaps don't go off target.
Thank you. I'll be brief and let my colleagues give this a shot as well.
I would just say, in thinking of this ahead of time, actually, my best advice to Ron and to the government and the support they can provide him is not to lose sight of the tremendous prize that's at the end of this, and not to get scared off by it. There have been delays, but you know what? Compared to what some of you may think of in terms of IT issues that have really gone wrong.... Time is an enemy, and I'll say that, so we need to catch up with that, but otherwise—
—it's moving in the right direction, and the value of what this will create is worth the time and the investment that it's going to take.
I didn't travel a lot on the job, because I was very busy here, but occasionally I would see people from other countries—the U.S., Israel, the U.K., France—and they were all very impressed with what this can deliver. They knew it was going to be hard but they said, boy, for IT and cybersecurity, for modernizing the work of government, this is absolutely essential.
I might just add to what Liseanne mentioned earlier. I'd gone through a similar exercise in the private sector. One of the conclusions as we approached the end of approximately six years of very much the same type of work was that as we went through the work—we didn't know this would be the result—things became much less complex.
Today, if you think about what you had under the old regime, you had 500 data centres delivering information to people located in 3,000 places across some 62 networks, etc. There was an unbelievable complexity to try to understand and then to manage all that. When you think of it, an end-of-day model essentially says, hang on, we'll connect those 5,000 people across one global network to five data centres that are properly constructed to withstand all kinds of peril and are resilient both for security and from the perspective of being able to withstand any number of different perils. It's a much simpler place to run and operate, thereby enabling much more. It's easier to do work in a world like that.
The issue is that you have to persevere. You have to realize there are going to be bumps in the road. On top of that, unforeseen things are going to happen to you, because it is over a period of time in an area that in fact can be quite turbulent. There are always things that happen and, nine times out of ten, IT is involved. You just have to persevere and stick with it.
I go back to perseverance. The mandate, I think, remains the right one. Mr. Parker and his team are engaging the full community across the government quite actively. He now has a group of deputies and a group of ADMs that are focused on helping to prioritize and address some of the challenges from the demand side, which I think is going to be helpful to their mandate and their mission going forward.
I would certainly encourage them to go as quickly as possible towards enterprise services. Only a few have been released. Procurements have taken quite an amount of time to get done, but now that they're available and will become available to many departments, I foresee that the demand for what they're doing is going to increase quite significantly. So we're close, but not yet there.
Thank you very much, colleagues, and thank you for your questions.
Madam Forand, Monsieur Long, and Mr. Westcott, thank you so much for your appearance here. You've been extremely helpful. Your testimony has greatly helped this committee in its deliberations. You are excused.
Colleagues, we will suspend for about two minutes, and we'll hear next from Mr. Nicholl.
As has been previously said—you were in the room—we're looking for ways to respond to some issues regarding how Shared Services Canada has been working toward meeting its goal of providing a unified service of information technology across all departments in government, and to some complaints in the Auditor General's reports in respect of that.
Can you describe your role within Ontario's version of shared services, and how your organization operates in relation to the other departments?
First of all, thanks for having me. I'm happy to be back here.
I am the corporate CIO. I run a fairly large shared services organization from the infrastructure, security, policy, and strategy side, as well as nine clusters of application groups that support our 28 or 29 ministries within the Government of Ontario. We are what we call a federated model, where we have nine CIOs that are looking after business solutions on behalf of ministries, and who have reporting lines both into deputies, as well as into me as the corporate CIO. I also control the central hub, what you call Shared Services Canada, as well. We're a federated model, and that's how it works.
This is a two-part question. Is there a plan to further consolidate those clusters, and as part of the process of developing Ontario Shared Services, how did the number and the style of the clusters come about?
We are committed to clusters. We think that it makes a whole lot of sense to group like ministries together, because there's so much sharing that can be done between ministries. If I look at the justice ministries, for instance, there's so much integration that can happen there, that it just makes sense to have a single solutions applications group to look after them. We've had this cluster model since 1998. It works extremely well. Gartner have reported on it as definitely being an excellent model, from a delivery perspective and a service perspective. The clusters will change over time, and ministries change over time, as you're all aware, and we may make adjustments. We have seven, and now we have nine, and we can go back to eight, but, generally speaking, that cluster model will stay much the same way.
In terms of asset management, we've heard a lot about the asset management being a problem and the inputs into Shared Services Canada being difficult to tabulate. In Ontario's experience, was the asset management plan put in place before the transformation and the grouping of the clusters occurred? Does it continue to be a challenge for Ontario? What teachings can you provide us on how to properly do the asset management trends from departments into a shared services model?
From a historical perspective, we started with clusters back in 1998. Clusters still had a fairly strong semblance of infrastructure within them. In 2006, that's when we did what you're all talking about here, which was to create that shared services organization and to pull all of the infrastructure out from the clusters into a central group.
I'd say that asset management is an ongoing challenge. You're big. You know that. You're very big. We are around 63,000 people. It's a hard enough job keeping track of what 63,000 people are using—and that's right down to a BlackBerry, a PC, a tablet, a server, or a mainframe. As you move into the data centre, you absolutely know what you have 100%. You know how old it is, how long it's been there, when it needs to be refreshed, and what version of software's running on it. You have to. If something goes wrong, you have to fix it. I think when it comes to our ability today, from an asset management perspective, I think we're in good shape. I'll never say it's perfect, but we're good. Prior to 2006, I would say that individual clusters, which had accountability for asset management back then, had a reasonably good handle on what they had. It was probably not perfect, but I think it was reasonable.
Asset management from a future perspective is something that we are always talking about and always challenged by, but that's far more on the software side than the hardware side. Software is where it's tough. Software worries me a lot more than hardware does, to be honest.
With respect to the human resource concerns, we heard maybe a bit of conflicting testimony from the previous group, in that they said they had all the experts, but then also that they did not necessarily receive—maybe it was alluded to—the experts they wanted at the administrative level. How does Ontario address human resource concerns with its information technology staff? In terms of the cluster model, is there still an issue of pulling people over from other departments into your group, or have you worked through all those issues?
We're done. We did this back in 2006 and 2007. We moved 1,200 people from eight or nine different organizations into what we now call ITS—analogous to your Shared Services Canada.
I totally sympathize with some of the comments I heard. Again, I go back to how the people you have running boxes and wires are quite different from the people who are supporting or developing applications. The difficulty becomes sometimes the support staff. Maybe that's where they were going a little bit on.... Did you get all the right finance people over, or did you get the...? Some of the support side can get more difficult.
Yes, people don't give things up willingly; you have to go and dig it out. It's why we felt it was very important to have baselining exercise. These baselining exercises that we've run over the last 10 years or so have been critical for us. We've invested a lot of time in digging out detail, because that's what you really need to do. We've looked at our baselining as core components. Every time we've taken a transformation step, we've been very specific in our baselining. That's an important part of what we've done.
Where do we start? In Ottawa, your departments, your ministries, still have enormous control, certainly on the application side of their business. In 1998 that was changed in Ontario, and clusters were formed. Clusters can range from one ministry—we have one cluster for health, for example, because it such a huge department—but another cluster may have five different ministries. By the sheer nature of it, you loosen the ties of fiefdom and ownership that may exist within certain organizations, and you create that sense of more horizontal sharing across ministries.
Our system is a silo system. That's what we live in. What we tried to do is to create that horizontal view across ministries. Sometimes it works, and sometimes it's a struggle. With Shared Services Canada, it was a terribly blunt effort they had to take. It was tough. Really, it's hard work to do this stuff. Ministries are very solid organizations, as they have to be, and to try to drive horizontal lines can be difficult.
A previous witness talked about a transplant: taking apart a ministry and putting it into this large figure. You've just referred to ownership. Is it your feeling that within Ontario, within a specific department, those involved in IT feel that they are part of your structure? Do the IT people belong to the department, the ministry, or to your structure?
Formally, our cluster staff will have a reporting relationship into a home ministry. I belong to Treasury Board. All the clusters do not belong to Treasury Board, but I do all the CIO's performance plans. That's what the federated model is. You have that true matrix environment where you're putting CIOs into position where they have an enterprise role—
On the Shared Services Canada side, we're identical. It's only when you get into applications, business applications support and development, that we're different. From an infrastructure perspective, we are identical to Shared Services Canada. There's no difference.
It is still expected that we could, as taxpayers, generate some savings with Shared Services Canada. What about you after 10 years? Have those, you know, political savings materialized or have they vanished with a cost overrun?
Our beginnings were strict. We had a two-year time frame to deliver on our our target of $70 million in infrastructure savings. We delivered that $70 million in infrastructure savings in two years. That was in 2006-07 and 2008-09. We did that, it was audited, and it was done.
In fairness, we picked a lot of low hanging fruit. There's a lot of low hanging fruit. When you bring together so much stuff, there's always stuff that's going to fall off the tree.
We started our next phase of rationalization we in 2012-13. It was tougher because we did another baseline: where are we to market, how good are we, how bad are we? Since then we've taken another $70 million out of our infrastructure budget. That's on an annual basis.
We're focused on two things: service and efficiency. I think on both sides we've done well, but on the efficiency side we have driven what the previous people were talking about: the true promise of Shared Services. Service has to be one. The other one is efficiency. I think we've proven the efficiency is there for sure.
Like me? No. It would have happened. We have great process in place. We have this desire to want to know how we're doing all the time. We run baselines, and we benchmark ourselves. We've done three rounds of baselining and benchmarking. We know where are we compared to the market. It's important for us to know. Are we doing well, or are we not doing well?
It's a constant theme. For those of you who read the Ontario budget, you may have seen that we have another target in IT. We have a $100 million savings target that we have to achieve by 2021. It's a continual journey for us.
Increasingly it seems that government records are not being kept in a paper format, but in electronic format. In the Ontario government, there was a major scandal and a police investigation involving the deletion of government records. That was occurring in the area in which you were working.
I wonder if you could speak to the lessons from that and if it has any implications for how government IT services ought to be organized.
I don't see a connection at all between anything we've done in Shared Services and records management. I think records management is a distinct subject. It's a strong policy driven discipline. There's lots to read about records management within the Ontario government. I don't think it's the right place for me to be commenting on it. I don't see a connection between that and what we're here for.
I guess one of the concerns in Ottawa has been the increased centralization of power in the office of the Prime Minister, in particular in the hands of the Prime Minister's political staff. I wonder if the centralization of IT could make it easier for the Prime Minister's political staff to interfere with the management of government or public records.
You have explained some differences between the type of structure you have in the Ontario government and Shared Services at the federal level. Notwithstanding that, do you have any thoughts about what the top few problems were with the way Shared Services was implemented federally?
To be honest, the scale of what happened here is just so different. I got to know Liseanne well. I got to know Grant and Benoît well. We had lots of discussions.
You talked a lot about it here today: the understanding of what existed is very important. You have to know where you are starting so that you don't get caught in this treadmill of not knowing how you are doing. Are things are okay? Are things moving? Are things not moving? I think they all said it. Probably, if SSC had taken its time at the beginning to really baseline what existed—not just from an asset perspective but from a service-level perspective, because it is service levels that will get you—it would have been very different, because expectations could then be set reasonably, as opposed to perhaps some people not being reasonable.
I look back at what my bible was, because for two years I ran the integration project for what we did with our shared services. I had a book of our baselining data, which was very detailed, so I knew everything that had come across from clusters into what we call ITS. I knew the service levels that were provided, and I knew the cost that went with that. We did not bring any money over. We very purposely implemented a chargeback facility, so we didn't take budget from ministries. We left the budget out there. We wrote service-level agreements, and we billed. Certainly, looking back on it, I have no regrets. In fact, we still do that to this day, where our shared services organization has zero budget. It has no base funding whatsoever. It charges for its services. There is an overhead to that. It is weighty at times. After 10 years of doing this, I think we can probably start to look at moving off that rigid zero-based budget and maybe going to a more mixed, hybrid mode. In clusters we do that. We have some base funding: salary, wage, benefits, and core maintenance. Non-discretionary work is put in the base budget, but for anything that is discretionary, ministries still hold that money.
I think that, for our shared services organization, it makes sense that it would be coming somewhere into the middle ground between where SSC is and where we are now. I can't overemphasize baselining. You can't do without it.
Shared Services, of course, is an attempt to consolidate IT services and procurement in the federal government. There have been somewhat similar efforts to do that at the provincial level.
Do you see any potential for greater co-operation between the federal government and provincial governments in areas like IT procurement, where different levels of government might be buying the same equipment, potentially from the same range of suppliers?
In Ontario, any procurement we do within the OPS, the Ontario Public Service, we make available to anybody in the broader public sector, including across Canada. We don't restrict it. I look at the desktop and laptop contract we have, and I think there are over 500 broader public sector organizations that are using the same contract. They don't come through us; they go right to our vendor, but the contract is written so that they get the pricing we get. It is the same thing with our network and with a lot of our software contracts, which are written for BPS. We have been talking a lot with the feds over the last, oh gosh, ten years now about whether we can get to the point where, when we are doing software or hardware procurement, we can all share. You are there now. It is not terribly widespread yet; we are looking forward to when it is. There is no question that the buying power of the federal government is so huge that it will have a positive impact on what we have to spend on things. I certainly look forward to the time when we can do a lot more procurement together, as opposed to separately. Absolutely.
I have to apologize on my colleague's behalf. I don't know why he keeps asking about provincial politics. But don't worry; the last time the President of the Treasury Board was here, he was asking him about Saskatchewan politics.
To get back to the issue, were you there since 1998?
No question. The concept of horizontality had already been introduced. In 2002, when I came in, I became one of the CIOs for the clusters back then. There's no question that there had been a lot of work done to actually forge that relationship between CIOs. It's something we work hard on, and extremely carefully, to bring those CIOs together.
I'm not going to say it was sweetness and light. It wasn't anywhere near what SSC confronted; absolutely not. I think a lot of that hard, hard work of convincing people of the benefit of shared services had been confronted, but it was still a massive exercise in culture change to get people on board. It was. I mean, they'd been in those positions, even within their clusters, for eight years, and you had to rip them away.
I heard what Grant said, that you're relieving.... Some CIOs are much more comfortable in dealing with boxes and wires than they are with the really nasty stuff of applications. Clearly they were uncomfortable with that. I think we were a microcosm of what happened up here. We had broken some of those bonds, for sure, but there were still huge culture issues to overcome.
I think it's very much based on the relationship between a service provider, in this case SSC, and the people who are receiving that service. Not everything is going to run perfectly every night. It's just not. The strength of the service element that you develop as part of your shared services organization is critical. There are so many moving parts, and some of those moving parts will go wrong on a pretty constant basis.
On the process side, Grant mentioned the ITIL world, the standards around how you implement service within an SSC. That is critical, because you need to have process to fall back on. You can't be fighting fires on an ad hoc basis, on a daily basis. You just can't do it. On top of that, you really need to have that incredible relationship between whoever is in a position of responsibility for SSC and those CIOs. You live or die by that.
I think that's just the culture of what things are when you have an organization. In my case, I had two or three ministries to service. I was very focused on servicing those two or three ministries. If a server went down somewhere that impacted somebody's application, I knew who would be fixing it. When we moved into a shared services world, I didn't know anymore.
Culturally, for a CIO, you shake. You lose sleep. You don't know what to do anymore. This is why the process has to be absolutely bang on and the relationship has to be just humming, because bumps do happen, as you well know.
How would you address the problems that we have at Shared Services today? Do you see an emphasis on putting a focus on client relationships, as you just mentioned, and making sure that...? How would you get the buy-in from other CIOs in other departments? I think there's maybe a lack of confidence in SSC in some departments. There was a client survey that proved that. How would you go about it?
I don't know what it's like. I'll be brutally honest. I've not read about any of the stuff that has gone on here, but I would fall back on process. I think people need to have confidence in the process, and the process has to be an industry-standard process. It can't be made up. It exists. It's not rocket science. It's there. It works. I think the process of the service you're giving has to be laid out, understood, and accepted by everyone who's using the service.
I think the second thing is outreach. It's ensuring that your Shared Services people understand what the impact is when something goes bump in the night. They have to feel the stress and the worry that a front-line service provider would. They're not in the front line; we know they're not. They're not as close as they used to be. They're a bit further back, but it's important that you make all of your staff in that Shared Services organization directly understand what the impact is of what they're doing. They're not just a shared service. They're actually delivering services to, in my case, an Ontarian or a business. Without that, they have no reason to lose sleep at night....
In my case, certainly, I think back to 2007, 2008, 2009, and even right through to today, where we focus enormously on bringing forward real ministries, real people, to talk to our shared services staff to ensure they know that whatever the service is, whether it's a public safety video, a call to an ambulance, or whatever—it doesn't matter what it is—they recognize that it has a direct impact on someone on the street, or on a police officer or a corrections officer, whatever it is, and that they feel that. That brings it alive, then. They're not some abstract shared service. They're actually delivering a service that means something to somebody.
Mr. Kelly McCauley: Can you ballpark where that came from? We heard earlier that when we consolidated to 43 departments we achieved basically zero efficiencies across the board. Where did you generally find yours, both the low-hanging fruit and the more recent ones?
I would say that we chased down contracts. We really chased down contracts. In coming from distributed to centralized system, all of a sudden you get your hands on all the contracts. Really sitting down with your key vendors, talking with them about what this new world is, and renegotiating contracts based on that shared services model reaps huge dividends—huge.
If you go back to our old days, we would have had multiple network contracts. We went for a single network contract. We're now on our third iteration, and every single time we've taken dollars out of that network contract. It's had a huge payback for us.
I would say that on the rationalizing side, we haven't taken huge numbers of employees out of our organization at all. It was never our intent to. It was interesting to listen to the earlier conversation on how you engage people and how you keep people engaged when they're at risk. Certainly, one of the first things I said to our staff when they all came together was that we had—it wasn't official—as much job protection in place as we possibly could because we had to—
All of our service desk is completely automated. If you ever come to my office and you walk on our floor, you'll see a big screen up on the wall. We have literally real-time stats coming from our help desk. I know how many calls are waiting and how many calls have been made that day. That's all there for everybody to see, including me. If it goes red, I'll call someone. Basically that's what happens.
Anyone who calls gets a follow-up survey. There's a constant go-though between a cluster and ITS with regard to what they're doing.
Don't forget, we're all part of the same team, as well. It's really important. The head of ITS and the head of Shared Services Canada sit at the same table constantly with the CIOs. We are one team. We really are. We recognize that we are a little different from the rest of government in that we are horizontal. But we really do feel part of the I&IT organization within Ontario. We have incredible loyalty to a ministry, but we also have incredible loyalty to I&IT. That's that dichotomy.
No. Software, just by its nature, is squirmier than hardware is. Typically, you could plug in a hardware box and it's going to work 99 times out of 100. Software just isn't. It's tougher to test. It's tougher to implement. It's just a harder world.
Did you say that you instituted your SSC process in 2006? Okay.
I used to be with the Management Board Secretariat with the Province of Ontario, which did the BTI, and it was a disaster at that time. That was 1995 to 2000 whatever. The transformation systems were not in place.
Looking at lessons learned, how would you guide us? You're saying that, yes, we are on the right track, which is good. No due diligence was done. Our baseline in assets may have been there, but our baseline in human resources or skilled competency was not there. From the information, I gather we have probably achieved it.
When we chose the service provider, did we make the right choice or the wrong choice? What would you say with the benefit of hindsight?
When you did your service agreement, how did you do it with different clusters? What did you do? Was it the type of service or the complexity of health or complexity of community and social services? What did you do?
They'll all have very different wants and needs. Even within a ministry, as you know, there are different wants and needs.
If you look at Service Ontario, they run 24-7, and they expect their services to be up. If you go online to renew your driver's licence, you want it to be there at 8 o'clock at night or 4 o'clock in the morning. We would have a very different service level agreement with Service Ontario for driver's licence renewal than, let's say, what we would have for our payroll run. Our payroll run happens once every two weeks. It's hectic for a shorter period of time. Once it's done, it's done. Then they're into maintenance until the next payroll run.
It very much would come down to a business requirement, what is required per application.
How would you conduct your needs analysis? Sometimes you're given a system, and you do not do your needs analysis and you deliver something that's not utilized properly. How did you do your needs analysis within those arenas?
—so you would never have a separation. When we're doing an enhancement or doing an upgrade or doing a brand new system, the team consists of both infrastructure as well as cluster. There should never—I shouldn't say never, there always will be—be a gap between what infrastructure is providing to applications and what applications are providing to clients.
No. Is it based on usage? I understand there was a glitch in one of the community and social services systems. When a glitch occurs, and there is price that the politician pays, nobody else pays, how do you—
What do you charge, and how is your cost...? I mean, we're looking at moving forward, and that's a good model, but we don't know whether it will move that way. How do you do that? What sort of service agreement do you have with them?
What we do is to have a price based on whatever infrastructure is required to run the application. If there's an application that needs this quantity of server, this quantity of data storage, and this amount of network connectivity, there's a finite math you go through to come up with what that costs on an annual basis. That's what the ministry as a customer will pay for that service.