For the most part, customers are reasonable and understand the uncertainties in any IT project. If they feel abandoned or left out of the process, they will react with anger or dissatisfaction to any departure from their conceptions of the ideal project. Treat them as participants, to be consulted and informed, and they will understand and accept even substantial deviations from their original expectations. By recruiting them into the process, you are trying to get them to regard the project, with all its lumps, as partly theirs. Few people criticize their own work.

Return to top

The Fear of Public Speaking

Several years ago, I jumped out of an airplane. Yes, the plane was flying and, yes, I had a parachute. Am I some extreme dude who thrives on mortal risks and believes that life is only worth living when it’s about to end? No. In fact, I’m somewhat risk-averse; waterslides bother me and I get nauseated even on merry-go-rounds. How, then, was I able to leap from an airplane at five thousand feet above the ground and overcome my fear of creating a small crater in some farmer’s field? There were three factors that made it possible, the same three factors that enabled me to face the first of my many audiences.

The fear of public speaking is, according to some claims, the greatest fear of all, bigger even than the fear of death (although this should not be surprising: give a poor speech and you’re still around to suffer the consequences). Can this fear be overcome? Well, of course it can, otherwise, given that most people start out fearful of the stage, the podiums of our meeting rooms, auditoriums, and classrooms would be empty. How to overcome that fear is the point of this article.

First, however, a brief digression is in order. There is a difference between a fear and a phobia. A fear is reasonable, a phobia is not. For example, consider the fear of snakes. If you cannot distinguish those that are harmless from those that want to turn you into dinner, it’s reasonable to fear them all. But if you discover that this one particular wriggler is a harmless garter snake and, instead of stopping to admire its colors as it slithers past you, you run screaming from it, your reaction is a phobia. Fears and phobias need to be handled differently: A fear will succumb to the techniques I discuss below, a phobia will resist them. So, before you embark on any program to relieve your fear of addressing an audience, you first need to determine which of the two is the cause of your twitching hands and sweating palms. Here are three simple tests to determine if your reaction to going on stage is a fear or a phobia.

1.      Can you speak confidently to two or three people in a social or business setting? If so, your reaction is probably a fear.

2.      In a formal meeting of your peers, are you able to make your point or defend a position adequately and articulately? If so, your reaction is a fear.

3.      However, if your mouth goes dry and the spigots embedded in your armpits turn to gushers when you are asked to present information such as your status, your reaction is most likely a phobia, especially if you have the same response regardless of who has asked the question.

Most people cannot overcome phobias by themselves. Seek professional help (phobias can be cured), then come back and read the rest of this article.

Returning to parachuting, the three factors that enabled me to overcome my fear of flattening a goodly portion of some farmer’s crop were:

1.      The rewards were compelling.

2.      Success was achievable.

3.      The preparation was exacting, demanding focus.

These same factors apply to overcoming any fear or yielding to it. If you believe that the activity that induces the fear is not worth doing or that success is elusive or that there is no way to prepare adequately, you’d be a fool to carry on.

So let’s look at each of these.

Are the Rewards Compelling?

As a project manager, one of your principal responsibilities is to communicate with the stakeholders of the project. This involves leading meetings, making presentations, facilitating decision-making, acting as a cheerleader for your project and your team, and, sometimes, bearing bad news to people in authority. Doing these well does not mean that you are a good project manager—there’s more to managing projects than speaking—but doing them poorly does mean that your ability to inspire project teams, to convince clients and management that you are in control, or to advance in your career to larger, more complex, and more fascinating assignments will suffer.

Your first step, therefore, is to believe in—to be thoroughly convinced of—the rewards that await your ability to deliver successful presentations. Imagine your most intractable client saying, “That was an excellent review of the status. Thanks,” or even, “You’ve made the problems on this project clear, but I think you’re the best person to handle them.” Or how about, “Our clients were really happy with your last project, so we’d like you to tackle this [much bigger, riskier, more complex, more profitable] project.” Would these reactions inspire you? Would they be worth the effort to learn to deliver good presentations? You may be thinking, “Well, I’d love to hear those comments, but it’s not likely.” Don’t worry. If you’d love to revel in the light of a great presentation, you’ve satisfied the first condition: The rewards are compelling.

