Promises, Promises: Negotiating Achievable Commitments

I once observed a discussion between Steve, a senior manager, and Rob, a project manager, about a new project. “How long will this project take?” Steve asked. “Two years,” replied Rob. “No,” said Steve, “that’s too long. I need it in six months.” So what did Rob say? “Okay."

Now, what changed in those few seconds? Nothing! The project didn’t shrink by a factor of four. The development team didn’t get four times larger. The team didn’t become four times as productive. The project manager simply said what he knew Steve wanted to hear. Not surprisingly, the project took more than two years to complete.

Successful projects—and successful relationships—are based on realistic commitments, not on fantasies and empty promises. This article, adapted from the book Practical Project Initiation, presents several ways to improve your ability to make, and keep, achievable commitments.

Making Commitments

A commitment is a promise one person makes to another. The commitment might involve delivering a specific work product or performing a particular service by a specified time and at a certain level of quality. A software project involves many commitments between customers, managers, and team members. The project manager makes both individual commitments and commitments on behalf of the whole team. The project manager also requests commitments from team members and perhaps from external stakeholders. Some projects have at least one formal commitment: a legally binding contract.

Meaningful commitments must meet two conditions:

1. We must make commitments freely.

Powerful people can pressure us to say yes, but most people won’t take seriously an impossible commitment that is thrust upon them. People might pretend to make a commitment they don’t intend to fulfill to end an unpleasant conversation, but lip service isn’t a true commitment.

2. Commitments must be explicitly stated and clearly understood by all parties involved.

Ambiguity about the specifics of the commitment reduces the chance that it will be satisfied. It’s easy to make unrealistic promises on software projects. Developers are optimistic about their talents and may overestimate their productivity. Project managers assume their team members each have 40 or more hours of productive project time available each week, although the reality often is considerably less. Managers and customers pressure the team to provide perfect estimates and to meet their aggressive business expectations with little regard for the uncertainties we face. Requirements are volatile, changing frequently for both good and less-good reasons. We need the freedom to renegotiate unrealistic commitments that turn out to be based on inaccurate information or on premises that have changed.

Negotiating Commitments

Negotiations are in order whenever there’s a gap between the outcomes stakeholders demand and your best prediction of the future as embodied in project estimates. Plan to engage in good-faith negotiations with customers, senior managers, and project team members about achievable commitments. Principled negotiation, a method to strive for mutually acceptable agreements, involves four key precepts (see Getting to Yes by Roger Fisher, William L. Ury, and Bruce Patton):

• Separate the people from the problem.

• Focus on interests, not positions.

• Invent options for mutual gain.

• Insist on using objective criteria.

Separate the people from the problem. Negotiation is difficult when emotions get in the way. It’s also hard to negotiate with individuals who wield more organizational power than you do. Before you dismiss a manager or customer as an unreasonable slave driver who makes impossible demands, recognize her legitimate concerns and objectives, including commitments others might have made that put her in a bind.

Focus on interests, not positions. A marketing manager who establishes a strong position in a negotiation (“This product must ship by November 5th!”) can find it difficult to change that position. If you, as the project manager, define an opposing but equally entrenched position (“We can’t possibly be done before mid-January!”), conflict is inevitable. Rather than reaching an impasse by defending your terrain to the death, seek to understand the interests behind each party’s stated position.

Perhaps marketing’s real interest is to have a demo version available for a trade show. Your interest might be to avoid burning out your team with massive overtime for four months and establishing a track record of failure. Maybe you and the marketing manager can agree on a core set of capabilities that would satisfy both sets of interests and constraints.

Invent options for mutual gain. Negotiation is the way to close the gap between polarized positions. Begin with a win-win objective in mind, and look for creative ways to satisfy each party’s interests. Think of feasible outcomes to which you are willing to commit and present those as options. Consider conditions the other party might be able to change, such as offloading other responsibilities from your team, that could allow you to make a stronger commitment. I firmly believe that thoughtful adults who act in good faith can usually—though not always—find a way to reach agreement.

Insist on using objective criteria. Data from previous projects and estimates based on a rational analysis will help you negotiate with someone who insists his grandmother could finish the project in half the time you’ve proposed. When you’re relying on commitments from an outside party, such as a subcontractor or a vendor, trust data and history over promises. When requesting commitments from other people, remember that an estimate is not the same as a promise. A common reason for commitment failure is making “best case” commitments rather than “expected case” commitments. Some teams define internal target delivery dates that are more optimistic than their publicly committed delivery dates. This helps to compensate for imperfect estimates and unanticipated eventualities. And sometimes you can even beat the external commitment that way, which makes you look very good indeed.

