Management Skills

Management Skills

We started with the statement that project management is management and the observation that management consists of general talents combined with specific skills. So far, we have dealt with the specific skills needed by project managers. Now we turn our attention to the management skills needed by anyone whose job includes managing people.

This section will deal with these skills:

1. Outcome framing

2. Listening

3. Gathering information

4. Running effective meetings

5. Bearing bad news

6. Managing your time

Outcome Framing

Someone says to you, "If I had more money, I'd be a happy man." So you say, "Here's a nickel. I'm glad to add to the totality of human happiness."

As you ponder what went wrong, welcome to the world of outcome framing. There is no end of advice on the importance of setting outcomes, usually punctuated by statements such as, "If you don't know where you're going, you'll get there." However, few people understand what a valid outcome is or that framing an outcome is different from simply stating it.

An outcome, or a goal, an objective, or a targetit does not matter what you call itis a statement of the desired result of some set of activities. Framing the outcome rewords it so that it meets five criteria: It is Stated in the positive, it is Measurable, it is Achievable, it Respects your values, and it is Time-dependent. The criteria form the mnemonic SMART.

1. Stated in the positive. Stating an outcome in the positive is not some West Coast, feel-good cult thing. You state an outcome in the positive in order to focus on what you want to achieve rather than on what you want to avoid. When you state an outcome negatively, you risk ending up with something you don't want.

On a project, one of your outcomes may concern client satisfaction. The outcome ''I want my client to be satisfied" is different from "I don't want my client to be dissatisfied." Attempting to achieve client satisfaction leads to an attitude of responsiveness; attempting to avoid dissatisfaction leads to one of reactiveness. The difference determines whether you will exert yourself to identify and satisfy needs or to practice damage control.

2. Measurable (specific). This is where your friend who wanted more money went wrong: He did not specify how much more money it would take to make him happy.

Making an outcome measurable and specific is the only way to know when you have succeeded. For example, if one of your project outcomes is to satisfy your client, you must decide how you will know whether or not you made it. What is the measure of a satisfied client? Is it a positive response to your question, "How did we do?" Is it a score on a predetermined test of customer satisfaction? Or does it happen when the customer gives you new business? However you define satisfaction, it must be specified in your outcome statement. Otherwise you will never be able to claim success, nor will you know whether or not you have achieved it.

You cannot make a negative outcome specifichow do you measure a lack of dissatisfaction? This is another reason for stating your outcome in the positive.

3. Achievable. Can you reasonably expect to achieve the outcome? If not, why are you wasting effort? Unfortunately, the question of achievability often withers in the face of management cheerleading.

Our culture prizes those who fight against impossible odds and honors them when they succeed. These "winners" are often contrasted with the "quitters" who whine, "It can't be done." If you

state that a project target is not achievable, you risk your management's regarding the problem as your "bad attitude" instead of their own unrealistic demands.

It is true that miracles have happened, that impossible targets have been met. It is also true that the ability of committed teams to achieve amazing breakthroughs has never been limited. If you are prepared to commit yourself and your team totally to an "impossible" goal, good luck. If you make it, you'll be a hero. However, wisdom consists, in part, of picking your causes and selecting the ones that are truly vital to you and your organization. Those who indiscriminately accept any challenge are fools, not heroes. In your normal life, you have the right, and the obligation, to say, "This cannot be done."

How, then, do you avoid being labeled as negative? First, recognize that "Can you do this?" is a loaded questionan appeal to your pride. Second, when you are faced with a loaded question, borrow a technique from politics: Rephrase it. Ask, "You mean, is this project loaded for success?" You have just moved from heroism to craftsmanship, from the epic realm of the impossible dream to the professionalism of what is reasonable. Rephrasing the question shifts the focus from you to the project, from your ability to its risks. You have just demanded that the project be reshaped so that it is achievable within normal constraintsso that it is loaded for success.

4. Respects values. If this outcome is achieved, will it actually produce results that conform to your values? To take an extreme example, if you achieve your outcome of having more money by robbing a bank, how will you reconcile that act with your image of yourself as an honest person?

Organizations, as well as individuals, have values to which they conform. A company that prides itself on not laying off employees will find numerous ways to avoid implementing a system that leads to staff cuts. A company is which departments are traditionally secretive and protective of their data will resist a system that makes data available to others, even with endless assurances of data security and integrity.

Too frequently, the results of an otherwise successful project languish on a shelf because the clash between the system and its organizational context has doomed the project from the start. If your project is to be successful in meeting its justification, you will have to ensure that the organization will embrace the outcome.

5. Time-dependent. To be properly framed, an outcome must have a time limit. To say, "I want to be rich ... some day" is to give yourself permission to avoid doing what you need to do until it is too late.

For projects, time dependency is usually obvious. However, activities within projects too often ignore time dependency. If the people on the teamor you-do not have specific dates by which assigned activities are to be finished, the activities will not slipthere is no completion date to miss. But the project will be late.

When to Frame an Outcome

Outcomes are not reserved for large, all-consuming projects; they apply to all activities. If someone were to ask you, "Why are you doing this?" your answer is a statement of your outcome regardless of what "this" is. To the extent that your outcomes are properly framed, you will have a better chance of achieving them.