Is Success Possible?

Is success possible? Since others have succeeded, this is a dumb question. What you really mean is “Is success possible for me?”

The problem here hinges on your definition of success. If you regard success as achieving the acclaim (or, at best, the lack of condemnation) of your audience, you do indeed have a justifiable concern because few audiences will respond favorably to a speaker who is more concerned with his or her status than with the real reason that they’re there. With rare exceptions, audiences do not gather to hear orators orate. Hearing the rolling mellifluous tones of an accomplished speaker’s voice is a bonus, but it is not why they’ve come. Audiences gather because they want information or they want to understand issues that they will be asked to help resolve or they want to provide information to some process. While it doesn’t hurt to speak well, the members of an audience will be satisfied if their primary purpose in giving up some chunk of their time is met. Therefore, success is the extent to which you have shaped and met the audience’s expectations.

Given this, success should be simple. Can you stand up before an audience and say, for example, “In this session, I’d like to familiarize you with this issue, to let you know how we’ve addressed it, and to tell you the effects it will have on your work.”? Then, can you deliver? If so, you can succeed. Will the members of the audience be happy? Will they be inspired? Will they love you? Who cares? Making them happy or inspiring them or inducing rapt expressions of awe was not your goal, nor, as a project manager, is it your role.

Therefore, before any presentation, you must define for yourself the goal of your presentation. Why are you doing it? What do you want to achieve? Furthermore, that goal must be from the point of view of the audience. If your goal is, “To enhance my status,” why would anyone care to come? (Of course, if you do well, your status will grow, but that’s a by-product of the success of the presentation, not its primary purpose.)

Of course, your goal must conform to the requirements of your audience. If you are addressing senior management on the project status, they won’t care about such esoterica as IP address conflicts. They want to know about money, dates, and risks.

Then, once you have defined your goal, you need to tell it to the audience. Often, the goal is implicit: The purpose of a status review meeting is to review status. But it never hurts to make the goal explicit, like the airline announcement, “This plane is going to Los Angeles. If you don’t want to go to Los Angeles, now is a good time to get off.”

Is the Preparation Exacting?

When I leapt from the plane, the instructions were precise. The plane was a single-engine Cessna with no door on the right side. When it was my turn to jump, I was given a command by the jump master. Facing the front of the plane, I crouched beside the door, which was on my right. At the next command, I swung my left foot over my right leg onto a small step outside the door. At the next command, I swung my body out of the plane and grasped the strut of the wing. My right leg was floating free. At the final command, I let go. The static line attached to the plane would pull my ripcord.

Why not just leap out of the plane? Because I was a novice and my trainers had to ensure that when the parachute opened, I was lying prone facing the ground so that the parachute would rise up from my back. If I were not in that position, the chute would be pulled around me and there was a good chance I’d be caught in the lines. That would not be a good thing.

There are two points to be made. The first is that the preparations, being so precise, forced me to focus on the tasks that had to be done instead of on the consequences of not doing them. The second point is that the very existence of these steps reassured me that what I was about to do had been done by others many times before. Had I been told, “just jump out of the plane,” I doubt I would have had the comfort that the people who were training me knew what they were doing or had my best interests in mind.

Public speaking imposes the same demands: The preparations should be exacting. Here are some rules to force your focus.

1.      Stick to the topic

You’ve defined your purpose, now adhere to it. Squash the temptation to add other information or to touch on topics that are only peripherally related. If someone raises a point that is off topic, have the following response ready, “That’s a good point but I’d rather not get into it here. Let’s get together later to discuss it.” Then move on.

2.      Practice

