Best Practices
IEEE Software, Vol. 13, No. 3, May 1996
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:
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, 11820
Northup Way
#E200, Bellevue, WA 98005.
E-mail: steve.mcconnell@construx.com
- WWW:
http://www.construx.com/stevemcc/
