Longtime software engineers know that feature requests are as inevitable as the daily tides. These requests are usually made by impassioned people who preface their requests with statements such as, “I’m sure this will be easy,” or “I know you can squeeze this in for me.”
Most textbooks say you can combat feature creep by performing
comprehensive up-front planning, creating detailed time estimates, and
establishing a track record of on-time delivery to back up your claims when you
try to control the feature set. This method works great, assuming you have a
specification to design against, you have the time to do a detailed design, and
you have developers good at estimating. In many companies I’ve worked with,
particularly at the startup stage, these conditions don’t hold true. In this
article I’ll talk about why people make feature requests, and I’ll give you
five tips for successfully managing feature creep that can be used in the
typical imperfect organization.
1. Avoid Saying No
This tip is easy to put into practice, and you’ll be surprised
how far it gets you. Instead of saying “No” to people and putting them on the
defensive, give them a positive answer instead.People like to
get their way, and when something prevents that, it upsets them. If you’re a
manager, consider how you’d feel if you asked a subordinate to do something
reasonable and that person said “no” to you. You’d probably be irritated and
have to spend the next few minutes curbing your temper to try and figure out
why the employee is so difficult.
Now, consider how others in the organization feel about development. They make what they consider a reasonable request (it may not be from development’s point of view, but they don’t know that), and development reacts by saying, “No. There isn’t time.” If you’re representing development and you make such a statement, you’ve put the other person on the defensive, left no room for negotiation, and set the stage for a hostile conflict.
Now, consider how others in the organization feel about development. They make what they consider a reasonable request (it may not be from development’s point of view, but they don’t know that), and development reacts by saying, “No. There isn’t time.” If you’re representing development and you make such a statement, you’ve put the other person on the defensive, left no room for negotiation, and set the stage for a hostile conflict.
Instead, try this
answer, “I think development can do that by either dropping features X and Y or
by scaling down the feature you described.” With this type of answer, you’ve told
them how you can put the feature in as well as given them the choice of what
tradeoff to make, thereby giving them a psychological feeling of control. Both
alternatives may be poor, but at least you’ve left room open for discussion.
And you never said “no.”
Don’t confuse providing
alternatives with saying “yes.” Say what
you can do, even if it bears no resemblance to what you are being asked for. You
may not be able to generate these alternatives off the top of your head, so
don’t hesitate to ask for a couple days to study how the request will affect
you. Let people know you need the additional time,
then get back to them when you say you will.
If you’re comfortable
playing politics, you can sometimes conveniently “forget” about features you don’t
think make sense. Tell the person you’ll get back to them about the feature,
then don’t get back to them. If the request really was important, the person
will remind you about it, and if it wasn’t, he or she will forget about it.
However, you can only get away with this if you have a consistent track record
of following up when you say you will.
I can think of many
meetings that would have been a lot more pleasant for me if I’d learned a long
time ago to avoid saying “no. Saying “yes” makes you appear a more reasonable person and you guide the discussion instead
of controlling it.
2. Make Decisions Based On Business Goals
Remember, engineers don’t think like people in other departments.
This leads to serious communication gaps between departments. Often, the people
requesting a feature speak “business,” the development representative speaks
“techie,” and the two sides can’t make the other understand their positions.
The CEO ends up arbitrating, but because the CEO also speaks business,
development loses. As this scenario repeats, the development manager loses more
and more credibility and eventually fails, by not delivering the massive number
of requested features on time, even though the manager never agreed to the
features or the schedule in the first place.
The textbook way to
solve this problem is to hire program and product managers whose job it is to
understand both the business side and the technical side. Outside of textbooks
and large organizations, these jobs often fall to the senior people in
development who have little or no training in business.
Resolving this problem
requires you, the developer, to learn to speak business. If you don’t explain
your position in a way the rest of the organization understands, it will be
very difficult to break out of the vicious cycle described previously. The rest
of the organization considers software development a black art, where worker
bees can churn out any amount of code in no time at all, if they’re pushed hard
enough. Engineers know it doesn’t work this way, but trying to explain this
rarely works.
As a first example of this technique, let’s look at a situation
where it might be applied inside development. It’s Monday morning and another
developer wanders into your office. Plunking down onto the nearest flat
surface, he says, “I’ve been thinking about our rendering code all weekend, and
I think I can make it 50 percent faster with about three days of work.” So which
of the following do you tell him?
·
That’s a great idea, faster is always better.
·
Absolutely not, there’s no time budgeted.
·
“If it’s really important to you, you can do it
after hours.”
·
“That section of code is already working and we
don’t want to destabilize it.”
All of these are typical engineering answers (or excuses, depending on your point of view). But the goal is to focus developers on corporate business priorities, so you need to try another solution. Appeal to the developer’s profit side. Developers may not always understand business, but they usually have a keen interest in their own financial stake.
The first point is that you shouldn’t say no to the
developer. However, instead of offering alternatives,
teach the developer the process of making the decision. How about an answer
such as, “You’ve obviously put a lot of thought into your proposal, but I know
you’ve shown a lot of enthusiasm about our company’s upcoming IPO. How would
making that change get us closer to that objective?” You force the developer to
analyze the reasons for the change, provide the metric for making similar
decisions, and demonstrate how that metric personally impacts the developer.
This technique won’t
work with all developers, but it is important that it should work for
architects and other developers who handle important parts of the project. If
the technique doesn’t work, you might want to question whether that developer
can make decisions in the company’s best interest.
I’ll make two final
comments about deciding based on
business goals. First, in some applications, such as air traffic control
software, protecting human life is more important than the bottom line. Second,
good business decisions depend on having a central strategy and sticking to it.
For example, if your application is for XML text markup, then adding SOAP
support probably doesn’t make sense. Even though SOAP is linked tightly with
XML, SOAP is for interoperability, not for text markup.
3. Use a Prioritized Master Feature List
Detailed lists are a cornerstone of engineering. A master list of
all feature requests can be an important tool in controlling feature creep. If
you’re following a formal development methodology, you should have the
beginning of this in a Marketing Requirements document. However, if you are a
typical small company, your process may be somewhat more ad hoc.
The secret to the list is to keep it prioritized. It doesn’t need to be perfectly ordered, just
categorizing each item as 1 to 5 is probably enough, with 1 the most important
and 5 the least important. You can prioritize development resources by having
developers work first on the priority 1 and 2 features. Once these are finished, move on to the quick and easy priority 3 and 4 features.
Ultimately, development will probably ignore most priority 4 and 5 features.
You’ll discover that
everyone will try to put everything into the highest priority, but here is
where speaking the business language pays off. As the design phase moves into
the implementation phase, and feature requests start rolling in, you need to
have a conversation with senior management that goes something like this:
“Do you agree our goal
is increased revenue?” Unless you’re a nonprofit company, senior management
will almost certainly agree. (Note to techies: a business can have valid goals
other than revenue, such as increased market share or increased profits, but a
company typically focuses on just one goal, because multiple goals can
conflict. For this discussion, I’ll use revenue as the goal.)
You next question is,
“Is it therefore reasonable that any changes to features be based on the
feature’s impact on revenue?” Again, it will be difficult for management to
disagree. Note the pattern of agreement we’re creating here.
“Is it therefore
reasonable that, given that development can’t do everything, we prioritize our
features based on the feature’s ability to increase revenue?” This statement is
the clincher. It is very difficult for management to disagree with the chain of
logic you’ve created. Once you’ve had this discussion, you can use management’s
own words to control it. The only other discussion point is how much revenue a
feature should be able to bring in before designating it a Priority 1. This is
a business decision, so you can stay out of it.
To see the prioritized
list in action, consider this situation: In the lunch-time status meeting, one
of the sales people has come back from a show where she has gathered dozens of
hot leads. One lead is for a large deal with a Fortune 50 company, and closing the
deal would be an important milestone for the product. The only problem is that deal
requires four new features, one a major change. Predictably, the CEO is excited
and wants to know how engineering can “Help out” to bring in this customer. Which
of the following should you respond with?
·
The developers are already working weekends.
·
Feature freeze was last week, and it’s too late
for a change.
·
It was already agreed that those features would
be in version two.
·
This has happened over and over again, and you
won’t add yet another feature for a customer who probably won’t buy anything
If you made any of the preceding statements, you’ve already succeeded in uniting the rest of the room against you. It will be almost impossible to avoid the feature request. Instead, speak their language by asking, “What’s the revenue potential?” The sales person will name some figure, for example, two million dollars. Now ask, “How did you arrive at that figure?” If the sales person can’t offer a convincing argument, everyone else in the room will do the arguing for you.
When the CEO agrees it’s
worth moving forward on the feature, you say something like, “It sounds like
the possibility of closing is only 25 percent. Therefore, I’ll prioritize this
feature at $2M * 25 percent=$500,000.” Sales organizations commonly use this
technique to project future revenue, so there’s no reason development can’t use
it, too. A rule of thumb is that the possibility-of-closing percentage never
goes above 75 percent unless a contract is actually signed. It is very
difficult for others in the room to argue with this logic, and the final dollar
value defines the feature’s priority.
Notice you never
mentioned development’s schedule or manpower. This is important. The moment you
start talking about development’s schedule, you also have to start talking
about estimates, and estimates are controversial and difficult to defend. If
possible, avoid discussing estimates. It’s often better to accept the new
feature and then quietly drop something (or several things) to the bottom of
the priority list. If someone asks why the feature isn’t in a release, you can
reply that the revenue potential for the feature wasn’t high enough, and again
avoid discussing engineering schedule and estimates.
Unfortunately, this
technique may indicate you need to add a feature at the last minute, and the
CEO doesn’t want to slip the release. The easiest way to handle this is to
capitalize on everyone’s belief that engineering can’t adhere to a schedule.
Instead of saying you don’t have enough time, say the estimates for the task
are too uncertain, and you aren’t confident you can finish it on time. From a
risk-management point of view, you believe it would be better to finish what
you have, then do a small point release with that one feature. Business people
understand risk, and you’re again speaking their language.
4. Understand the Root Requirement
There is a big difference between what someone wants and what someone
needs when they make a feature request. This happens because of a lack of
understanding about how to effectively link a real-world solution to a
technical solution. Therefore, when a developer meets with a nontechnical
person to talk about a feature, the developer must first understand the
nontechnical requirement driving the feature request before determining the
technical solution.
Here’s an illustration.
At the end of the day, the product manager stops you on your way to the car to talk
about a magazine review of a competitor’s product and the new “must-have” items
reviewers expect in that kind of product. The product manager believes the new
product you’re working on needs these features for “parity,” and he wants to
have a meeting with you tomorrow to talk about adding these features. Before
the meeting the next morning, you could prepare notes about:
·
Why magazine reviews are useless.
·
How far the release date needs to slip to add
those features.
·
How many people you’ll need to hire to implement
those features.
·
What features the product manager recommends
should be dropped to make room for new features.
At least two of these
responses represent ideas from this article, but none is the right answer. The
solution is to go through each feature, determine the end-user requirement
driving that feature, then see if you already have the feature, but no one knew
about it, or if you have an alternative solution to get the same result.
For example, say that
one feature request from the magazine article is to “support FTP.” Many reasons
might drive such a request. Because the FTP protocol is built into many
libraries, adding FTP support might not be hard, but no work is still quicker
than a little work. By going back and reading the magazine article yourself,
you might discover the competitor’s product needs FTP support do file transfer
through firewalls. However, maybe the application you’re building already supports
HTTP file transfer. Because http goes through firewalls even more easily than
ftp, it would not be necessary for you to add support for FTP. You can now explain
to the product manager that you are already able to meet the spirit if not the
letter of the requirement. Scratch one feature request.
Another example might be
a feature request to “support XML.” Such a broad, ambiguous description could
require years of development work. You might assume that only a developer could
properly interpret what “support XML” means. In this example, further
discussion with the product manager reveals the requirement is simply to be
able to say on the box that the product supports XML. You ask the product
manager what she means by “support.” And the answer is, “I don’t know. I just
need to be able to put those words on the box.”
Now, you probably think this
is stupid. However, XML is a big buzzword right now, and lots of people have
heard of it. It’s likely someone comparing products on the shelves at CompUSA
might buy a box with a big “Now supports XML” sticker, even if that person has
no idea what XML is and has no plan to use it! So, your job is to technically
decide what “supports XML” means, and to decide the minimum amount of work you
can get away with. XML is evolving so fast that anything you do will be out of
date before it ships, so one strategy might be to create something simple and
see how customers react. This is dramatically different than a requirement to
“successfully interoperate with three popular B2B, XML-based application
servers” that a statement like “supports XML” might mean.
5. Plan Your Development Strategy
All too often, despite your best efforts, so many features get
stuck into the product development can’t finish it in time. You can combat this
by changing your development strategy. In most organizations, the strategy is to
determine the feature set, pick a ship date, then, when the date is missed,
keep slipping the date until the feature set is finally finished. I’ll call
this the “feature-driven” strategy. Unless your organization is actually
skilled at project estimating (and, judging by the number of slipped dates in
the industry, few are) this strategy rarely works.
An alternative to the
feature-driven strategy is the date-driven strategy. In a date-driven strategy,
whatever you have on a certain date, you ship. This strategy has logic behind
it. In most cases, a date is chosen for a good reason. Perhaps it’s the end of
the quarter, perhaps investors are reviewing the company, or perhaps a customer
has a “drop dead” date for certain new features. In all these cases, developers
need to recognize that hitting the date is often more important then completing
all the features. Sales prefers to have something to sell, even if it isn’t
perfect, rather than nothing at all. So, the solution is to change the
development strategy so the company can ship something on any given date.
The key change to the
development process that this strategy requires is ensuring that features as
they’re built. In too many organizations, development does months of feature
development, then tests for bugs during a huge “bug bash” at the very end,
which invariably takes much longer than anyone expected. A date-driven strategy
calls for lots of little “bug bashes” along the way to keep the product as
stable as possible. With this strategy, when the deadline rolls around,
development can offer the organization two realistic alternatives—ship on time
with a limited feature set, or slip the ship date and add more features.
Remember, with two alternatives, you avoid saying no!
Development often
presents these alternatives, but frequently unsuccessfully, because the
development process doesn’t allow for shipping on time with a limited feature
set. If you leave bug fixing to the end, you can’t estimate how long they’ll
take to fix, so you can’t ship on time, even if you leave many features are
left out. By finding and fixing bugs as you go, you can actually offer these two
alternatives and be able to deliver on either of them.
To follow this strategy, it is an absolute requirement to maintain
the prioritized feature list to make sure the features you do deliver are the ones that will have the greatest impact on revenue
or market share.
Today’s reality is that the computer industry is changing very
rapidly and successful companies must be able to change direction on a dime. To
stay competitive, a company must have the flexibility to add features as a
product is developed. Ultimately, you don’t “win” if you successfully fend off
all feature requests that appear after the design phase is over. In a
product-based company, you win by doing whatever grows the business, enhances
market share, and/or drive revenue. Computer science classes rarely teach this
fundamental point, but it is important to remember when managing feature creep.
Being successful at doing this is much more a matter of working
with people and understanding business needs than it is of maintaining detailed
schedules and estimates to prove your points. At the end of those never-ending meetings,
the most important result is that other people feel good about themselves and
the decisions that were made. They don’t care about why you’re right—they care
about why they’re right. If you can consistently make people feel good about
themselves, you’ll always be a hero.