Find yourself a private room and deliver your presentation exactly as if you had an audience. Speak out loud. Listen to the sound of your voice. Practice until your talk becomes conversational, with normal variations in tone and volume.

3.      Know the room

If possible, visit the room ahead of time. Many a prepared speaker has crumbled at the sight of a chaotic or awkward setup. While you might not be able to change anything, at least you can be prepared. Where will you stand? Is there a podium? Will you need a mike? If so, is it attached to a podium, is it on a stand, or will it attach to your lapel? Does it have a cable that could trip you up? Where will you place your notes? Your computer? How are the audience’s sight lines? If you are part of a program of speakers and you need time to set up, tell the audience so, ask them to take a short break, then ignore them while you get ready.

4.      Have some water available

Your mouth will get dry, not only because you’re nervous, but because you’re talking. Have a bottle of water to hand and sip from it regularly. Not only does it refresh you, it introduces a pause to allow you to collect your thoughts for the next subject.

5.      Minimize distractions

What are your nervous habits? Do you twist your ring or fiddle with a pendant or twirl a necklace chain? If so, take them off before you go on stage. Put your watch on the podium or on a table where you can glance at it. If you must use a laser pointer, force yourself to lay it down after each use.

6.      Avoid humor

Unless you are an accomplished stand-up comic, don’t attempt to be funny because when your poorly told joke fails to elicit laughter, you’ll be thrown off. Don’t start a talk with, “Did you hear the one about the farmer’s daughter” unless your topic is something like “The Sociology of Family Dynamics in an Agricultural Milieu.” Humor has its place and, once you become more comfortable, you can throw in some off-beat lines, but never tell a joke that has nothing to do with your topic.

7.      Ignore your audience

This is strange advice that contradicts most of what you will hear. However, unless your audience consists of people you know well, you will never know what motivates, inspires, bores, angers, or enlightens the individuals who are listening to you and you can go nuts trying. All you can do is establish your goal and deliver on it, regardless of who is in your audience, with two caveats:

a.       As discussed above, your goal must respect the interests of your audience.

b.      During your talk, you cannot ignore a hand raised to ask a question.

8.      Friends vs. strangers

Some speakers will advise you to talk to friends instead of strangers. This is futile advice: You rarely have control over who will be in the audience. But how about practicing in front of a group of friends? I don’t recommend it. Your friends have an image of who you are, which may not be the persona you will present on stage and the dissonance can result in unhelpful comments such as, “Just be yourself.” (I don’t know any experienced speaker, myself included, who has the same personality on stage as off.) Furthermore, if your friends truly are friends, they’d rather bolster your ego than give you any useful critical feedback. Speaking personally, I vastly prefer talking to a roomful of people I don’t know. After all, in the words of the folk singer Connie Kaldor in her provocative song, “Get Lucky,” “Ain’t the nicest thing about strangers / is that they don’t know you that well.”

The point to all of this is to force you to focus on all aspects of the process, including you, the room, the topic, and the contents of your talk. Will you have them standing in the aisles cheering? Probably not, but neither will they be booing and throwing things. That alone should embolden you to accept your next presentation. Will you ever overcome your fear? No. No good presenter goes on stage without butterflies and a case of nerves, but once you know you can do it, your fear becomes your friend, motivating you to improve and, ultimately, to achieve the excellence that will have them cheering. Good speaking.

© 2008, allPM.com (www.allPM.com) republished with the permission of the International Institute for Learning, Inc. (IIL)

Return to top

Building High-Performance Project Teams

Every project manager I have ever met has spoken about “our team.” I consider this to be a communal delusion because I have rarely seen a team; what I mostly see is a bunch of people working on roughly the same thing. There is a difference between a bunch and a team—some authorities have suggested that a team can outperform a bunch by a factor of two or three. Think what this means. Even if the “team factor” is only two, this means that the same work can be done by half the number of people. Would this interest your company? Would being able to produce consistently high work with fewer people mark you as a valuable member of the organization? If so, learning how to turn a bunch into a team should become one of your priorities.

