The Skeptic’s Guide to Project Management, Part II: Winning Agreement
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Welcome back to the skeptic’s guide to project management, where I look at what actually happens on successful projects.
Last time I introduced the guide and suggested that project management is a game of negotiation. I also covered eight types of influence, explaining how a project manager can use leverage to get things done.
Influence will help, but you'll still need to negotiate. In this article, I will talk about Good, Bad, and Ugly ways to negotiate, with an eye toward how a project manager might use these in the complex and sometimes confusing "real world." First, let's talk about what a negotiation is.
On Negotiation
Here is a brief rundown of negotiation tactics: The Good, The Bad, and The Ugly.
The Good
I call negotiation approaches good if they respect both parties. This is different than bartering, which presents the world as a fixed pie with both sides directly competing for a bargain. Good tactics look for ways grow the pie. They keep both parties in mind, weighing the value of a long-term relationship over a "quick win." Stephen Covey, author of The Seven Habits of Highly Effective People, is famous for his term "Win-Win or No Deal", where you strive for an agreement that is mutually beneficial.
Good tactics should also be ethical tactics. You should be able to do them and sleep at night; you should be able to hold them up to your children as examples of who to be when they grow up. Here are some good negotiation tactics:
Reframe as shared risk. Say a speaker is arguing over his fee for a dinner meeting. He wants one thousand dollars; the association wants to pay him two hundred and provide a nice meal. Note that if five people show up for the dinner, the organization will take a loss, and if fifty do, they'll collect a nice profit. Instead of fighting over the pie, the speaker might suggest a payment in terms of percentage of net profits. This helps the organization limit its risk, creates an incentive for the speaker to help with PR, and moves the conversation from pie-fighting to growing the pie. In project terms, that might mean offering an incentive based on profitability of the project -- not on a deadline. If you can't find financial incentives, you might be able to offer something else -- give the worker choices, autonomy, and the opportunity for mastery, something Daniel Pink suggests in his book Drive: The Surprising Truth about What Motivates Us.
Problem solving. Instead of trying to win, consider the issue a problem to be solved. You might start by exploring things that have little cost to you but great value to the other person. You might get a war-room for the project, isolate the team member from other projects, or let them work from home four days a week. Likewise you might work to understand what the most valuable features are for the customer, what the cheapest features are for the staff to build, and see if you can put an interesting package together before the deadline. (Just how important is that deadline anyway? What happens if we are a single day late? A week? A month?)
Systematic small concessions. Perhaps the best of the "bartering" approaches, with systematic small concessions, you start with your ideal contract and negotiate down to your real bottom-line number in small pieces. People are generally comfortable with this approach, but it tends to cut off breakthrough discussions, and, worse, sends the message that nickel-and-dime style behavior will be rewarded. Be careful.
Systematic equivalent concessions. In a way, pure bartering is a bit of a game. You have some personal value on your product or service, but you are trying to maneuver to get the most or least for the product. Over time, you likely compromise a bit and meet in the middle. With equivalent concessions, you might lower the price, but you'll get something else in return --- payment up front, or delivery of a smaller feature set for the software. This technique can be especially helpful as a PM. After all, the technical staff should be making professional estimates; they won't have any slack left to add more in negotiations. So sure, you can hit an earlier deadline, by cutting features, or perhaps quality. (One way to do this is to put all the features on story cards on a board. When people want to add stories, you point out the board is full; what is going to go down so the new requirement can come up?)
Take it or leave it. This is pretty much how it sounds. You may want to use this approach when you just aren't interested in the deal or if you don't want to invest time in a long negotiation. You might, for example, name an absurdly low price when dealing with a vendor you don't like. If he rejects the price, you haven't wasted much time, and if he takes it, well, at least the work will be cheaply. Even then, you'll also want to make sure the work is clear-cut, well-defined, and you have some confidence the other person can actually deliver on time. When someone takes a lowball project, odds are, you'll pay for the lowball with your time and effort ... if they ever deliver anything.
The principle of least regret is a strategy to set your price. If you try take it or leave it, you still have to come up with a price somehow. There are plenty of models for this that you might use. The idea here is that bidding brings regret -- either regret that you lost the project from bidding too high, or, if you get the contract, regret that you didn't ask for more. The principle of least regret tells you that the right price is the price where, should you experience either emotion, the regret roughly balances.
The Bad
Not all negotiation tactics lead to mutual understanding and mutually beneficial outcomes. Some of them are designed to give you the best advantage, without regard for the other person. They might poison the relationship, they might be a bit underhanded, they might be short-sighted, but they'll help you win ... at least this time.
Notice: I am not recommending these. At all. Don't do them; you will cripple your future effectiveness. That said, it is important to notice when these tactics are used on you -- and have a few counters available.
Hidden Decision Maker. You see this at the used car lot, where you make your best deal, and then the salesman says "I have to go check with the boss in the back room." Not having the right people in the room cripples your ability to negotiate, and it means you have to negotiate twice. Counter this by asking, early in the process, who the key decision makers are. If you are the project manager and stuck between a team of "stakeholders," get that down to the smallest set. If that smallest set can't agree, point out the blocking issue. Either that group has to speak as one voice, or it will be extreme challenging for you to be successful.
Last minute demands. The papers are ready to be signed and the development team has finally agreed to hit the project milestones. All of a sudden, out of nowhere, an executive has a new requirement, and the success of the project depends on it. Fail on this one new thing, and the whole project is failure -- at least it sure seems that way. You aren't alone in this; I've felt that way too, and delivered on the new requirement, only to be rewarded with ... more new requirements! That's right, rewarding this behavior will get you more of it. Every now and again, it is possible that this emergent opportunity can save the company, so I don't want to make too hasty a generalization, but, most of the time, you'll want a phrase for this. My personal favorite is "Sure. That sounds like a good fit for phase II" and "I appreciate the idea. If we can do it for free, we'll sneak it in. Beyond that, [summary of oversight process and how decisions are made]."
Slippery Slope. This is a tactic similar to last minute demands, but it starts with the customer asking for "just one more thing" -- the kind of thing that can be done on a lunch hour. You know that the technical folks are team players, so either you volunteer to add the work or perhaps a member of the staff does. Over time these small demands grow and grow until they threaten the success of the project. The counter to this tactic is to reframe these “little requests” as the extra work they are. You will also want to track these “little requests,” pointing out any extra hours of work you've done to fulfill these and their true cost. Remember: There are no free lunches on projects. If people want more work, sure, they can have it and they'll also have to pay for it.
Misrepresenting the value of a concession. Imagine an executive has ten demands, but only really cares about five. The other five he will trade away (using systemic small concessions, listed above), then say something like "Can you meet me halfway on this?" appealing to your sense of fair play. This tactic can be hard to recognize. My best advice is to stop talking about the problem as a negotiation, and go back to problem solving and understanding the need. "Even with missing that feature, I still see this gap in the schedule. The programmer' estimate is their best professional one; I can't just ask them to work harder. Could you help me understand the business need, to see what we can shave from to hit this date?"
I forgot. "Did we say two weeks? No, I couldn't have said that. It will take three." The classic advice here is to cover your tail with paperwork and an email trail, and that's fine, as far as it goes. Personally, I prefer more lightweight methods, like a project wiki, which is a sort of editable, version-tracked web page, combined with an understanding about accountability. If possible, keep the deliverables small -- a day, two, maybe three days at a time, and get the whole team to make commitments in public. Sometimes, people do forget, but if it happens a lot, my advice is to let the project team have a go on the issue before weighing in. Let them ask "what's up with that?"; let them try to solve the issue. Facilitate, don't rescue.
The flexible offer. Consider the word "done." Does "done" mean the code is written? Tested? Integrated? Backwards compatible? Deployed? With the flexible offer, the other person makes a promise that is just vague enough to pass muster. You, the poor Project Manager, get to figure this out what that actually means the day the piece is done, or if you are lucky, at a weekly status meeting. "Oh Done?" Bob will say "Yes, it's done. But not deployed. No, getting it to done-done will take another week ..."
I have actually used the phrase done-done-done in meetings, and had someone reply that four done's would take another week. No, really. Other approaches to the flexible offer include re-defining time ("oh, yes, four weeks, but I had a week of vacation in the middle. So a little more than a month calendar time") or perhaps re-defining the scope of the work itself. To prevent this, be specific on the commitments team members make, and, if possible, slice tasks very thinly and get quick feedback daily.
The exploding offer. The other person can meet your requirements -- or come close -- but something is about to come up; some other project is competing for their attention. They can do the deal right now if you sign, otherwise, it disappears forever. Honestly, I've chased the "right now" offer a few times, and it has never worked out for me. If someone is using pressure tactics to get you to make a decision, strongly consider walking away. If you are pressured to make a decision on your feet -- say a company Vice President offers to give you $200K of budget to bring on six contracts for three months to accelerate the project -- you can always say something like "I'll have to get back to you on that."
In my experience, if you take the exploding offer, something else will go wrong.
That's the thing about these manipulations: If you give in to them, you teach the other person that you can be manipulated. You think you've made the other person happy and avoided the conflict, but in reality, you taught the person that this kind of behavior works on you. Expect to see more of it.
The Ugly
These techniques can be done with good or bad intent. Sometimes they just happen. One thing's for certain: You'd prefer that they not happen to you.
Absent Proxy. A contractor using absent proxy might say "My wife won't let me take less than fifty dollars and hour." This sets the floor for negotiation, just as he could if he set up the fifty-an-hour policy. Without absent proxy, the contractor might fall for appeals to emotion, to teamwork, to work-with-me-on-this. Thus, the wife is a sort of emotional crutch; the contractor can shift the blame to someone else and not feel internal conflict. Two ways to deal with this are either to engage in problem solving, offering other tradeoffs to compensate, or to respect that the person has set up a boundary, and come to “no deal” quickly if you can’t meet those requirements. If the boundary is not real -- if it just a negotiation tactic -- then introducing “no deal” will bring the other person back to the table.
Bring me a rock. The other person asks for a rock; you bring them a rock. "Oh no," he says. "I wanted a red rock." You bring him a red rock, he complains it isn't shiny. You bring the shiny red rock, and it is too small, or too light, or ... you get the point. Sometimes, with bring me a rock, the customer doesn't really know what they need, and is learning through the process. Other times the customer is just intellectually lazy, and doesn't define requirements well. In either case the solution is to create cheap mock-ups of the rock the customer can respond to, and to re-define the process as an iterative one. Bring me a rock is very similar to Moving the Goal Posts, a problem where the success criteria keeps changing. Realize that if your goal posts keep moving, you can never score; it will be critical to your success to figure out why, then either nail them down or get out.
Wrong level of authority. Your friend the programmer says he can do it in a week, so you put it down on the schedule. The next day, his manager drops by your office and explains that sure, it will take a week, but that programmer will be busy on another project for at least the next month. This can also happen in hiring, when a manager approves a hire but ... ooops ... the requisition is frozen by HR. Gosh. I hope you didn't turn in your resignation letter yet.
Back in Project-Land
Once you start thinking in terms of negotiation, you start seeing it everywhere. From who will pick up the kids after the scout meeting, to who is driving to the regional meeting for your service club, who gets to drive the golf cart on the range and how much to pay the baby-sitter. Be careful here; I am not saying to suddenly become selfish, manipulative, and to see the world as a series of contests to win or lose.
The point is that you will start to see negotiation and options where you previously did not, and, I expect, that will include your software projects.
Projects are inherently complex things. In many cases, the success or failure is determined up front, where someone “sets” the feature list, timeline, and the resources to be assigned. As a project manager, you'll have to play with the project you are dealt. Yet once you realize the difference between the plan and reality, you can start to set and negotiate expectations.
In the previous article (link), we talked about methods to obtain power and influence on projects. Today, we covered how to put those powers to use. You'll need to negotiate on every side: Between peer executives on what they will get, with managers on what people and resources they can commit, with individuals on what they can promise to deliver and when.
In some cases, you'll only have the appearance of a negotiation. What do I mean by that? In order to have a real negotiation, you need five things:
- you
- the other party
- something you want
- something the other party wants
- an alternative to a negotiated agreement
If the secret of project management is negotiation, then the second secret is that many times, although what you are doing has the appearance of negotiation, it is missing one of these components. Consider your annual review and salary negotiation. Without an alternative to a negotiated agreement (like a job offer in your back pocket), it isn't really a negotiation at all; it’s a request. Likewise, when it comes to working with full-time employees, in many cases the project manager has nothing to offer as the “alternative to a negotiated agreement”. When you only have the appearance of negotiation, you'll want to pull out those power and influence cards. In other cases, you'll have a real negotiation, and want to be dealing with it in an ethical manner.
As a project manager, you'll be dealt a set of cards and want to play them in the best way possible. In some cases, you may even be able to negotiate what cards you get.
Finally, there is the other guy, who might not negotiating in bad faith. Watch out for those, and prepared with a counter.
This is far from a complete guide; there are, after all, entire books on negotiation. Today I've stressed the importance of negotiation for project management, trying to "hit the highlights" and provide some actionable tips. Humans are imperfect, we make mistakes, and we have conflicts and desires. If you are a project manager, you'll want negotiation in your skill set.