Systems Under Development Best Practices Symposium

How do We Make it Work?

Roary Butler

Roary Butler is currently the Director of Information Services at Alcan Aluminum Limited. For 35 years he has been involved in the changing relationship between information technology and industry needs. After spending 15 years in the manufacturing sector, he entered the competitive world of financial markets. As a senior Vice-President, he developed a market-adaptable functional service. When he returned to the manufacturing sector, Alcan Aluminum Limited assigned him the task of directing and structuring informatics to service the corporation in its activities on the global market.

I saw the article that said, "systems development". What you're going to hear today is 10 minutes of 35 years of experience. I've drawn some things up, and I'm going to leave them to you as an exercise. You can play with it when you go back.

I'm going to relate how we've done it at Alcan. If it stimulates thought, Montreal is about two hours away, and I'll gladly participate.

I won't go into the material that you were going into, this morning, on organizational structure and how you create ownership. If you haven't done that yet, then you're in real trouble. I'm past that. I'm into actually developing the product.

If you're going to be judged, what you want to know is who's going to judge you? Who are the judges of whether we're doing a good job in developing systems? Clients? The project team judges itself. Client management, IT management, and eventually senior management—those are the guys that judge me.

What do they judge? Here's a non-exhaustive list of what people judge when they judge a system's development. The price: what does the thing cost? Have you ever seen anybody who's been happy about how much you charge them, or how much a system is going to cost them? Never. Before they even knew if it was going to be successful or not. "On time, on budget"—that's the way most people judge things.

Functional conformance. I think the most critical one is expectation conformance. I had an earlier meeting with all my systems managers from around the world, and I said, "How many believe that you're actually managing something? What are you managing? Are you managers of systems?"

A hand shot up. Wrong! When you're in a service department, you are not managing systems. You're not managing anything concrete. What you're managing is expectations. That's why our methodologies have failed us miserably. Have you ever seen a methodology that establishes the expectations of the individual?

I just came out of three days on a project to redo all the financial systems of Alcan in the world—$180 million, it cost us. We did some benchmarking exercises. We've got to take 30 per cent out.

Some consultants that will remain nameless were given the freedom to do a feasibility study. They came up with 16,000 mandates of external consulting, 15,000 mandates of internal people, $55 million project, and $8 million IT. What do you think the focus of the all the discussion was on? IT.

These guys have their wires crossed, haven't they? Yesterday, I told them, "You're dead".

What are you going to do? You're going to go back and develop a vision of where you want to be in 10 years. You're going to re-engineer the whole thing, fire 30 per cent of the financial people—which is what we want to do anyways, right? Then, we'll do the RD."

Expectations. We want to restructure the IT. What they wanted to do is to get rid of 30 per cent of the people. You restructure IT, and five years later, you still have 100 per cent of the people. Are you successful? You're dead; that's what you are.

People judge maintainability, portability, user-friendliness of information. We just finished a world-wide IT assessment. The first thing that we did was to give about 15 business imperatives. We said, "We want you to rank these business imperatives, and we want you to try to arrive at some idea of how critical IT is to the business imperatives."

The very gratifying surprise to me was that our managers rated access to pertinent information number one. Our managers learned from GM. You walk around, you touch it. If you can't touch it, you can't manage it. I don't know how long it has taken for our managers to realize that information is a tool to help them go out and validate what their people are doing and support what their people are doing.

We put a plant in a place Terre Haute. We closed a plant of 3,000 employees, and put a new plant in with 500 employees doing twice as much of what the other plant was doing. The manager could walk in, in the morning, look at the screen and say, "We have about 20 indicators. Do a good job and it's resolved. Let's play golf."

The plant wasn't doing very well. They brought a new manager in. The plant started improving - still not doing well, because there are some design flaws, but doing much better. When we asked that manager what he did and what role information management played, he said, "You know, when I walk to the screen in the morning, I can look and see what happened. Then I go down to my people and tell my people how good a job they've done, or what they messed up." This guy knows how to use information. To see that happen was absolutely fantastic.

Technology performance is passé. Speed the delivery. I mean, if you can't do it quickly, then don't do it at all. You're dead if you can't do it quickly. I get a newspaper. The newspaper boy comes at 5:45 a.m. to deliver my paper. How much tip to you think I give him, as compared to the other kid who came at 7:15 a.m.?

Who judges what? Try to develop a matrix between those issues, and who judges them. There's a little ledger on the back of it. You see that client management is pretty much universal. If you don't know who's going to be judging what, how can you do your job of implementing? Of keeping them informed? Of getting them to participate?

Who said that managing a systems project is just like managing anything else? Absolutely not. In French, we say, " le rôle d'intervenant ".

In the systems project, it's much broader. There are people that participate in a systems project—the janitor participates in the thing—and you don't even know about it. You'll have to go through that exercise yourself. It really helps.

What do they measure? Again, a non-exhaustive list. Competitive knowledge—if you're fortunate enough always to be hiring consultants, then you have competitive knowledge. You go out and get competitive bids. You can elect the prices.

What if you're dealing with the guy in-house? Again, I'll come back to that other issue. The guy knows that he got a deal. He goes with his friend from financial management and has drinks, and he says, "I got that for 50 per cent of the cost. You didn't."

Schedule adherence. Test results. Scope. Change. I mean, I don't know how well you've managed scope, but do we manage scope! I don't know if you do this in government, but I have people that give me estimates on projects with contingencies. Do you have contingencies here in your projects—you know, 20 per cent?

Do you know what these guys did? They came to me with a contingency of $1.2 million on a $7 million project. Do you know why they did it? Because the users didn't know what they wanted. You go to engineering school, you build up the contingency, and the users don't know what they want.

Do you know what else they did to me? They had $800 million in those projects on people who were controlling quality, controlling performance. What do you want? Do you want people to control, or do you want a contingency, because you can't manage?

We took one of them out. We took out contingency. We took the $1.2 million, and we gave it to the Vice-President who is in charge and said, "Hey, how does it feel to be holding $1.2 million in contingency?" It's his, nobody else's.