In fact, assuming that you are a project manager, I suggest that learning how to build high-performance teams is more difficult and more critical for you than it is for any other managerial role. I have two reasons for this claim.

The first reason is masked by a project management myth: that project success depends upon selecting the right team members—those who will meld together. Not only is selecting the right team a notion that pervades project management literature, it is one that caused an engineering company, which shall remain anonymous, to hire an expensive consultant to administer a personality profile to all of its technical and managerial staff with the goal of ensuring that project teams would be assembled from those whose personalities “meshed.” The problem with all of this, apart from the hugely complex and largely futile psychological exercise of predicting how people will interact, is simply that few project managers ever have the luxury of selecting a project team. Companies do not have idle pools of talent waiting to be picked like players in a sandlot ball game. The problem that I and other project managers face is not in choosing compatible team members, but in getting people who are even remotely qualified for the work. Project managers do not select teams, they must build them from the people they are allotted.

The second reason that team-building is especially difficult for us as project managers is that while department managers have the luxury of time to allow a team to evolve, the transitory nature of projects requires that we build teams fast.

This, then, is our burden: to build high-performance teams from a near-random collection of people and to do it quickly. No other management role carries these constraints, which forces me to conclude that building good teams is far harder for project managers than for anyone else, and every bit as vital.

But what is a team? How does it differ from a bunch? The most concise definition I have found is, “A team is group of people committed to a common goal.” There are two aspects to that definition: a common goal and commitment. In this article, I will deal with the latter. (This is not to devalue setting a common goal. Conflicting views of where the project is going has derailed many a sincere attempt to build a team. After all, if you hitch one horse to the front of the wagon and the other to the rear, both horses can work mightily, but you won’t go far and you’ll probably wreck the wagon. As the project manager, it is your responsibility to ensure that everyone on the team agrees on the goal, even if they prefer another one.)

Which leaves commitment.

Commitment means that the goal of the project is more than just another work assignment, it becomes a psychological imperative. It means that success is personal. Failure hurts. At a gut level, the project matters. Committed people do not need to be exhorted to “give 110%” or “do whatever it takes” or “come to play” or any other sports cliché you choose. Committed people will “do what it takes” to make the project succeed. Uncommitted people will do what it takes to collect a paycheck.

However, one of the more frightening aspects of commitment is that when people commit, they do not commit to a project or to a company, they commit to a leader. That’s you. And when they commit to you, they commit to follow you wherever you (reasonably) need to lead them. (Those who follow a leader wherever he unreasonably leads them belong not to a team, but to a cult.)

So how do you instill commitment? How do you motivate people? The bad news is that you can’t. People, annoyingly, are self-motivated. All you can do is establish the environment in which motivation will grow. As more than one commentator has noted, motivation is not industrial, it is agricultural; you can’t manufacture it, you must nourish it and allow it to evolve.

How?

It is astonishing to me that managers need to be taught how to behave in order to get their people’s commitment. After all, we have all been in situations where we have been uplifted and ennobled, and we have all been in situations where we have been belittled and scorned. Which of these is more likely to produce commitment? (This question is rhetorical. If you have to think about it, please take up a career that doesn’t involve managing people.)

A Couple of Examples

I had pulled an all-nighter. The project had to produce a set of reports by noon the next day and it would take all night. At the end of the day, I went home, changed into my casual clothes, ate, and returned to the office. I worked all night, through the next morning and finally finished at about eleven o'clock, at which point I turned the reports over to production and went home to collapse into bed. The next day, my manager summoned me into his office, but instead of the well-deserved praise and thanks I expected, he said, "We have a dress code here. We don't mind you working all night, but if you are going to work during office hours, we expect you to go home and change. Don't let it happen again."