Documenting Commitments

When my brother was an engineering manager, periodically he would discuss expectations with certain individuals on his team. Sometimes he would think a team member had made a commitment, but later discovered that the team member had viewed his request merely as a suggestion. Mismatched memories and interpretations can lead to conflict.

To reduce ambiguity, consider writing a brief summary of each major commitment that you exchange with someone else. This confirms the communication and establishes a shared expectation of accountability. Unless I write them down, it’s easy to lose sight of promises I’ve made to others and of things I’m expecting from other people. I keep two running lists in my daily life: To Do, and Waiting For.

Modifying Commitments

Project commitments can fall by the wayside if the requirements turn out to be technically unfeasible or especially challenging, if customers change them, or if the stated requirements were just the tip of the real requirements iceberg. Project stakeholders must alter their expectations and commitments in the face of evolving information.

Inevitably, project realities—features, staff, budgets, schedules—will change, problems will arise, and risks will materialize. If your customers demand 10 new features late in the development cycle, they can’t expect to get the product by the originally committed date. Whenever it appears that some deliverables won’t be completed on time, the project’s decision-makers need to know how to respond. Possible negotiating angles include:

• Can some lower-priority requirements wait for a later release?

• Can delivery be delayed? By how long?

• Can you channel more developers onto the project?

• Must quality be compromised to meet other, higher-priority constraints?

If it becomes apparent that you team won’t meet a commitment, tell those affected promptly. Don’t pretend you’re on schedule until it’s too late to make adjustments. Letting someone know early on that you can’t fulfill a commitment builds credibility and respect for your integrity, even if the stakeholders aren’t thrilled that you can’t deliver on the original promise.

Your Commitment Ethic

I once managed a good developer who always said “yes” when I asked her to take on a new responsibility. However, she often didn’t deliver on schedule. Her in-basket was overflowing. There was simply no way she could complete everything she’d agreed to do, despite her best intentions and hard work.

A meaningful commitment ethic includes the ability to say “no.” Here are some other ways to say “no” that might go over better.

• “Sure, I can do that by Friday. What would you like me to not do instead?” (As the manager, you’re responsible for making these priority decisions.)

• “We can’t get that feature into this iteration and still finish on schedule. Can it wait until the next iteration, or would you rather defer something else?” (This is a way to say “not now” instead of simply “no.”)

• “That sounds like something I can do, but it’s not as high on the priority list as my other obligations. Let me suggest someone else who might be able to help you more quickly than I can.”

I practice this personal philosophy: “Never make a commitment that you know you can’t keep.”

My personal preference is to under-commit and over-deliver. A track record of making realistic performance estimates and fulfilling your commitments earns credibility. That credibility improves your future ability to negotiate problematic schedules or other commitment requests.

Once I was discussing process improvement plans with my department’s aggressive senior manager, three levels above me. Fred was pressuring me to agree to a timetable that my group had concluded was not remotely feasible. When I resisted, he grudgingly moved his objective out several months, but even that goal was pure fantasy. Finally I took a deep breath and said, “Fred, I’m not going to commit to that date.” Fred literally did not know what to say. I don’t think anyone had ever before refused to make a commitment he demanded. (My boss, who was also in the meeting, was going nuts.)

I explained our analysis and reasoning to Fred. I told him, “We’re not going to work any less hard if we have more time to do it, and our morale will be higher if we’re not set up for certain failure.” Fred didn’t shout at me, hit me, or fire me, although in some situations those might be possible risks. Reluctantly, he agreed to a more plausible target date that our team believed we could achieve.

As a project manager, don’t force your team members commit to outcomes they don’t believe to be achievable. If you fear someone is getting in over his head, discuss the commitment details, assumptions, the risks of failing to meet the commitment, and other obligations that could get in the way. Create an environment in which your team members can turn to you for help with negotiation, priority adjustments, and resource reallocations.

Unfulfilled promises ultimately lead to unhappy people and unsuccessful projects. Strive to build a realistic commitment ethic in your team—and in yourself.

Karl Wiegers is Principal Consultant at Process Impact, a software development consulting and training company in Portland, Oregon. He has a PhD in organic chemistry. Karl is the author of numerous books on software development, most recently Software Requirements, 3rd Edition (with Joy Beatty). He’s also the author of Successful Business Analysis Consulting: Strategies and Tips for Going It Alone, a memoir of life lessons, and a forensic mystery novel, The Reconstruction. You can reach him at ProcessImpact.com or KarlWiegers.com.