Gamasutra is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Gamasutra: The Art & Business of Making Gamesspacer
Killing Feature Creep Without Ever Saying No
View All     RSS
March 31, 2020
arrowPress Releases
March 31, 2020
Games Press
View All     RSS

If you enjoy reading this site, you might also want to check out these UBM Tech sites:


Killing Feature Creep Without Ever Saying No

October 20, 2000 Article Start Previous Page 2 of 4 Next

Communication and discipline are the keys to successfully managing changing requirements. By completely understanding your original design, all change requests, and the people involved, you can avoid feature creep without ever saying 'No' to a request.

Establish yourself and your team as experts, and recognize the expertise of others. If you have experience and skills producing other similar products, gently try to help everyone you are working with understand your expertise. Obviously, you don't want to appear egotistical and immediately alienate your partners -- publishers, users, teammates, management, and others. But your goal is to have others recognize the expertise you have, so they trust your opinion and input.

Similarly, ask your partners about their past experiences and recognize their expertise. Recognizing the skills that everyone brings to the design table will help all parties trust each other and communicate better.

Understand the project priorities. Everyone wants everything in a product: great performance, a huge list of awesome features, a stable program -- all at a low price and on a short schedule. But ultimately choices will have to be made. Is stability more important than performance? Are features more important than finishing by a certain date? Understanding the project priorities will help you know which feature requests make sense, and which will undermine the product goals.

You may have to use tact to learn the project priorities without upsetting people. Once I realized how important it was to understand a project's priorities, I started asking project stakeholders their priorities at the beginning of projects. To my surprise, I ended up confusing and upsetting a few people. I explained that, of course, we would do our best to deliver all the features performing well, on time and budget, without any bugs. But if push came to shove, I wanted to know if stability was more or less important than performance, or if both should take a back seat to adding one more feature. One client said she was confused, and expected to be involved in those decisions. I tried to explain that the team members would be making dozens of minor choices every day -- which algorithm to use, how many debugging checks to add to the code, and similar choices -- and that neither she nor I would be involved in every one of those minor implementation choices. The client partially understood, but the conversation ended with her still expressing concern that she would be left out of decisions.

In hindsight, I completely understood the client's concern. They absolutely should be involved in any major decisions, and a question about priorities can make someone feel like they won't be involved. But it's still very valuable to know the project priorities. Since my experience, I've taken a more subtle approach to asking about project priorities. I start by explaining my own priorities. My first priority is a stable product with a very low number of bugs at any time. I know this is ultimately the only way to develop a quality product on time. As I talk about my priorities, I gauge the client's reaction as I raise each aspect of the product. Do they enthusiastically agree when I say that stability is a priority? Do they not seem to care when I say memory usage is a lesser concern? Learn the project priorities without making stakeholders feel like they must choose between important aspects of the product, or will be left out of any important decisions.

Plan for the unexpected. Some amount of flexibility to respond to new information during development will greatly help your product. Set up the project so that you have some room to adjust to unexpected requests and problems. Obviously, you must balance the pressure to reduce budgets and schedules with the need to leave room in the development effort. Remember that doing no business is better than doing bad business, and having no room to respond to any feature requests at all is usually bad business.

Get a clear, detailed, unambiguous specification before you agree on a schedule and budget. Schedule, budget, and design must ultimately all work with each other for the project to be successful. If you are not in control of these parameters, at least one must be flexible before you come to agreement on a schedule and budget for the project. For example, you might agree to a schedule and budget, and then design a product that fits those parameters. You can only set up a successful project if you understand in detail what you will be building.

Work through the design as thoroughly as you can, as early as you can. Understand where the design is working, and where it needs more attention. Raise design issues early in the process, preferably before the project budget and schedule are set. If the people you are working with are reasonable, they will respect you for raising concerns early. In one case, I raised concerns that a voice-recognition feature was not designed into the product at all, but merely mentioned occasionally. The client agreed and confessed that the voice recognition was an unrealistic hope added to the design document at the last minute. Discovering that design issue early on likely avoided several changes to the design as the product was built.

Discuss your expectations for change requests and use a formal change control process. When will change requests be made, and by whom? Who approves the change requests? Will the team get a chance to comment on change requests before they are approved? When will users and/or important parties see the product? Will there still be time to make changes once they give their feedback? How will you settle any schedule or budget adjustments that are necessary in order to implement a change? It's always best to agree on the answers to these questions before you are in the middle of a feature request discussion. When in doubt, use a formal change-control process.

A good change control process can go a long way towards controlling feature requests, and typically involves these steps:

  1. Key team members review requested changes. Make sure all of your leads, from quality assurance to art director, have a chance to review a request.
  2. Determine the costs and benefits to the product quality, usability, schedule, budget, performance, complexity, documentation, testing, and so on.
  3. Identify and propose alternatives (more about this below).
  4. Accept or reject the change and notify everyone involved.
  5. Ensure the changes are documented and implemented properly.

The amount of formality required will vary greatly from organization to organization and team to team, depending on team size, team structure, the parties and personalities involved in the project. When in doubt, use more formality than you think you will need. A little extra overhead can bring a huge reduction in risk. And it's always easier to loosen up a formal system than to formalize a loose system.

Article Start Previous Page 2 of 4 Next

Related Jobs

Remedy Entertainment
Remedy Entertainment — Espoo, Finland

Lead Producer
Visual Concepts
Visual Concepts — Agoura Hills, California, United States

Animation Engineer
Square Enix Co., Ltd.
Square Enix Co., Ltd. — Tokyo, Japan

Experienced Game Developer

Loading Comments

loader image