I had pulled an all-nighter. The project had to produce a set of reports by eight the next morning and it would take all night. At the end of the day, I went home, changed into my casual clothes, ate, and returned to the office. At about eleven p.m., my manager (a different manager) appeared and asked how it was going. When I muttered a non-committal, "fine," he said, "I have some work to do. if you need a hand, I'll be in my office. I dismissed the offer as managerial posturing and went back to the project. I finished the reports about three a.m. and cranked up the machines that would prepare them for delivery when my manager suddenly appeared and said, "This is something I can help with." We finished binding the reports, he took me out for a bite to eat, drove me home, and said, "Don't come in today."

These are true stories and they illustrate some of the principles that can either inhibit or foster commitment. However, before I get to them, there is one other topic that I need to discuss.

Foster Prima-Donnas

We have all heard sentiments such as “There is no ‘I’ in ‘team.’” “We don’t want prima-donnas here.” “The team is bigger than you.” “Check your ego at the door.” Good grief. It seems as if anyone who wants to build a team must be first concerned with squelching any expressions of individuality; the team is all. The problem is that of all the high-performance teams I have had the privilege of knowing, they have succeeded not in suppressing egos, but in harnessing them, and not in the service of some amorphous concept such as “team,” but in the practical, real problem of achieving a concrete result. (A quick definition: A prima-donna is one whose attitude of superiority is deserved. Someone whose attitude is underserved is a poseur or, to be more Anglo-Saxon, a jerk. Get rid of him.)

The prima-donnas on your team will raise the hackles of two groups: the client and your other team members. If the client demands that the team member—any team member, prima-donna or not—be removed, you must refuse, otherwise you are giving notice to the team of whom they must satisfy. And it’s not you. Your bigger problem will be how to pull together all your team members, including the prima-donnas, into a cohesive unit. Here are some principles.

Principles for Building a High-Performance Team

1. Lead by example. Are you committed to the project? If not, it’s harder for your people to commit to you. Is your work exemplary and of high quality? If not, you can’t complain when your people mirror your sloppy habits.

2. Develop leaders. You have an issue that needs to be solved. You can solicit “input,” which, you hope, will mitigate your ignorance of the subject enough to allow a defensible decision, or you can delegate it. Find the person who is the most knowledgeable about the issue, then assign that person to resolve it with the condition that you will accept whatever resolution he produces. Will it be the best solution? Perhaps not, but leadership emerges from the cauldron of dubious decisions.

3. Set specific expectations. People can only commit to what is clear. If you are vague about the scope or details of a work assignment, don’t be surprised when your team member’s interpretation of your fuzziness does not conform to yours.

4. Walk the halls. The action is not at your desk, it’s out there where people are solving problems, working, and interacting. Join them or prepare yourself to cry, “What happened?” when the project founders.

5. Involve your team. If you have a problem, such as schedule slippage, you can either hunch down at your desk and produce a revised plan that you will impose on your team, or you can call them together and solicit suggestions about how to handle it. Not only does this approach create a commitment from those who developed it, it honors and respects their abilities as people rather than as resources. (In fact, unless you are talking about something like oil sands or lumber, expunge the word “resource” from your vocabulary.)

6. Emphasize teamwork. Thank and reward team members for helping others who are struggling. Even better, thank and reward team members who are courageous enough to ask for help.

7. Serve your team. Who should do the peripheral activities: photocopying, faxing, doing pickups or deliveries, scraping the sludge from the coffee pot? You can demand that one of your minions handle it or you can recognize that every hour that that minion spends on side issues is two hours lost in project work and you can swallow your pride and do it yourself.

8. Defend your team. Never allow anyone—customers, managers, suppliers, or team members—to attack anyone on your team. Be absolutely ruthless in condemning all destructive or unsolicited criticism as unwelcome and offensive. In particular, be vigilant against humor. It often disguises a vicious barb.

9. Praise in public. In any meeting, make it a point to embarrass with effusive praise at least one team member.

10. Discipline in private. If you need to discipline, it’s between you and the team member. It’s nobody else’s business. (With respect to discipline, you may find it hard, but without it, you are not a leader, you are a social worker.)