We manage scope. If you don't manage scope, your project will never finish. That's where you get most of your overruns.

Responsiveness to change. Use of technology. Migration of use. Again, information access. Response time in technology—I'm amazed that we still talk about response times. Delivery lead time and product availability—I'm going to touch on that in a minute.

The last item on the list is contribution of benefits. We deal a lot with critical success factors. In this IT assessment, we asked every business unit to establish what its four critical success factors were, rated IT accordingly, and they rated satisfactory in all the things that they were doing. I don't want to go through all the critical factors, because I don't have time. I'd like to focus on a couple of them. You can take this away and do your own.

Here is one that I think is critical: how we manage with this ownership principle. Obviously, there is someone asking questions before looking to get some auditor fired, I think. I'll tell you, if he gets fired, I get fired. That's the whole principle of ownership.

If you don't do this as a team, you shut it down. It's not going to work. I don't detect in this room a lot of team spirit between the different " intervenants " and the systems project. In our business, we do a great a job of going down to people on the floor and saying, "We're going to build teams." We spend a lot of money building teams. Look at the management team, and see what kind of team is there.

Delivery lead time—this is what I ought to focus on a bit. Small deliverables? You deliver big things, or you're never going to deliver. I'm no expert on how people deliver systems in government, but I hear things. I didn't know that the word "small" existed for systems in government, from what I hear.

Value focus. I mean, if it's not focused, we shut it down. I can guarantee the 20/80 rule: 20 per cent of the effort gives you 80 per cent of the benefits in the systems project. Guaranteed. For example, the blue coloured screens. I guarantee you, they'll hit you with 25 per cent of your project cost. What are they going to give you as value in the business? We focus on it. If it doesn't add value, we take it out. We don't just let it go; we don't put it in.

Productivity improvement tools? Absolutely. There are so many of those coming on the market today. Business contribution? We simplify the process. We call it "processing simplification". We simplify it before we do anything in automation. We "kill" a lot of people in our process, too.

One big problem we have is lousy business matrices. You know, you read all these books on value and value of IT. How many times have you tried to measure a project's success after the fact and found out that the business contingency has changed 10 times? What am I measuring?

In a large project—and we have very few—if you can't establish the matrix up front, you don't have a project. Somebody was talking about the tangible/intangible stuff. If you can't measure with a matrix, if you don't understand the matrix, you don't have tangibility. I don't take intangible stuff. I don't believe in it. It doesn't exist.

Another problem is insufficient commitment to benefits. We have problems having clients who are willing to make sure the benefits accrue to the corporation. I don't believe it's just a question of taking it off their balance sheets. I don't know what the answer to that one is, other than to replace most of their managers. We're doing that, too.

Good success factors. These are the "GSFs" that go with the different issues in Alcan's approach: architectures; packages—we're getting a lot of packages; application generators; standardization; portability; tools and techniques—we use them extensively; the information access tools.

Let me just back up here. We over-configure technology. It costs so little. Who cares if you spend 20 or 30 per cent more? You're going to spend it anyways, if you've made a mistake. You're going to have to come back. We just spend it right up front: a lot of prototyping, price, package solutions - that is the ultimate GSF.

I have a neighbour down in the country south of Montreal. He called me one day and said, "Roary, I've got a tree that's cracked and lying over the electrical line." He knows I have a chainsaw. He said, "You want to come over and look at it?"

I go over and look at it. Sure enough, there's this tree that's cracked over the hydro lines.

He said, "What are we going to do about this?"

Well, you look at the options. What can we do?

We can call Hydro Quebec and tell them that there's a tree that's about to crash down on the line. Two weeks later, three weeks later, they're going to come over and cut it down.

We can wait for a wind. By a lake, it's going to be windy. The tree is going to come down on the power lines, and is going to rip everything off the wall. Hydro Quebec is going to come down and fix it.

Or, as a team, we can cut this tree down. The fact that it's beside a hydro line is just one of those risk factors that we get scared of when we do these things.

I'm an expert woodsmen. I said, "Jean-Marc, let's get a cord. You pull the cord, and I'm going to cut the tree down." I got up there with my chainsaw and said, "Are you ready?"

"Yes!" I start cutting; he's pulling. As the tree gets closer, he's pulling harder.

"Are you ready?"

"Yes, I'm ready."

Snap! The cord breaks. The tree falls on the line. The line comes flying over the walls. Sparks all over the place!

What do we do? We call Hydro. Now, Hydro is in the crisis mode, right? There are sparks, fire. Two and a half hours later, Hydro is there. An hour later, everything is fixed. The line is back up. The walls are fixed. Everything is fixed.

Have we got success? I'll tell you, we've got success; but more important, you know this man is now my team member. We messed it up together.

Dr. Kenneth Tucker

Dr. Kenneth Tucker became President of MESSAGZ, on August 1, 1993. MESSAGZ is a new Canada Post Corporation division created to provide customers with electronic and hybrid products. Formerly Dr. Tucker was Vice-President of Information Technology and Strategic Development, Canada Post.

Dr. Tucker is an electrical and aeronautical engineer, holds an M.Sc degree in computer electronics and a Ph.D. in Cybernetics. Dr. Tucker has taught at McGill University, Montreal; he writes and speaks on information systems, management and the future of Canada Post.

How do you, in fact, get more funding than you've been getting at the moment? I suggest that, certainly in the private sector, the current Corporation sector, funding is a really interesting thing. There are two types of money: capital money, and expense money. It's the capital money that you need to build projects with. That's very rare stuff.

We're a $4 billion corporation. We spend roughly $400 million in capital. Much of that goes to the hard side of the business, to letter sorting machines, and things like that. You can imagine that the IT projects don't get too much. We used to get about $100 million out of that $400 million, about 25 per cent -- more than our fair share, a lot of people said. But, we can still find ourselves with a backlog of several projects, any of which can be justified in terms of reducing the operational cost. Then we can't fund them. There simply isn't enough money to go around.

