Communication/negotiation techniques that work!
Several prominent studies have pinpointed poor communication as a major contributor to project failure. Project team members are tasked to communicate in multiple directions, both detailed and summary information, and to internal and external stakeholders in a timely and efficient manner. Yet, they often fail in the simplest forms of communication – person-to-person!
This session will introduce several tools to assist the project team member in understanding and delivering concise and clear messages. Through the use of these tools, one can drill down to the core message and unearth the details hidden in our assumptions and perceptions in order to clearly express our ideas and understand one another. Samples of the tools and their use will be illustrated through case studies and examples.
It has been my experience that most people involved in projects often know the correct things to say and do, but often lack the vehicle or process in which to do it successfully. Many have progressed through the ranks because of their technical ability and have not been trained in general management topics.
This paper attempts to give the project team member some tools and techniques that I have used successfully in over 20 years of managing projects. They have proven to work for me in actual practice, the true test of a tools use. We will look not only at the tools and technique, but also the practical application within the context of a project and see how they can help. Your actual mileage may vary, but put the tools to work and judge the results for yourself!
The definitions of “communication” and “negotiation” follow:
1 : an act or instance of transmitting
2 a : information communicated b : a verbal or written message
3 a : a process by which information is exchanged between individuals through a common system of
symbols, signs, or behavior <the function of pheromones in insect communication>; also : exchange of
information b : personal rapport <a lack of communication between old and young persons>
ne go ti a tion noun
1 : the process of discussing something with someone in order to reach an agreement with them, or the discussions themselves
Having defined these terms, let me say first off that my assignment of a tool to a specific category (communication, negotiation) is totally my choice, and is subject to disagreement. My choices are arbitrary and not to be construed as industry best practices or definitive classifications. Feel free to re-categorize them as you wish; the important thing is to practice and use the tools to increase your personal and professional effectiveness. It is the process and techniques upon which we should focus. The categories are not significant.
Often, when suggesting a new concept or technique, one is asked “Can you guarantee results?” By now, you have probably excised the word “guarantee” from your vocabulary, but, if not, let me offer a suitable expression as a substitute. Instead of using the word “guarantee”, substitute the phrase, “increase the likelihood of”. That's as true a statement as you give these days. Too often, as project team members, we feel that the deck is stacked against us. We could use some tools to help us reverse this trend and put the odds in our favor. These tools will “increase the likelihood of” successful communication and negotiation with project stakeholders.
Project Management really is stakeholder management. Would you agree that managing stakeholder expectations from concept through implementation increases the likelihood of customer acceptance at project's end? If you agree, then approach day's work as a “Manager of Expectations”, and see what influence that idea has upon your performance. These tools will help you in that regard.
Finally, as in all examples of project management tools and techniques, focus on the process, and not the content, of any example used to illustrate a particular tool or technique. The object is not to see who can be clever, or get the most points poking holes in the example, but whether we can learn to use a process that will increase the likelihood of good communication within a project.
Start with Questions
When all else fails in a conversation, always ask a question. We have been trained from early on to respond when questions are asked of us, so it is quite natural to have another person answer your question when asked. It may have also occurred to you that the person asking the questions is often in control of the direction of the conversation. Any student of the detective movie/police story genre can attest to that. So the first techniques we'll deal with revolve around the asking of questions, and how to use the idea of asking questions to get past personal smokescreens and get to real issue.
You may have noticed that during your projects, individuals will often “misrepresent” themselves when faced with a risky or difficult issue (duration estimates, percent complete, etc.). There may be no malicious intent here; it may be that the person is giving what they know of the truth, or are trying to be overly optimistic. Regardless, you need to get to the bottom of the issue and find out the real information if you plan on making a valid project plan. With that in mind, let's focus on the Questioning techniques.
More Than One Question
Ask a single question, and you're more than likely going to get a cursory, or expedient, answer. It has been my experience that individuals need to be presented with a series of questions if I want to drill down to the core of the issue or problem at hand. As David Sandler states, “The first two responses to your questions will result in what I call Intellectual Smoke Screens (ISS)…. When you hear ISS, continue asking questions!”
Test this out the next time you feel that someone is no giving the full picture. Ask increasingly more probing questions, and see if you can get to the route cause. Mentally conceive an Ishikawa (fishbone) diagram, and ask questions to narrow the spines to the real issue. Use this idea in combination with other techniques to get to the real problem.
Any student of Sun-Tzu will tell you that if you can turn a potential weakness into a strength, that is a good tactic. This idea translates well when a team member asks you a difficult or confrontational question and you feel the need to respond even though you don't have all the information necessary to give a good one. Many times, the question masks some deeper issue within the questioner and the question asked is just a prelude to something else. In either case, you're at a disadvantage, because you're not prepared to answer the question that was asked.
Why not take control of the conversation back by switching gears and asking a question in response to the question? This way you shift the focus back to the person asking the original question, and you can find out a little more information before rendering judgment. The process is pretty straightforward and sounds something like this:
|Team Member:||Hey Sam! I want to know how come I get to do all the dirty jobs on this project?|
|Sam:||Joe, that's interesting that you feel that I give you all the dirty work. You must know that I value your contributions to the project and would never deliberately pass on grunt work. What makes you feel that way?|
First off, notice that the response begins with a calming statement, one that validates and repeats the message to show that it was heard and understood. Next, came a statement designed to make the questioner feel appreciated and valued – in other words, a stroke for the ego. Never underestimate the power of recognition on a project; it may be the cheapest and most powerful tool for team development. Finally, we switched gears by turning the question back on the petitioner to probe for more details. Try this process, and see if it helps when pushed in a direction that you're not prepared to go!
Let's Pretend is a tool that was taught to me by management consultant Al Turrisi of Turrisi & Associates. Let's Pretend takes the conversation way into the future, to the point of some issue or confrontation, and tries to develop a solution today, in case the issue or confrontation were to appear. Most projects have their usual points of contention or issues that show up in mid-projects. Many of them make the Top n Risk or Issues list. Let's Pretend forces the situation to the future, at the point in time where the risk or issue is realized, and asks the team to develop a response today. In practice, it sounds like this:
|Project Manager:||Joe! I need to talk to you about the late status reports. This is the third week in a row that your reports had to be tracked down. Is this going to be a problem every week?|
|Team Member:||No, Sam, it won't. I got a little behind the curve, but I'm OK now and all future reports will be on time.|
|Project Manager:||I can understand your time constraints, and appreciate that you're giving it your best effort. I hope you can appreciate the value your report gives me when it comes to managing our client's expectations. So, you're report next week will be in by Friday, noon next week.|
|Team Member:||I'll try my best!|
|Project Manager:||I'm sure you will. But, Joe, Let's Pretend that it's noon next Friday, and your report is not in yet. What would you expect me to do in that case?|
|Team Member:||I guess that I'd expect to be called on it again.|
|Project Manager:||Yes, but that doesn't work, as evidenced by the newest late report. Any other ideas as to what I should do?|
|Team Member:||Well, Sam, you could always fire me!|
|Project Manager:||Well, that always is an option! But I'd rather not lose you over something like this. Let's explore some other options and see if we can develop a process that insures an on-time report.|
Is it Important?
This tool is particularly effective in the situation where a customer asks for a particular feature of function to be added to the scope of your project – in other words, a scope creep scenario. When put in this situation, simply ask the questioner if the specific feature/function is important. In a few cases, the answer will actually be “No!”, and you will have saved yourself a whole bunch of requirements gathering just by asking a simple question. Of course, if the answer is yes, you have prioritized the request in your customer's eyes (it's important!), and you go through the normal change control processes.
The communication techniques that follow are designed to be use together with the questioning techniques and negotiating techniques to give you a toolkit that you can adapt to several situations.
Up Front Contracts (UFC)
An up front contract is nothing more than an agreement made beforehand about how you'll deal with a future situation. Used with the Let's Pretend tool, it becomes an effective way to plan for future problems today. Use Let's Pretend to take the other party to the point of contention, work out the solution together, and form an up-front contract to behave that way once the problem or issue arises.
This tool is used to remind people that all causes have effects and each action has consequences. I use it whenever someone asks for a new, previously unidentified requirement, and wants to add it to the project (for free). I simply tell them, “If you would like this new feature/function, then it will have this schedule and cost impact.” If you don't know offhand the schedule and cost impacts, make an up-front contract that when you meet with the team to discuss this change, you'll get back to them with those impacts.
No doubt your industry or functional area is fraught with technical terms or industry jargon that seems designed to confuse and frustrate the outsider. Many times, people will appear to agree with you just because they do not want to appear ignorant of the technical term, or understand it in a way different from your application of the terms. Either way, you're both using the same words to describe a different vision, and when it comes to describing the product of your project, that spells disaster. The advice here is to refrain from using industry jargon and try to explain things as simply and universally as possible to avoid these misinterpretations.
Know Your Chainsaw!
Project Management texts will often use the analogy of a juggler to illustrate how a project manager juggles the 3 sides (Cost, Time, Scope/Quality) of the triple constraint. I don't juggle, but I've been told that the juggler needs only to focus on the ball in flight to keep going. I once saw a juggler who juggled an apple, a bowling ball, and an operating chainsaw! I have to think that this juggler focused on one object more than the other two!
Taking the analogy back to the triple constraint, isn't one of them more like the chainsaw than the other two for your current project? Are both you and your customer and your project team in agreement as whether budget, schedule, or quality is the “chainsaw” for your project? Wouldn't this analogy help them in determining this and help you balance the trade-offs?
Many project team members when presented with opportunities that require them to negotiate with another party. In many cases, it is because they have not been formally trained in negotiation techniques, or their job does not require negotiation on a regular basis. Regardless, knowledge of some simple techniques should be in everyone's toolkit, as we're negotiating in the workplace every day.
An up front contract can be a very effective technique in negotiating for resources, project trade-off decisions, or getting agreement on a common understanding of scope. Use with the other tools to craft the solution up front.
Elegant Currency is something that is of greater value to the person with whom you're negotiating than it is to you. In many scenarios, you possess something which the other party wants and there is no significant cost or time required on your part to produce it. Use this to trade for something of value, or a special consideration that you desire. In a project scenario, always deal in Elegant Currency before you deal in real currency!
“Quid pro quo” has always been a tactic used in negotiating. In this application, always make sure that and the other party know that “chips” are being traded, and that there ultimately will be a reconciliation of any chips acquired or owed. In a project scenario, we often trade chips when requesting or providing resources, or when trading off project objectives with a customer.
The “Best Alternative To a Negotiated Agreement (BATNA)” was a concept introduced by Roger Fisher and William Ury (1981). The idea suggests that you spend time developing a solution that does not require negotiation, so that you have a fall back position should the price of negotiating be too high. By knowing this walk-away alternative, you'll be better able to judge the offer presented, since you'll have a built-in option with which to compare. The better the BATNA, the stronger your negotiating position.
When working with project teams, you are presented with many situations that require the use of a variety of techniques to help you communicate. These techniques can be applied to these situations and give you some tools to help explain your ideas and understand those of your team members.
Fisher, R. & Ury, W. (1981) Getting to yes New York, NY: Penguin Books
Sandler, D. (1995) You can't teach a kid to ride a bike in a seminar New York, NY: Dutton.
© 2004, Ernest Baker, PMP
Originally published as a part of 2004 PMI Global Congress Proceedings – Anaheim, California