11. You are not their friend. You are their leader. This does not mean that you must remain aloof or that you must refrain from the banter that is part of any good workplace, but it does mean that you cannot establish personal relations with any team members that would inhibit your ability to discipline or replace them.

12. Facilitate communication. Communicating is a pain. You have to formalize it. That means making it harder to avoid than to carry out. For example, set up a workflow system such that whenever anyone changes a document, an automatic notification is sent to everyone who is affected.

Call team meetings at least once a week. Make them brief, informative, mandatory, and fun.

13. Thank people. Believe it or not, this is free. Of course, you could thank them materially with an occasional team lunch or doughnuts at the meetings or an evening outing at a skating rink or ball diamond.

Another Look at Motivation

Years ago, psychologists began to study what people in the workplace want. At the time, this seemed like a pointless research project, akin to the one that found that rats sometimes can’t tell the difference between recordings of Japanese and Dutch played backward. (This is a real study. It won the 2007 Ig Nobel award in linguistics.) After all, everyone knew what people wanted: money. But to the surprise of the initial researchers, money was well down the list. The big three motivators for workers in all industries and of all ranks were the same: recognition for their contributions, a degree of control over their work, and appreciation. Do you notice something interesting about these? They’re free. They take some effort on your part, but they have zero effect on the project budget. Provide them and the people in your company will fight to be part of any project that you manage. What’s holding you back?

© 2008, allPM.com (www.allPM.com) republished with the permission of the International Institute for Learning, Inc. (IIL)

Return to top

The Fourth Dimension: Justifying Information Technology Projects

If you ask a room full of project managers what constitutes a successful project, the overwhelming answer will be, “on time, on budget, in scope.” Meet these three measures and your project is successful, miss even one and it’s not. For most project management practice areas, these criteria define success. However, for information technology (IT) projects, there is another standard that is almost universally overlooked: the realization of benefits.

Organizations engage in IT projects because they expect to receive a benefit. If the benefit is not achieved, the money spent in financing the project is wasted. Yet at the conclusion of many IT projects, organizations cannot tell whether or not they realized their benefits and in most of the rest, are painfully aware that they did not.

However, the failure to achieve benefits does not deter IT project staff from proclaiming a project a success irrespective of whether or not the sponsoring organization got what it paid for. “On time, on budget, in scope” is all that counts. Furthermore, this attitude of indifference to benefits is fostered by the project management literature. In a recent survey that I conducted of fourteen IT project management books, thirteen had no index entries for “benefit,” “cost benefit analysis,” or “justification.” The reference in the fourteenth was trivial, simply averring that projects should be justified. I contend that this reflects a massive delusion shared by IT project managers and shaped by an unswerving drive toward the traditional triad of budget, schedule, and scope. This delusion is understandable; “IT project” and “overrun” have come to be synonymous. There is enormous pressure to get projects on track. Nevertheless, any effort that does not focus on delivering benefits and value to the sponsoring organization is doing only half a job.

In this article, I will define the characteristics of a usable statement of benefits. In a subsequent article, I will describe the process of managing an IT project to ensure that benefits are met.

The problem with IT project justification is not that the process is ignored, but that it is not well understood. While most projects pay lip service to justification, It is common to find “benefits” that cannot be achieved side by side with a standard list of “intangible benefits” such as, “The system will be user-friendly.” In my experience, most statements of project justification ignore four fundamental requirements:

·         Benefits must be financial.

·         Benefits should be stated as goals, not predictions.

·         Benefits are different from effects.

·         Benefits cannot be intangible.

Benefits must be financial

The only valid benefit to an IT project is its impact on the organization’s finances: The project will either increase revenues or reduce costs. Nothing else counts. Any “benefit” that is not financial cannot be compared to the project costs, cannot participate in a cost/benefit analysis, and cannot, therefore, be used to justify the project. Furthermore, most non-financial “benefits” are not measurable, meaning that there is no way to tell whether or not the project actually delivered the expected results.

