Beware the insider. Even if you diligently watch every feature request coming in to your team, your project may still be suffering from feature creep. Often your own development team will add features that aren't specified, or develop a feature to a higher level than needed.
On a project for a major new client, a developer decided to implement a dynamic panning system for character dialogue. Depending on where the character was on screen, the audio would be panned to the left or right channel. Was it a good effect? Absolutely! Was it necessary? Absolutely not. Did it adversely affect the schedule? Yes.
Whether motivated by pride, interest in the technology, or competition, many engineers are routinely guilty of "gold-plating" an application. In addition to managing requests coming from outside the team, you need to check in regularly with the team to ensure that they understand the required features, and are not going overboard in their efforts. Looking at the product regularly will help you be aware of what's getting done, and whether it's necessary. Better yet, have a strong technical lead who can closely monitor what team members are doing and ensure that it is appropriate for the product and schedule. In a well-run project, a leader is closely involved with the developers and is involved with all decisions about which features get implemented, and when.
Say "yes" when you can. Agree to any changes that don't increase your work or project risk significantly. Pick your battles and don't argue the minor points, even if you don't completely agree with a minor change. However, watch for a pattern of minor changes that will add up to trouble, and resist any change that won't help the product.
While developing a product recently, I was asked if we could speed up the gameplay in a fishing activity. Knowing that this would help the product and not be a complicated change, I happily agreed. The game was improved, and the client understood that I had the best interest of the product in mind. Therefore, the client was not suspicious of my motives when I later resisted a more significant change that would have added a lot of risk to the project.
Be straightforward and true to your word. Deliver information and some form of the product early to establish as much trust and confidence as possible. When you describe where the product is coming along well and where it is having trouble, and then deliver a version that matches, your partners will understand that you assess and describe the state of the product accurately to them. Demonstrate that you want to deliver as much high-quality work as possible. I usually try to deliver a very early prototype that demonstrates product navigation as soon as possible. I will then follow with one or more pre-alphas, before finally shipping the standard major milestones: alpha, beta, and final.
Seek to understand first. Be sure you understand the change request completely. It doesn't do anyone any good to respond rashly to something you don't completely understand. I have received feedback on a major milestone and worried about changes that I thought made no sense at all. Once my colleagues calmed me down, I called the client and calmly asked to discuss the feedback. It turned out that I completely misunderstood the change requests, and thus I was very glad I had not sent an e-mail objecting to their ideas.
Offer alternatives whenever possible. You may be able to make a different change from the one being requested. Better yet, your alternative may be less costly to the project and just as effective as the original request. To offer successful alternatives, you need to understand thoroughly the underlying problem and the motivation behind the change request.
I had a client who asked to make a whole set of buttons larger. Concerned that an overcrowded screen would result, I asked for the reason behind the request. The client explained that they thought the user might not notice that the buttons were clickable. Rather than increasing the size of the buttons, we brightened the buttons' rollover pictures, and added a rollover mouse cursor. The result: neither of these changes was difficult or resulted in further complications, the product was improved, and the client's problem was solved.
Explain your reasons for resisting a change. You need to speak for the sake of the project. When you explain that you are hesitant to agree to a request because it adds a high level of risk to the project, everyone understands and usually agrees. It usually helps to acknowledge that an idea might help the product, while maintaining your position that you would rather not implement the change in the interest of maintaining the schedule.
Wait for user feedback. Particularly if you think the current design is correct, suggest that you wait for user testing feedback before making the design change. User feedback can often help settle any debate about a program's design.
I recently had an issue involving a button that returned the user to a product's main screen. The client was concerned that the button would not be intuitive and that users would not know to use that button to return to the main screen. Since I was more optimistic, and we were within a few weeks of user testing, I suggested that we wait and see if users understood the button. No one had trouble understanding that the button returned the user to the main screen, and the issue was settled without changing the product.
There's always version 2. It's easier for a client to hear, "That would make a great addition in version 2," than "We can't do that now". Particularly if you know future versions will be delivered, suggest that a change wait for the next version of the program, when you can plan for the work and schedule accordingly. Someone may be willing to wait for a feature, but not willing to give it up entirely.
Don't use your only bullet. If you tell someone you can't do a feature because it can't be done in the operating system, and then they give you a piece of code that shows it can be done, you're in a jam. You would have no credibility if you suddenly started talking about some other reason you couldn't do the change. As long as the justifications are real, give multiple reasons why you are hesitant. If those reasons can be addressed, be prepared to implement the change.
Let's make a deal. One way for people to quickly understand the impact of a feature request is to suggest a feature trade. In order to add something to the product and stay on schedule, you have to give something up.
I was once asked to add multiple colors and fonts to the text editor in a creativity program. I explained that I could do that, but in order to stay on schedule, I would need to cut the ability to move and resize pictures. Given this information, the client decided that a single font editor would be just fine.
Use your superiors; let someone else be the bad guy. It's important that people working together are on positive terms. Rapport is important. If something unpleasant must be said or done, let your boss play the bad guy and do it for you. Don't let a disagreement lead to a personal issue between you and any of your partners on the project.
When all else fails, say you can't agree to the requested change without adjusting schedule, budget, or both. Leave the decision up to the people in power requesting the change. Try to avoid a plain "no" whenever possible. People need to have choices and feel in control. Think about the change request and possible alternatives. Assess the schedule and budget impact of the various possibilities. Present different options to the person requesting the change, and let them decide what to do.
use schedule time twice. If
your schedule does slip due to feature creep or any other reason, people
who want to add features will see an opportunity. "Since we're
adding time to the schedule, let's add that feature we wanted."
The temptation to add features is obvious, but the irony and foolishness
of such an approach should be equally obvious. You're adding time to
the schedule because you need that time to develop the features you
already have specified. Don't add "just enough" time, and
then immediately take that time away by adding more features.
Beat the Creep
You can have a flexible design and still ship on time. Design as thoroughly as you can up front, and plan for unexpected changes. Understand the people and priorities of your project, and access every change request. Clearly communicate about alternatives and the impact of each potential change. Only implement the changes that will truly help the product. Either make room for the new feature by getting rid of another one, or adding schedule time as a last resort. If you keep feature creep under control, your product design can improve as you build without missing the schedule.