Software Project Negotiation: Success Tips for Delivery Teams and Sponsors
Back at Berbee, when we were working overtime at a loss because we’d over-committed on a fixed-fee contract, the client told us, “You’re not bad estimators, you’re just bad negotiators.” More than 10 years later, I’m as convinced as ever that the foundation of success, or failure, is laid very early, and that it’s the result of a negotiation. I’ve spent eight weeks writing about this because I don’t think it’s getting the attention it deserves. There’s too much waste and stress in software development, and that hurts everybody.
- I see Sponsors driving Commitments that they think are in their best interests, but aren’t.
- I see Delivery Teams not negotiating well, or not even realizing they’re negotiating, accepting low-probability Commitments, and then getting blamed for the outcome.
This post summarizes the best advice I have today for both Sponsors and Delivery teams. It’s based on
- My own model of the process as Target > Estimate > Commitment
- Principled Negotiation, as described in Getting to Yes (1981), and
- 10 years of focused software project set-up experience—5 as a Delivery Team business analyst, estimator, and proposal writer, and another 5 as a consultant, primarily to Sponsors, as they evaluate, select, allocate resources to, and oversee projects.
Vocabulary: Target, Estimate, Commitment
A clear vocabulary can help you.
- A Target is a project concept of scope, schedule, and budget, usually posed by the Sponsor.
- An Estimate is the probability of a given scope, schedule, and budget being achievable for a given team and technology.
- A Commitment is an agreement by a Sponsor and a Delivery Team to achieve agreed-upon results (a Position), or follow an agreed-upon process that converges to a result that satisfies all Interests (a bigger target).
You can make things better just by treating these steps separately. You can learn more in:
- Software Sanity: Accurate Estimates and Other Myths
- A Target’s just a Good Idea
- Numbers without Probabilities aren’t Estimates
- Covey’s “Win/Win or No Deal” approach to Commitments
If you want to read books about estimation, I highly recommend:
- Software Estimation: Demystifying the Black Art, by Steve McConnell
- Agile Estimating and Planning, by Mike Cohn (useful even if you’re not yet an agile shop)
Or I’d be happy to help you improve your decision support—your estimates—and how they’re used.
Guidelines: Principled Negotiation
Not being a trained, experienced negotiator myself, I’ve drawn on Principled Negotiation (Getting to Yes, 1981).
- Separate People from Issues
- Focus on Interests, not Positions
- Invent Options for Mutual Gain
- Insist on Using Objective Criteria
Success Tips: Delivery Teams
You have to make it happen. Given enough time and the right tools, you can. But that means negotiating for the time and tools you need, starting from the first whiff of a new project. It’s too important to wait for someone else to do it. By then, expectations may have hardened.
Here are some things I try to keep in mind:
- “Separate people from issues.” Your Sponsor knows things you don’t, and they’re probably not stupid or evil. Their life isn’t all beer and skittles either. Use your problem-solving skills to understand their problems and help them solve them. Ask “Why?” (“Help me understand” is gentler and will work better).
- “Focus on Interests, not Positions.” If you want a life—no more death marches—ask. If you want to work with some cool new technology—ask. Your chances of getting one or two things you want most are probably better than you think.
- “Invent options for mutual gain.” Do your homework. Come prepared with reasons behind your estimates, and the amount of uncertainty in them, and how a change in scope or other inputs would change them.
- “Insist on using objective criteria.” Strongly consider adding metrics-based estimation to your tool kit.
- Refuse a commitment that estimation shows is a low probability. If you’ve done your estimation homework and have established a reputation for not being a slacker, you probably won’t lose your job. More likely, you will improve your reputation in the organization, as well as saving you and your buddies a lot of misery, and your organization a blown project.
- Do good work and expect your teammates to do the same. If you want to be treated like a professional, be one! Credibility really helps in a negotiation, and knowing your stuff, and being able to communicate it, builds credibility.
Success Tips: Sponsors
You are the man or woman who has to decide which software projects to do and at what level to staff or fund them, and then you’re accountable for the outcome being worth more than it cost. I believe your role is the more difficult one. Here’s my usual advice:
- “Separate people from issues.” Most programmers love to write software. (If they don’t, that’s a serious concern for you and their management, but you won’t cure it by cracking the whip). Programming is like an addiction. I know. The real issue is that there’s a lot of uncertainty in how long software stuff takes. There just is. (“Accurate Estimates and Other Myths” explains why).
- “Focus on interests, not positions.” What do you really need out of the project? Explain the “why” behind your targets, especially deadlines. Engage your Delivery team in coming up with different ways to get there. The larger the target that amounts to Success, the easier it is to hit.
- “Invent options for mutual gain.” You’re more likely to be the trained negotiator, plus you probably outrank them. Draw the information out. Ask them how they arrived at their estimates, not to beat them down, but to understand the cost and value space.
- Remember that a low-probability commitment, even a seemingly willing one (remember, they’re mostly not comfortable with negotiation), does not guarantee a successful outcome. It might make you look good now, and let you shift the blame later, but wouldn’t you come out even better if there was no blame to shift?
I welcome your feedback, be it good, bad, or ugly. I’m putting these ideas out there because they’ve worked for me, and I think I understand why, and I think they’ll work for you, too. If you agree, please try them, and forward them to others.
And if you need my help applying them, that’s what I do. Thanks for reading!
Next week, we’ll get on the “Requirements Merry-Go-Round” and find out how to spot big gaps nearly every time.