This point of view is not widely held; there are several non-financial sources of benefit that are routinely offered. One of the more popular ones is necessity. For example, the government may introduce new legislation requiring a change to a company’s systems, or a major customer may switch to electronic data interchange and insist that its suppliers do likewise. In such cases, there is no choice; the company complies or shuts down. But this is the ultimate financial benefit: You get to keep your business. That such a benefit is easy to identify does not diminish the need to do so. The company may find, for example, that it is more cost-effective to shut down the part of its operations that is affected by the new demand and focus its energies elsewhere, but without a cost benefit analysis, such an option will be swamped by the knee-jerk response to comply.

Another popular non-financial “benefit” is improved customer service. But why would any organization want go to the expense and effort of improving customer service? The obvious answer is to increase (or at worst, to protect) sales revenues. But where a benefit is identified by such an obtuse term as “customer service,” not only can it not be used in a cost benefit analysis, nobody will ever know if it has been achieved. Improving customer service may be a powerful motivator for a project, but it needs to be restated as, for example, “Sales to existing customers will increase by five percent and sales to new customers will increase by two percent.” Given the current annual sales, the benefit from the project is easily calculated.

However, this type of justification only applies to commercial organizations. How does a government department quantify the effect of improved customer service? It cannot use increased revenues; a Department of Motor Vehicles cannot expect to attract more customers for its drivers’ licenses by shortening its queues or pasting smiles on the faces of its staff. Unless the improvement to customer service leads to increased operational efficiencies, the “benefit” of improved customer service is financially empty. Does this mean that governments cannot justify improving service to their constituents? Not unless there will be reduced costs or the project is required to deliver a mandated service. Government departments that initiate IT projects because their staff’s (usually legitimate) concerns over service delivery ignore fiscal responsibility are unfortunate contributors to the massive deficits that characterize many public sector agencies.

The third widely used non-financial benefit is the corporate infrastructure project. For example, a company decides that it must link its staff by a set of corporate databases and a company-wide groupware system. Such projects are usually “justified” by arguing that the company needs to “enter the twentieth century,” “adopt state-of-the-art tools,” and “realize the full benefits of modern information technology.” Failure to do so will condemn the company to be marginalized in some technological purgatory.

There is no doubt that providing better tools improves work efficiency or quality, and sometimes both. The point is not that such projects are intrinsically worthless, but that, like any other major expenditure, they need to be properly justified. The real benefits of justified infrastructure projects are increases to efficiency and quality, which lead, respectively, to lower costs and higher sales. The fact that it is hard to put precise dollar figures on these benefits does not obviate the need to do so. Otherwise, the organization, in assessing whether or not to proceed, will not know if the benefits outweigh the costs.

Benefits Are Goals, Not Predictions

One of the disincentives to stating benefits is that they are normally treated as predictions. “If we can implement this inventory control system, our stock levels will be reduced by 15%.” The trouble is that predictions are passive; if the fates are kind, good things will happen. There is little we can do to influence the outcome.

However, if benefits are regarded as goals, the attitude toward them is reversed. Most businesses set goals and understand the steps of working to achieve them. Hence, a goal statement for a project might be, “When we implement this inventory system, we intend to reduce our stock levels by 15% in the first year of operation.” The difference between this statement and the prediction in the preceding paragraph may seem semantic, but the attitudes behind them are poles apart. A goal is actionable, requiring an approach, a plan, checkpoints, and a commitment to execution.

IT project benefits that are expressed as goals are properly part of the project’s implementation plan. That plan typically addresses such issues as training, pilot and parallel testing, rollout, and phasing out of existing systems. For projects that are properly justified, it should also list all the benefits identified at the start of the project and present a plan to realize them. In this way, the IT project manager is not simply a courier, handing over a new or enhanced system, he or she is providing a procedure to help the organization realize the benefits it expected when it started the project. The project manager is an active contributor of value to the company.

