Issue: Vol. 13, No. 3, May 1996 | PDF

How to Defend an Unpopular Schedule

Estimating software-product size and of software-project time and resource needs is undoubtedly hard. But once you have made an estimate, you still have to convince your customer or boss to accept it. If the estimated schedule is too long, customers and bosses will pressure you to shorten it–not because of flaws in your analysis but simply because they want it to be shorter. All too often, they succeed, and, as a result, many of us find ourselves working on projects that have been planned from the outset to achieve an unattainable combination of cost, schedule, and functionality. Such projects are programmed to fail. The inevitable late-project consequence is a loud chorus of “Why can’t these software guys figure out how to deliver software on time?”

Defenseless Developers

Current estimation practices are a problem, but I am convinced that current scheduling practices are the more serious problem. Philip Metzger observed 15 years ago that developers were fairly good at estimating but were poor at defending their estimates (Managing a Programming Project, 2d Ed., 1981). I haven’t seen any evidence that developers have gotten any better at defending their estimates in recent years. Several underlying factors come to mind.

Developers tend to be introverts. About three-quarters of developers are introverts compared to about one-third of the general population. Most developers get along with other people fine, but the realm of challenging social interactions is just not their strong suit.

Software schedules are typically set in negotiations between development and management or development and marketing. Gerald Weinberg points out that marketers are often ten years older and negotiate for a living–in other words, they tend to be seasoned, professional negotiators (Quality Software Management, Vol. 3, Congruent Action, Dorset House, 1994). The deck is stacked against developers during schedule negotiations.

Developers tend to be temperamentally opposed to the use of negotiating tricks. Such tricks offend their sense of technical accuracy and fair play. Developers don’t want to offer lopsidedly high initial estimates even when they know that customers, marketers, or bosses will start with lopsidedly low bargaining positions.

Because developers need to become better negotiators, I’ll spend the rest of this column describing how to negotiate schedules effectively.

Principled Negotiation

Start improving your negotiating skills with the principled negotiation strategy described in Getting to Yes (Fisher and Ury, Penguin Books, 1981). This method has several appealing characteristics. It doesn’t rely on negotiating tricks, but it explains how to respond to tricks when others use them. It’s based on the idea of creating win-win alternatives. You don’t try to beat the person you’re negotiating with; you try to cooperate so that both of you can win. It’s an open strategy. You don’t have to fear that the person you’re negotiating with has read the same negotiating book and knows the same tricks. The method works best when all the parties involved know about it and use it.

The principled-negotiation strategy consists of four parts, which the following sections relate to software schedule negotiations.

Separate the people from the problem. All negotiations involve people first, interests and positions second. When the negotiators’ personalities are at odds–as, for example, developers’ and marketers’ personalities often are–negotiations can get hung up on personality differences.

Begin by understanding the other side’s position. I’ve seen situations in which non-technical managers had good business reasons for wanting specific deadlines. In one case, a manager felt pressure from the marketing department to produce a software product in 6 months. I told him that the best I could do was 15 months. He said, “I’m not giving you a choice. Our customers are expecting the software in 6 months.” I said, “I’m sorry. I wish I could develop the software in 6 months, but 15 months is the best I can do.” He just froze and stared at me for two or three minutes.

Why did he freeze? Was he using silence as a negotiating maneuver? Maybe. But I think it was because he felt trapped and powerless. He had promised a six-month development schedule, and now the person who was supposed to lead the development effort was telling him he wouldn’t be able to keep that promise.

Most middle managers aren’t being stupid or irrational when they insist on a deadline that you know is impossible. They simply don’t know enough about the technical work to know that the deadline they want is impossible, and they do know all too well how much pressure they feel from their own bosses, customers, and other departments.

What can you do? Work to improve your relationship with your manager or customer. Be cooperative. Work to set realistic expectations. Position yourself as an advisor on schedule matters, and avoid slipping into the role of adversary. Point out that by refusing to accept an impossible deadline you’re really looking out for their best interests. Point to your organization’s history of schedule overruns, and tell them that you’re unwilling to set either of you up for failure. These points are easiest to make after you’ve demonstrated a willingness to look for win-win solutions.

Focus on interests, not positions. Suppose you’re selling your car in order to buy a new boat, and you’ve calculated that you need to get $5000 for your car in order to buy the boat. A prospective buyer approaches you and offers $4500. You say, “There’s no way I can sell this car for less than $5000.” The buyer says, “$4500 is my final offer.”

When you negotiate in this way, you focus on positions rather than interests. Positions are bargaining statements that are so narrow that in order for one person to win, the other person has to lose.

Now suppose that the car buyer says, “I truly can’t go over $4500, but I happen to know that you’re in the market for a new boat, and I happen to be the regional distributor for a boat company. I can get the boat you want for $1000 less than you could get it anywhere else. Now what do you think of my offer?” Well, now the offer sounds pretty good because it will leave you with $500 more than you would have had if the buyer had just agreed to your price.