Your projects should, of course, have outcomes, but you should also be able to state the outcomes for activities within the project. How many meetings have you sat through wondering why you were there? How many reports have you struggled through waiting for the author to reveal the point? How often have you pasted an expression of fascination on your face and turned it toward a rambling, incoherent speaker whose sole virtue is to provide you time to daydream about your upcoming vacation? More important, how often have you led those meetings, written those reports, and delivered those speeches?

On the other hand, you may recall the pleasure of leaving a meeting or reading a report or applauding a speaker with a surge of elation at having spent your time well. It was not an accident. The speaker or author, consciously or otherwise, framed an outcome, got you to accept it, and delivered. To the extent that you frame your outcomes properly, you and your people will consistently become more effective.

Sample Framed Outcomes

Each outcome is unique. There is no "standard" that you can select from a kit bag. However, the following examples should help give you a flavor of how to frame outcomes for various situations. As an exercise, review each of these outcomes to ensure that they meet the SMART criteria.

1. The presentation. You have been asked to give a presentation about your project to a group of key users in the client organization as a preparation for the pilot test, implementation, and rollout of the system. You could grab some overheads from other presentations you have given on project status, drop some of the more uncomfortable material, and deliver a bland summation of facts about the project. But as you think about the audience, you may conclude that this is an excellent opportunity to create some enthusiasm. Hence, you might frame your outcome as:

To make a presentation to key users about system implementation and rollout that will generate a positive attitude toward the project, as evidenced by questions after the presentation and informal feedback.

You may object that the outcome is neither measurable nor time-dependent in that there are no statistics. Nevertheless, both criteria are present. The outcome's time dependence is dictated by the scheduled date of the presentation. That it is measurable is more difficult to observe.

The reason that an outcome must be measurable is so that you will know whether or not you have achieved it. In this example, the type of questions you get and the feedback you receive after the presentation will tell you whether or not you have succeeded in "generat[ing] a positive attitude."

If you take this outcome to heart, then before you insert any material into the presentation, you will be prompted to ask yourself whether or not it will lead to your outcome. As a result, you will delete technological complexities or uninteresting (although vital) issues. You will also plan to present your material with a style that generates enthusiasm.

A different outcome will lead to a different presentation. For example, you could have framed your outcome as:

To make a presentation to key users about implementation and rollout so that they can plan their resources appropriately.

This presentation is more likely to be a recitation of facts and dates with little involvement or commitment by the users. However, if the project history is such that building enthusiasm would be difficult and your goal is to let the users know what will be expected of them, this outcome is more appropriate than the first.

2. The discussion paper. Your project has encountered a major issue that needs a decision by the steering committee, and you have been asked to "put some thoughts down on paper" outlining the issue and its alternatives. You decide to prepare a discussion paper.

One risk with discussion papers is that they are too broad, that they bring in issues that bear indirectly if at all on the central issue. A second risk is that in an attempt to be neutral, you will be too equivocal, and the steering committee will not be able to reach a decision or will be misled into reaching the wrong one. A clearly framed outcome might be:

To present the steering committee with information on [the issue], enabling them to reach a decision by November 30.

If you have a specific decision that you want the steering committee to reach, your outcome could be:

To present the steering committee with information on [the issue], to decide [the specific decision], by November 30.

The contents of the discussion paper will be substantially different based on which of these outcomes you select.

There is a potential problem with the second outcome. If one of your values is your professionalism, which you interpret to mean that your job is only to provide information and not to manipulate clients, you may run afoul of the requirement that your outcome respect your values. In that case, go with the first outcome. However, you may want to review your values; steering committees are justified in expecting their project managers to have opinions on most of the major issues in their projects. Yours may be looking for leadership.

The intended result of this framed outcome is to lead you to focus on the essentials of the decision in your report and to exclude any material that is not relevant. Furthermore, the second outcome will also cause you to be more directive. There will be no doubt which decision you recommend, and your reasons for supporting that alternative will be clearer than if you simply "put some thoughts down on paper."

3. The problem-solving meeting. An issue has arisen in your project, and you have called a meeting of interested project participants to discuss the issue and reach a conclusion. Warning: Whenever you call a meeting, you are at risk. Meetings (see "Running Effective Meetings") are constant sources of irritation and present a rich opportunity for participants to run amok with all the issues that have so far bedeviled the project. There is no other activity that so clearly benefits from a well-framed outcome.

Assuming that the sole purpose of the meeting is to resolve the issue, your outcome could be:

To facilitate a discussion among team members about [the issue], leading to a consensus by November 30.

Note that this outcome demands facilitation, a discussion, and consensus. This meeting will be totally different from one in which the outcome is:

To gather information from team members about [the issue], allowing me to reach a decision by November 30.

The second outcome demands only that you receive information. Discussion is valuable only if it adds to the information, and consensus is irrelevant; the decision is yours alone. In fact, you could achieve this outcome by conducting interviews rather than by holding a meeting.

The effect of both of these outcomes is to focus the meeting explicitly on the issue and to exclude side issues. How well the meeting fares will depend on your skill in running it, but any failures will be problems of execution, not of planning