Benefits are not effects

One of the most popular sources of apparent benefit is savings in employment costs through layoffs, enabled by the conversion to a new technology. For example, if this $500,000 system will reduce workloads by the equivalent of ten clerical staff, each of whom costs us $50,000 per year in salary and benefits, we will save $500,000 in the first year alone. A payback period of just one year is compelling. But is it realistic?

In order to actually save $500,000, we will have to dismiss ten people. There are several reasons that this may not be possible:

·         The appropriate people are protected by union contracts. Getting rid of them will be extremely expensive. If buyouts will cost an average of one year’s salary per employee, the total costs increase to a million dollars and the payback period doubles.

·         The company was founded on a policy of employment protection. If an employee’s job is eliminated, the company has committed to find that person another job within the company. Hence the payroll cannot actually be reduced.

·         The employees in the affected department are specialists and, while the workload of each will be reduced, the company cannot afford to lose the skills of any of them.

·         The savings in workload do add up to a total of ten people, but they are distributed over a hundred people in such a way that no one (or two or ten) people end up with no work to perform.

In this example, the savings in workload are effects. Reducing someone’s workload by an hour a day is an effect, but it has no financial impact on the organization. In order to be a benefit, there must be a real, dollar, saving. Too many project justifications are based on effects, not benefits.

The acid test that distinguishes an effect from a benefit is the question, “How will this result save (or earn) money?” This question makes it clear that reducing workloads, to continue with the illustration, does not in itself save money; some other actions need to be taken. For example, the reduced workload may mean more time for people to complete assignments, resulting in increased quality and ultimately in higher sales. Or the reduced workload may make it possible to free up resources to improve internal processes or assist sales or solve longstanding irritations, all of which may be quantifiable in dollar terms. And of course, it may be possible to reduce staff and realize cost reductions. (In over thirty years of IT experience, I have never seen a project actually result in layoffs. That’s not to say it never happens, only that it is not common and certainly not easy.) The point is that an effect does not directly result in financial benefits, but it may enable them through other means.

Benefits cannot be intangible

One common theme in IT project justification is an inevitable list of “intangible benefits,” replete with catch phrases such as “state-of-the-art,” “flexible,” and, of course, “user-friendly.” The only problem is that there is no such thing as an intangible benefit. A benefit is real, tangible. Anything else is a collection of buzzwords designed to sell what is probably a marginally justified project. Projects that deliver real benefits do not need a list of intangibles.

One of the real ironies behind the focus on intangible benefits is that many of them do produce tangible results. For example, consider “user-friendly.” I will define this as a system characteristic in which the correct response to a screen state is more intuitively obvious to an average, untrained user than any possible incorrect one. (Contrary to some opinions, user-friendliness is not simply a matter of wrapping a windows-like interface around a poorly constructed design.)

Does user-friendliness, by my definition, lead to benefits? Of course. To identify just three, it reduces the need for users to consult documentation, thereby increasing productivity; it reduces training time and with it lost production while staff are in classes; and it reduces the rate of errors and the need for subsequent re-work. But how much will productivity be increased? How much will re-work diminish? These benefits are hard to quantify and, in some cases, even to measure, so writers of business cases take the easy way out and label them as “intangible” when what they really mean is, “We couldn’t be bothered trying to quantify this.”

However, quantifying such benefits is not difficult if, as recommended above, they are treated as goals and not as predictions. Now it becomes reasonable to say, “Because of the intuitive nature of the system, we intend to reduce the training budget by five hundred dollars per person per year and to increase transaction throughput by ten percent. In addition, we intend to reduce re-work costs by twenty percent.” Of course, the numbers in this example are for illustration only and presumably would be supported by some level of analysis in a real case, but the point is simply that it is easier to set targets than to predict results. Will you meet the targets? Of course not. You never do. Sometimes you fall short and sometimes you exceed them. But having a quantified target rather than a nebulous wish is the first step to providing real benefits to the organization.