Focusing on interests rather than positions opens up a world of negotiating possibilities. Your boss might start out saying, “I need Giga-Blat 4.0 in six months,” and you might start out saying that you can’t deliver it in less than nine months. But your boss’s interest might be in keeping a promise made to the sales organization, and your interest might be in working less than 60 hours a week for the next six months. Between the two of you, you should be able to redefine the product so that your boss can keep his promise and you can work a normal schedule.

Software negotiations can become one-dimensional tug-of-wars that focus only on schedules. Don’t dig into a position. Make it clear that you’re happy to consider a full range of alternatives.

Invent options for mutual gain. Instead of thinking of negotiation as a zero-sum game in which one person wins at the other’s expense, think of it as an exercise in creative problem-solving–the truly clever negotiator will find a way for both parties to win.

Your most powerful ally in schedule negotiations is your ability to suggest options. As the technical expert, you can suggest a wealth of possibilities and tradeoffs that the other person probably has no way of knowing about otherwise. The person you’re negotiating with is bound to find some of those options more appealing than others.

Here are some options that can shorten the schedule by changing the characteristics of the product you’re building:

• • Move some of the desired functionality into version 2. Few people need all of what they ask for exactly when they ask for it.
  • Deliver the product in stages–for example versions 0.7, 0.8, 0.9, and 1.0–with the most important functionality coming first.
  • Cut features altogether. Features that are time-consuming to implement and often negotiable include the level of integration with other systems, level of compatibility with previous systems, and performance.
  • Polish some features less–implement them to some degree, but make them less fancy.
  • Relax the detailed requirements for each feature. Define your mission as getting as close as possible to the requirements through the use of pre-built commercial components.

Here are some options that can shorten the schedule by changing the resources available to do the project:

• • • Add more developers if it’s early enough in the schedule to avoid the “mythical man-month” syndrome.
    • Add higher-output developers, for example subject-area experts.
    • Add more administrative support.
    • Increase the degree of developer support. Get quieter, more private offices; faster computers; and approval to use higher priced, faster turnaround developer-support services.
    • Eliminate bureaucratic red-tape. Set your project up as a skunkworks project.
    • Devote a full-time end-user to the project who has the authority to make timely decisions about the product’s feature set.
    • Increase the level of executive involvement. For example, if you’ve wanted to try using JAD sessions but haven’t been able to get the executive sponsorship you need, this is a good time to ask for it.

Here are some options related to the schedule itself:

• • • Set a date to use as a schedule goal but not as an ultimate deadline. Agree not to set a deadline until you’ve completed the detailed design, the product design, or at least the requirements specification.
    • Agree to use broad estimation ranges rather than single-point estimates and to refine them periodically as the project progresses.

Throughout the negotiations, focus on what you can do and avoid getting stuck on what you can’t. If you’re given an impossible combination of feature set, resources, and schedule, say, “I can deliver the whole feature set with my current team four weeks later than you want it. Or I can add a person to the team and deliver the whole feature set when you want it. Or I can cut features X, Y, and Z and deliver the rest with my current team by the time you want it.” The key is to take attention away from an “I can’t do it.” “Yes you can.” “No I can’t.” “Can!” “Can’t!” shouting match. Lay out a set of options you can do, and focus your discussion on those.

Insist on using objective criteria. A key to breaking deadlocks with principled negotiations is to use objective criteria. The alternative is to break negotiation deadlocks based on willpower. I’ve seen schedules for million-dollar projects determined by which person could stare the longest without blinking. Most organizations will be better off using a more principled approach.

In principled negotiation, when you reach a deadlock, you search for objective criteria you can use to break the deadlock. You reason with the other people about which criteria are most appropriate, and you keep an open mind about criteria they suggest. You don’t yield to pressure, only to principle.

One key to keeping schedule negotiations focused on principles and not just desires is to insist on a rational estimation process. One of the oddest aspects of our business is that when careful estimation produces estimates that are notably longer than desired, the customer or manager will often simply disregard the estimate (Capers Jones, Assessment and Control of Software Risks, Yourdon Press, 1994). They’ll do that even when the estimate comes from an estimation tool or an outside estimation expert and even when the organization has a history of overrunning its estimates. Questioning an estimate is a valid and useful practice. Throwing it out the window and replacing it with wishful thinking is not. Simply writing down a shorter schedule won’t shorten the amount of time it will take to create a given product anymore than writing down a different number in your checkbook will give you more money. It will just increase the risk of being late.

Parents know that the best way to divide a piece of cake between two children is to let one child cut the cake and let the other child choose. The process is inherently fair. Similarly, the practice of letting marketing own the feature set, management own the resource allocation, and development own the schedule defines responsibilities in such a way that none of the parties can take unfair advantage of another.

Weather the Storm

Although different people tolerate pressure differently, if you are pushed to change your estimate without also making changes in the feature set or resources, you should politely and firmly stand by your analysis. No one really benefits from setting impossible schedules. Develop your negotiating skills and push for realistic solutions so that you can deliver what you promise. Batten down the hatches and endure the thunderstorm of an unwelcome estimate early in the project instead of the hurricane of schedule slips and cost overruns later on.

Editor: Steve McConnell, Construx Software  |  More articles