The solution is what? One of the solutions that we found was, in fact, to look outside. There are a lot of people outside. What has happened in the business is that we have a maturation, and we have people who are, of course, systems integrators out there.

Are they better than we are internally? The answer is, man for man, woman for woman: no. How come we use them? What can they do that we can't do internally? I'd like to spend a couple of minutes talking about that.

If you take a typical project life-cycle, you've got a big bulge when you're developing it. There's a reasonable amount of money to spend in operations.

We said to a number of people, "We have no money, but we want you to build us a system." After they got through with laughter, we said, "We're serious. We want you to go to your bank and borrow money. Go to our system. We won't pay you anything. What we will give you is this: if you produce and it works, we will pay by the transaction when it works."

In other words, we suggested that we will start paying when operations start, and we will pay over a period, the life of the party itself. (I've ignored the cost of money, and I've ignored profit, for simplicity's sake.) We will guarantee the minimum number of transactions, and they will recover their cost over that period. This is a good way of doing business, right? First of all, if you sponsor people in this way, you get their hearts and minds for five years. You certainly get their hearts and minds from the beginning. They have to produce best practices.

The best thing to do in the world is not to solve a problem, it's to dissolve a problem. Don't solve it; make it go away. What we've done, with a couple of our major projects, is exactly this.

We told a company that, if they build it, and they support it over a number a years, they're guaranteed that income at that rate. Of course, if they spend a little longer in this period, all they do is force back the time when the payment starts. Guess what they are given incentive to do? Incidentally, they have to maintain it over this period, so they're not given incentive to build something quickly and drop rubbish on us, because it belongs to them.

The next thing that you'll find is that there are people out there who are quite interested. They've converted from a business of feast or famine, or the lottery, into one where they want to be part of the business.

We have said to one particular company, "We won't pay you on line A, we'll pay you on line B. You'll never recover your money with us, but you can go and promote this system. We'll allow you to plug as many people as you like into the system, and we'll share the profits with you." Now we've made them very interested in some of the systems that we want.

Some of the systems that we want are peculiar to Canada Post, but very few are peculiar to Canada Post. For instance, we are building, under this arrangement, a national system that is available for all sorts of people in Canada, and of course, for other postal administrations. The systems integrator has caught on to this and is promoting this project. It's a different way of getting best practices.

I'd like to tell you another thing about why it is that these people, in economic terms, have comparative advantage. Thirty seconds on economics: Ricardo, in 1817, proved conclusively that, although Portugal could out-perform England in both growing wheat and making wine, the best for both of them was for England to concentrate on growing wheat and for Portugal to concentrate on making wine. If they did that, they had more than enough to satisfy each other, and there was some left over.

Incidentally, captains don't understand economics, I find. It doesn't matter that the guy outside is more expensive than the guy inside, if there is comparative advantage. It doesn't matter in this case because there's absolute advantage as well.

How is it that somebody who has to make a profit, who has marketing costs, can outperform the internal group? If you assume that the schooling level is the same to begin with, the answer is that they learn through the systems. If they really do become experts in a particular area, they are building a system for the third and fourth times, whereas, every time internal groups build something, it's the first time.

An excellent example is Systemhouse, who built their first track-and-trace systems by copying our existing track-and-trace system, which we use for another type of mail, our so-called Trace System. They probably didn't make much money on that. I think they have sold it five times already. There's another example of best practices.

In conclusion, I'd like to say that the best practices may not have to do with how you manage projects, but how you manage getting the projects funded and worked on. In fact, some of the issues you've talked about today might not be terribly relevant to you as people in the shop end, but more relevant to the systems integrators.

Mary Baetz

Mary L. Baetz is a Director of Western Management Consultants and has been a management consultant since 1978. Her fields of expertise include organizational development, planning for productivity improvement, human resources, managerial and professional effectiveness and managing the human and organizational effects of office technology. In addition to her consulting experience, Ms. Baetz has ten years of industry experience.

Ms. Baetz is the author of "The Human Imperative: Planning for People in the Electronic Office". She is active in many associations including Organization Development Canada and the Couchiching Institute for Public Affairs.

As he was about to be speaker, he said, "Well, that's because they're waiting to find something to question—something new."

I thought about it. We did have a lot of topics, this morning and early this afternoon, that hit the same thing. I have some questions for you, so I can focus my remarks a little better.

How many of you currently link your IT plans or systems plans to business? How many of you currently have project steering committees and/or other kinds of project management, methodology, tools, etc., that you're using? How many of you would currently say that you have user involvement or participation in the projects as they go on? How many of you are using some sort of a phased approach, most of the time? How many of you would say that you and your executives are happy with the returns and the results that you're getting?

We've talked about all these things. I don't think we've talked about the things that make a difference.

Otto Brodtrick was here earlier. He did a really interesting study on: if these are all the impediments, how come some people get around them, and still do good things? It was his "best-performing organization" study. Well, what I see today is that, despite all these best practices in which we're all engaged, we don't have well-performing systems projects or systems implementation projects.

My question is: why? Not what's best-performed: what are best practices. We've been talking about that for 10 or 15 years. The question is: once we know what it is, why don't we do it? What's getting in the way?

The importance of the plan: there's not one of you who can get funding if you don't have a plan, right? We've learned that one. Is it complete? Is it realistic? Does it allow for some benefits if we get shut down early? I think we're learning those things. Incremental phases.

Look at the implementation plan. That's my concern. I don't believe there's anybody I've seen that really knows how to put together a decent implementation plan. It's the most "euphemistic" part of the overall plan. It doesn't demonstrate that we really know what's going to be involved. Worse yet, we don't even make people carry them out. You only have to look internally.

In the last few months, I was dealing with a lady in one department. She was busy cursing her screen, because she couldn't get it to work.

She said, "You won't believe this. I got a call last week, saying that I was going on training."

This woman is at a very senior level. Her call was, "You're scheduled for training next Thursday and Friday." Training for what? "Training for the new system." What new system?

Then she went on the training. She came back, and she needed help. She called down to the support phone. People on the support phone couldn't answer her questions.

I said to her, "Ask to look at the implementation plan for this new system."

She did. She called the systems group and said, "I want to see your implementation plan."

Guess what was in the implementation plan. Communications. "We're going to let everybody know this is coming. They're going to be involved. We're going to spread this out. We have all this user support money. When the users get back, the users are going to be supported. Right?" It was all in the plan, but it wasn't implemented.

If we know enough to put it in the plan because we're now getting asked some of the right questions by managers, we're not implementing it because we're not doing that in a way that's in phased projects. We go to Phase two. Nobody ever asks us if we, in fact, carried out the plan we put in Phase one. We're just allowed to move on.

The second thing to enhance is success. Define success ahead of time in realistic management terms, in ways that mean it can be measured as milestones. Ensure that the true "go/no go" decisions get made.

Peter, this morning, talked about multiple matrices. I think you have an example in your departments, in the redesign projects, where they spent a lot of time on designing matrices about what success meant—in absolute business terms, not in technological terms. I might quibble with them that I think they had too many. But, I think, that's probably a high-class problem. At least they bothered, and they defined it quite specifically in terms of business outcomes they need to have.

It's not only the outcomes in terms of service to the public, etc. I think there are some criteria that go beyond the hard-nosed business or technical criteria. I think there are some about what your expectations are for people in the organization—impact on people, impact on work, impact on the power structure, impact on information sharing. What will you define success as in those areas?

Taking the down-side as well as the up-side, you have a situation right now, and one pilot in one department where the line managers have been given access to each other's financial information. They have learned that, if they get together, they can say, "In your budget, you have excess over here, and I have a need over here. Why don't we have this little negotiation." They decide what they want to do with their money. They then go to their head of finance and say, "We've negotiated this. We want this to happen."

The head of finance says, "Sorry, you can't do that. I've got an agreement with the ADM that any money that comes up surplus I get to give back to him."

We're going to have a major power struggle going on as a result of the transparency of the information process, in terms of budget, and the non-transparency of the agreement process that's going on inside the organization. Were they aware of what kind of plans they have?

I'm going to be rude and disagree with my host here. You do get paid in intangibles. I think they are one of your success criteria, and one of your business benefits.

Roary said it, and he's dead right. There's a lot of research to support him. Rewards such as better jobs, rewards such as learning, rewards such as the ability to provide better service and not go home feeling used at the end of the day are factors that people take into account when they make a conscious choice to give a little or a lot—to retire on the job or to go that extra mile for you. In these days of restraint, when you need every minute of every hour out of the people you've got, because you've got so few of them, you do not need your people opting out and deciding, "I'm going to work to rule."

Why is "work to rule" so scary? An organization is built on the assumption that people are going to give beyond the rule. If we start taking away the motivation for them to go beyond it, and if we build systems and justify our systems under the premise of only tangible benefits, we will not get what we thought we were going to get out of them.

I will also argue that, if you don't understand what the intangible benefits are, or could be, you will not budget for them. You will not budget the costs involved in getting there. You will not understand, when you cut parts of your budget, that you are undermining these potential or actual intangible benefits that may, in fact, be the ones necessary to make your systems work at all.

Richard said, this morning, about the program delivery systems, that you get them in quickly and that those kinds of things are the way to succeed. I didn't get a chance to ask him what he meant by success, but I can argue just as strongly that I have seen an awful lot of program delivery systems go in on time and on budget, or at least on time, because some ministers said that this would happen or some legislation said it would happen. A year later, that system is still not performing. People are still not using it. They're running duplicate systems. They are running bootleg systems. Just because you've got it in quickly doesn't mean that you've got success. That you were up and running may be one criterion, but it's not the only criterion.

"Building-in" challenges. This is one of the things that, I think, we do very badly: we do a pretty good job of planning; we do a terrible job of challenging the plan in terms of its appropriateness and in terms of movement to date. When you link the rewards system for the project managers to project success, they have absolutely no incentive to stop the projects at any time. They are going to fail if they stop them, even if that is the honest thing to do. They're going to fail otherwise; so, why not delay the inevitable?

You need a built-in challenge process that recognizes people can get over-committed to a system or a project that's not going well; that escalations are not being truly criticized; that milestones are not being met, or milestones are being changed. The definitions of the milestones are being altered subtly or not so subtly. Everyone is colluding and making that happen.

We need, in the present, measures of prior successes, including the success of the users. I can't tell you how many times in the last two or three years I've been called into a project that's under way. Phase one was a prototype. They did the prototype. The technology works great, but users have said it's a dog. They ignore the users' input because, they say, it isn't bad, and they tell you what the fixes are. That's the whole point of a prototype, right?

They say, "Well, we didn't budget for that. So, we're going forward with this one. Our criteria, against which we're evaluating our prototype, may not be consistent with what we're viewing as overall successes, but we don't want that data. So, we keep going."

You need to make it possible to change the plan without dishonour. It's not easy. Gordon was demonstrating this to some degree when he was talking about the Statistics Canada planning process. He was saying that, in their planning process, they lay out what you're going to do. You're going to hold to it. And they have a process for you to go back, because, in fact, the world does change.

The most important thing is that, if we're going to build in a change process, the change process has to take into account the impacts of the change, such as moving the budget away from the things that we know, and the likelihood of success of implementation.

I'm involved in a number of projects where, when the system starts to get out of control, the money gets pulled out of training, communication, implementation, physical redesign of space—all the things that are going make the people want to make this a success—and gets moved elsewhere. If you're going to rearrange the budget or rearrange the plan, there has to be a full and complete disclosure of what the implications are on the original outcomes. You've got to have a way to do that without dishonour.

Most of the organizations that I'm dealing with right now value persistence in management. They think that anyone who says, "I've got a problem," is being a weak person. They don't want to hear about problems.

I've got a great example from a cartoon. A guy comes in and says, "Sir, it looks like the project isn't going as planned." The manager stands up, throws the guy out the window and says, "I'm going to kill you and all who look like you!" In the third scene, he's sitting back behind his desk and says, "Why don't they come to me earlier?" We don't make it very easy for people to tell us that there's a problem.

My next point: is telling the truth. One of the most difficult things to do in any organization is to tell the truth. I run a course on planning and scoping projects, and out of the two and a half days of the course, we spend almost a full day on practising telling the truth. Telling the truth isn't valued, and everybody thinks they're going to get killed if they do it. We spend time on gathering stories where people told the truth and lived, on role playing the difficult situations in which you have to tell the truth, and on understanding the impact of not telling the truth.

If you want to succeed in your plans, you need to make telling the truth less painful than not telling the truth. You've got to figure out a way to do that, with public demonstrations that you mean it.

Is it so horrible to award someone publicly for purposely cancelling a project? When is the last time we did that? How did the press and the public react when Kim Campbell pulled out seven helicopters? You could argue it wasn't enough, but the chief reaction was, "Oh, she changed her mind! Oh, this is a terrible thing!"

How often do we do that inside our organizations? Make sure your information systems are telling you the truth. Most of the project management tools that I've seen can't be managed in such a way that the project is always on time, on budget. People are hitting their milestones in seven and a half hours a day, and are, in fact, being used on the project. The time-keeping isn't accurate. Most of the other things that are marked aren't accurate if, in fact, there are no incentives in the system for them to be accurate and there is no punishment for them being inaccurate.

My last point is: never underestimate the impact of your behaviour. We have all these things that we say are important—the best practices—and we do them. Ten good deeds are completely undone by one publicly thoughtless or demeaning comment. I've heard it all the time about systems methodologies. People will go out of the way to tell you why they don't work, not how to make them work and where they've been useful.

"Walking the talk": we say something is important, then we cut the budget. I'll give you a perfect example. A department was finding disappointing results in its implementation technology. They did an investigation, and they discovered that their training was inadequate: it was improperly integrated; it wasn't appropriate; it wasn't where it was supposed to be.

They rectified it. They established a training unit, integrated with systems functions, staffed with good people. They saw concrete positive business results. But they staffed that unit with term contract people, and on the 1st of April, they were all gone.

The people in the organization think the management team are a bunch of idiots. They got the business results they wanted, and the response is that they're cutting it out.

The impact of the behaviour, the consistency of the message, can work another way. One outstandingly different supporting action will send a clear message, if it's truly heartfelt.

I heard one story of a systems fellow who was having trouble because some of the ADMs in his department were telling him that they didn't think the system was a good system. It was an administrative system. It wasn't working for them, so they thought it must be a bad system.

He was talking to his Deputy about it, and the Deputy said, "I don't understand what the problem is. I use the system, and it's perfectly fine. It's easy to use. It gives what I need."

They thought about it for a minute, and then the Deputy went to every ADM and said, "Any problem that you've got with the system, let me know. I'm now the officially designated trainer for the executive group." They didn't make trouble with that system anymore.

What I'm trying to say is that we've talked of theory, we've talked about grand management things. What matters is our behaviour, telling the truth, focusing on what's going to make a difference, and measuring the right things, not just measuring. I will make a strong argument that the intangibles count an awful lot.

John Riddle

John Riddle was appointed to the Treasury Board Secretariat of Canada position of Director, Information Technology Management on June 10, 1991. He came to the Treasury Board from the Canadian Centre for Management Development.

Mr. Riddle was involved in the data processing of the 1971 and 1976 National Census at Statistics Canada. He went on to hold the posts of Assistant Director, Director, and finally Director General of Regional Operations during the period of 1978 to 1989. In 1984 and 1985, under the aegis of Interchange Canada, Mr. Riddle was responsible for opening and managing a Government Relations Office for the Canadian Gas Association.

Mary ended by talking about consistency in the message. You'll get the full impact of this by realizing that I'm about to give a "low-tech" presentation.

We're asked, now, to walk around in Treasury Board with our pockets out. We never go into a department, now, without our pockets out. Mel Cap regularly gets us up, and we practise how to say no. This low tech presentation would be perfectly consistent. You'll see that we really have learned.

When you have a panel that has never met, you end up with one of three things: a perfect synergistic linking of all of the talks; little slices that are unique; or all reports on the same thing. I'll leave it up to you to judge what, in fact, you're going to get. There is certainly some repetition.

I went back to basics. I reread the letter inviting me to come here. It said, "From your perspective, would you talk about critical success factors? What makes it work?"

From my perspective, there's a past, there's a present, and there's a future. That's as good a way as any to organize these remarks.

Let me start by talking about the past. I spent a lot of my career with Statistics Canada—very happy years, in which I learned a lot. I also had the opportunity of being involved in pioneering technology—things like bar coding in 1973. I've been through things like conversions. Wonderful word, "conversions"—it sounds so innocuous. Words like "redesign"—I've been involved in putting management information systems in smaller organizations such as CCMD. More recently, I've been a participant in the Board's effort to get us all up and comfortable with Microsoft tools.

What have I learned? I'd like to talk about the point of view of a project manager. Over all, most of the things that I learned were within my control. I could have changed them. I had control over them. A second thing is, as Mary said, that many items were relationship-based.

Here is a short list, and I won't spend a lot of time on it: focus, scoping, and holding on. To me, if you don't get the terms of reference correct, then the rest of it falls apart. You don't have anything to come back to. "This is what we've decided would be the best result. This was the deliverable."

This has been said by other speakers: focus. There are perils in being a pioneer. I'm not saying, "Don't be pioneer"; I am saying that, if you are going to be a pioneer, you should clearly calibrate that factor into your management style. The fact that this is an audit group, and we're trying to look at systems under development—we need to have that in the calculus.

I'm of the view that you should consult wisely, not widely. Everybody has a view. I'm not going counter to the culture, arguing that we shouldn't involve users. I am saying that you need to be more driven by those who can really add value to the subject of consultation. Clearly, users are one source, but consult them wisely.

There are perils of incrementalism. I saw some people smile when I talked about redesigning. When you talk about the redesign of a system, little words come in: "We want to make a modest change, or a small change, or a little incremental change." These things build. Be careful of that. Perils have slipped deadlines.

Gordon Brackstone, with whom I worked for many years, raised the fact that, when you're working on the Census, the Census doesn't occur on August 9th, it happens on June 3rd. The point is that you're driven by a timeline. There's a wonderful discipline when you have that timeline. (Again, this is somewhat repetitious of speakers' ideas this morning.) The peril of missed deadlines is that you're on a slippery slope. Those things build. You have great difficulty recovering that time.

I've learned about morale. Mary would agree. Celebrate small victories. You know you cannot legislate commitment. You earn commitment from people going the extra mile. You earn it by celebrating small victories. It also indicates to a team that you know where you're going. That's very important. It gives momentum.

I'm sure there are many other things that can be said, such as knowing when to stop the project. In the Treasury Board, we have another interesting tool, called "off-ramps". When we look at major Crown projects, we look for off-ramps: when could you get off the freeway? I think that, when we're starting a project, we should also take a look at what would cause us to decide that it isn't succeeding.

That's the past. That's what I've learned about projects.

Let me turn to the present. Since I am a Treasury Board officer, you probably would expect me to talk a little about framework. I'll do that briefly, partially because Andy Macdonald covered it, and partially because, as you see this thing layered out, I fear that you'll say, "Oh no! They're everywhere!" Maybe we can talk about that.

Let's talk about framework at the level of policy recently: 1993 policy. IT policy says, simply, this: it's a strategic issue. It has to be driven by business concerns. (How often have we heard that?) And there is the issue of information management. There's a lot more to it, but that's the short version of what the policy asks departments to address. There is aid on such things as how to do business plans, and the like.

The next layer would be strategic directions. (Again, it was referred to this morning.) It's still reasonably current. I'm happy to say that this is a policy that was very widely consulted on. It is a good example of policy. It was not shoved down; it was built by a variety of people, practitioners, people like yourselves.

The next layer is the whole issue of standards and architecture. How do we migrate? Incentives. There are (rather soft) incentives built into the framework. We have a partnership fund, where we are happy to fund somewhat risky ventures where we feel there's a high payoff, not only to the partners in this venture, but also to the government as a whole. There are community projects. We're looking for best practices. There are a variety of things that constitute this sort of high-level framework.

At the department level, primarily, there are things such as information management plans. This becomes the department's touchstone. There's a recent chapter on long-term capital plans. We got the Treasury Board to agree—I believe, in May—to the basic outline, and we're filling in the chapters, on the whole project approval process: risk assessment, project management.

Roary said that managing a project with IT is dramatically different from managing other projects. I'm in the other camp. Clearly, IT is an important function, but the principles, in my view, are the same. Major Crown projects are a whole chapter. But what of procurement review for projects that are over $100 million? I'm saying that, from a policy framework, there are now a series of applications that concern themselves with large projects in government, and there are other aspects to this business case, which were spoken about by Peter Greis—the idea of a balanced scorecard.

You know, he spoke about a year ago about "auction value". That's a wonderful concept, probably missing from most people's business case thinking. He also talked about getting the value out of the information itself. How does that get featured in business cases? We do need to do a lot more work on how business cases are applied. The Treasury Board added what we think are generic issues in a business case, but we've left the matter primarily to departments. I don't see any particular change in that thinking.

The next layer down I call corporate measures—measures for managing IT investments. If you looked at expenditures in government, you would find that the lion's share of expenditures is in the A-base of individual departments. They're not really reviewed. The A-base is broken up into programs. The Treasury Board doesn't, other than in rare occurrences, get into detailed reviews of programs.

I think there is increasingly a role—and we're asked to perform that role—to comment on submissions made by departments, where IT is featured in programs. We do that.

Ian Clark instituted something you may be aware of, called, "The Shared Management Agenda with Deputy Ministers". He actually sits down with deputy ministers and enters into a results-driven, issue-driven, shared management agenda. We have a role in that. We provide information that we think should be in that discussion.

We convene major file reviews once a quarter. I get together the common service providers— people who are doing procurement across government, such as the Government Telecommunication Agency—to look at major files.

We do peer reviews. (Reference was made, this morning, to ACIM and TIMS. These are large committees.) We've actually taken information management plans of departments and had them assessed by peers. The most recent one was Government Services Canada. Third-party assessments are also possible.

Last, but not least, is the CIO intervention. Recently, I heard Andy referred to as "the Godfather". I don't think he really warmed to that particular image. I think that anyone who knows him will know that he's practical, he's results-driven, and he isn't a wallflower. He has access to people: deputies, his colleagues. I think that you'll see, in his new CIO role in government, a willingness to intervene where the corporate interest is not being served.

The question was, "How do we make it work?" I think, and I hope to demonstrate, that we need to be considerably more vigilant in the applications of the policies, practices, and protocols that we have already.

Last, I want to talk a little bit about the future. Increasingly, IT is imbedded. We've heard this more and more. I would say that information technology is going to become, very shortly, simply a utility. It's buried in the programs.

I'll also go further and say that this may be the first and last symposium on systems under development. There are projects or programs under development, of which IT is a part. We were told this morning, and I believe we are seeing more sharing, more reuse, more purchasing off the shelf. We're seeing clients who simply specify functionality, which is essentially what Ken Tucker did. He said, "I want this, this, this, and this. Now, are you prepared to play ball?"

As it is largely imbedded, so the audit function is going to concern itself primarily with managerial issues. Much has been said about the role of internal audit, and ideas like "being more involved" were stated. I don't know what "more involved" means. I would simply say this: give them a specific role.

I don't think you want internal audit there simply as a caboose on the project team or just more weight. If you want them there, and you agree that they should be more involved, then, perhaps, get them to drive down on the business case. Perhaps they should look at how the information is going to be used: harvesting of benefits, client surveys, and so on. You determine that. I don't think simply having them at the table is enough; nor does it guarantee, in my view, better projects.

Finally, the meaning of insistence. You know, the Treasury Board was viewed as control and command. We never went to licence and laissez-faire . I do see a movement toward more insistence. That's where I see, partially, the role of the CIO and officers in the CIO organization to be selectively constructive, and corporate in their interventions with departments.

The conclusions I reached are the following. First, let's apply what we've got and not re-invent it. Second, obviously, we can learn from practitioners; that is the purpose of this gathering. I have certainly learned a lot. Third, manage outputs and results, not technology per se .

I know that everything is supposed to go in threes, but I thought we'd break the momentum. So, fourth, welcome intervention, be it from internal audit, audit outside, peers, the CIO. We simply can't afford to fail on large systems.

Questions for the Panel

Mary Baetz

The other important thing is that intangibles become tangibles over time. Morale, for example, can be proved to turn into things like recruitment cost, absenteeism, and other costs to the organization. The problem is that they don't tend to happen in the same six months as the cause. We have to have a time lag on the harvesting, if you will, of the intangibles. If you don't believe that intangibles count, and count for business purposes, why do organizations fight so hard to be one of the hundred best companies to work for in Canada, and put that in their recruitment, and do other kinds of things?

External Affairs was able to calculate that the cost of one person who had to be rotated home from overseas ahead of schedule was a quarter of a million dollars. They knew exactly what it would cost to have a failure, if you will, for whatever reason—whether it's a person whose health failed because of the stress of the job, or whether it's a person who could no longer deal with the situation. They were very conscious of this when they were rolling out the immigration technology and things like that, trying to help people overseas deal with any changes that were coming, in order to cut their costs. It's the kind of thing that, if you don't pay attention or build it into your plan, you won't cost it into your plan, and therefore, you won't be able to harvest any of those gains that come out later.

Roary Butler

How do you make it tangible? You say, "No." When a person comes and says, "This is an intangible," you say, "No, go back and do your homework." It's amazing how they learn in the process, how they grow in the process, and they come back and make it a tangible.

Q. We're all getting panned here. I don't really want to think this way. I had a question that was really the other way around. If technology is rolling at the rate that it is rolling in the government, and if we really select the best of our people to be the managers, can we not interpret this as having actually made it work? If technology is rolling and we know that we've selected the managers—the ones who hold the purse—from the best and the brightest people, would this be sufficient evidence of somehow having made it work? It's a success story.

Roary Butler

Q. Yes, I think. It's one of the most democratic countries.

Roary Butler

Q. I not saying that you only judge success. I'm saying, somehow they are the brightest people. They somehow spend the money wisely.

Roary Butler

Mary Baetz

Ken Tucker

It's easy to be hard on oneself, particularly for IT types because of the way that they think. The thing doesn't work perfectly, of course, in an IT environment. Some things are not perfectly understood in the business case. Sometimes, there is failure. Go back to the President of the United States: if he can get 55-45 support, he's doing remarkably well.

If I heard your question correctly, Sir, I think you're absolutely right. It is a success. Can we do better? Well, I hope so. But let's not flog ourselves.

Q. I have a comment on these proceedings. It's an observation about one of the factors that is hurting our performance as developers but that has not been discussed today. I think we are susceptible to the "superstar syndrome". We rely on our superstars. We rely on a superhuman effort in order to develop our systems.

We cannot be process-driven within the IT industry. We have methodologies but, this morning, Richard said, "How you get there is not important. It's the result that's important." I believe that. There are many ways of getting to an end result. It's the end result that you want, but not understanding how you got there can cause problems.

I recall the example that Richard gave this morning, of his son, given three out of 10 on his math exam even though all the questions were right. The teacher did not give him the marks because he did not show process. His son had used innovation, had used creative thinking to come to an answer. The problem is that he may not be able to use that insight when the problem becomes more difficult. Somebody may not be able to sit beside him and have that insight through the process of osmosis, and transfer it to another student.

That is the way that we used to train analysts in the seventies, before we had analyst process. We would say, "Jane is one great analyst. Sam, I want you to go and sit beside Jane. We haven't a clue what she does, but her results are terrific." Our method of training in the seventies was the process of osmosis.

In North America, 80 per cent of the money we spend on research is devoted to inventing tangible, real things: things that have moving parts. In Japan, 80 per cent of the funding for research goes into the process research. The value of process is to teach the ability to replicate the star's performance.

At lunch time, we had a definition explained to us, demonstrating being complicated and complex. I think we need to understand the difference between "rigour" and "rigid". "Rigid" is following a process or a methodology blindly—a guaranteed failure, most of the time. "Rigor" is understanding the process so that you know when you have to compromise, and you compromise on the basis of sound decisions. That's the difference between being a cowboy and being a sound decision maker. If you are unable to replicate a star's performance, the process is of little value. That's my observation.

John Riddle

The point of your question is, I think, that there's another dimension in the IT area. Most of the money and effort is spent on maintaining old systems. At any large department, my guess is, the 80/20 rule is in effect. We spend 80 per cent of our energy on just keeping the thing running. Twenty per cent is spent on the new.

I think there's an encouraging sign, that what you're talking about is that learning from that process is occurring. Sessions like this can also cause growth of the institute over at Government Services. That's a tremendous learning experiment and commitment to people. It is really quite an amazing success story, I believe.

The other thing is the issue of training entitlements. Surely, in the IT area, this is more than in other areas of government. We should be spending more on our people. It is complex and complicated, and speedy, quick—turnover is enormously fast. Increasingly, the system is reacting to the fact that we do need to invest in our people, and invest in them with discipline, with some rigour, with some process. I'm sure Richard would not discount rigour or discipline or the process. He was simply making the point that we should keep our eye on the ball, which is the result. I think he would say that.

Roary Butler

I don't go for half-results. To me, nearly good is not good enough. You're good or you're not good. I know that superhero is going to make me good. I'm going to go with the superhero.

The complexity of the systems project is tied in with the difference between the engineering process and the people that are involved in that. How many technicians do you know that have the human skills and the self-confidence to run all these projects? That's what I think is complex about these systems. That's why, I think, we have these superstars.

I did some work with a consultant from the U.S., trying to establish the characteristics of a superstar systems project manager. You're not going to find those guys. What we do is make the projects so small that we don't need the superstars. If someone messes up, that just messes up the small project. I'm not going to risk it. That's our answer to our problem of not having superstars. We can't afford them. We can't keep them. We make the projects so small that we don't need them.

Q. When you do have them, I think that you can have a method in place by which you do learn from them and are able to replicate their skills. Roary, I was pleased to hear you qualify that intangible benefits are of value, but you have to make them tangible in order to sell them. It has been my experience that it's the intangible benefits that are your future. By the time an intangible benefit becomes tangible, you've already missed the boat.

Roary Butler

Ken Tucker

I'm reminded of a person from Northern Telecom who had degrees in law, in engineering, and a few other things. He told me he had a job as the Vice-President of Technology, a few years back. He told me about a lunch he had with Steven Jobs. He was sitting across from a guy who was 27, who was very well dressed in a red shirt, bow tie, green pants and red suspenders. And there was Ed, in his early sixties, in his professional business suit. There was that fellow who just got out of high school, and there was Ed with all his degrees.

Ed asked me, "How come he's a multi-millionaire, and I'm just on a reasonable salary?"

I was able to tell Ed what his problem was: "Ed, your problem is that you know what he was trying to do was impossible. He didn't understand that."

I think, with all the training and all the education, we must not drive out originality. There are some things that you can't teach. I'll give you an entirely different example. When I worked in Montreal, I used to work along the railway line. They had just replaced the tracks, and railroad spikes were hidden among the stones. They made nice paper weights. I found that, if I thought about these, and looked for them as I walked along, I found none. If I told myself that that was what I wanted and put my head down, they jumped up at me. Some things are, in fact, not necessarily consciously driven. If somebody is good at something, and unconsciously good at it, hail that person a bit more for doing it.

Q. I agree. I believe that's the difference between "rigour" and "rigid". Within rigour you can have innovation, but you don't have to keep the same innovation and keep re-inventing the same wheel. That's what happens within our industry.

Mary Baetz

I've just offended every lawyer and engineer, but anyway, I'd like to respond to what you said originally about the outcome justifying the process, that the process doesn't matter and it's only the outcome that matters. I think Peter agrees. This morning he gave us a nice model called "balanced outcomes". In it he had the business outcome, the organizational outcomes, and the continuous learning outcomes, which would involve both the service and the people themselves growing as a result of the project, or the intervention, or the implementation. If that's your definition of outcome, then I would argue that you get that only by going through an appropriate process.

If your definition of outcome is "on time, on budget, up and running the day the legislation says, no matter who you run over", then I would suggest that you're probably going to end up with the "ends justifying the means" mentality, which will give you short-term, limited success that leaves seeds for a long-term, very expensive failure. The issue is winning the battle and losing the war. I would argue that process matters considerably, but defining the outcome appropriately is equally important.

Q. I was listening to the recurrent theme of linking what we're doing in systems development and these types of initiatives with the business strategies of the organization. We've been trying to do that, and we finally got to the point where we said, "The way we're going to assess the benefits in our business case is to see whether they're directly linked to the benefits in the business plan of the organization." That way, we got around some of those tangible/intangible issues. We thought that we found a breakthrough.

The problem we've seen is that the business strategies are changing rapidly. I can see how some of the option value helps, how flexibility and even rapid development might start to address these. I'd be really interested in some of your insights into dealing with rapidly changing business strategies from our perspective.

Ken Tucker

I think that you've got to recognize quickly where the threat is, and understand that you don't have to change your strategy every day. The threat is there. It doesn't matter if it's an ATM, or a VCR, or a television, or a telephone. The rate at which we absorb technology in North America means that to get that money to the 5 per cent level takes about 25 years. And you can use almost any technology you like. I've chosen a number of electronic-based ones. Strategies don't change that quickly. I think you have to get people to understand that they must change this strategy. You can drive yourself into ever-decreasing circles if you try to change your strategies every year.

Roary Butler

He said, "Well, you know, I used to travel with a terminal. All the time, I've got this thing going with me. All my electronic mail I have accessible. One day it dawned on me that Microsoft strategy is not going to change every day. What have I got all this for?"

I think that the strategies don't change; it's usually the products that change. They don't get changed as much as they get modernized. That's where I think structure and architecture are so important. When I was in finance, all I did was to set up an infrastructure. It was so flexible. I could change it as a guy who is dreaming a product. Those aren't strategic changes; they're product changes. I don't think strategy changes that quickly.

Mary Baetz

The other piece is that, out of the fundamentals that are required of any government that are and aren't going to change, the process, the product and the delivery of the service may change, but the fact that you have to do it isn't. Maybe that option value piece will help.

I don't think that we can just say that strategies aren't changing. I think you are in an enormous chaos. The pressure is very high in trying to figure out something, if only to give your people some direction, which they are crying for. I think the important thing, at this time, is to focus on the things that you know you're going to need no matter what. Try to do some brainstorming on the different directions that it might go, and then say, "What if we do certain things? They'll be valued no matter which way we go." Do some focusing on that to get some feeling of productivity, some movement forward until the uncertainty goes away. It may not go away for a couple years. You still have to keep a lot of people moving.

John Riddle

Money has become tight. We've had 13 successive incremental budget cuts since 1986. There's a lot less money. We've also been asked to find 10 per cent, as you all know. Twenty-five per cent comes out of infrastructure. Money is a part of what's affecting strategy, and it's causing people to look at revenue generation—also to look at such things as Ken was referring to: out-sourcing or in-sourcing. Whether in-sourcing or out-sourcing, it is forcing government officials to market-test their products, their results. We're going to have to do that.

Anybody who has listened to talk about re-inventing government knows that's a trend. I don't think it's going to go away. I'm obviously of the view that, yes, the strategy is changing.