Why is your favorite game late? Why is your own project slipping? Chances are good that one of the reasons is an acute case of feature creep. Feature creep -- requirements changing during development -- is a major risk for virtually every game project. Various project size changes lead to increased complexity, effort, schedule, and budget. Given the average complexity of a game project, it's safe to say that almost all of us have experienced feature creep. If uncontrolled, changing requirements can overwhelm even the best-planned effort, and quickly put your project in trouble.

Case Study: Too Eager to Please

You are probably involved with managing projects because you are good with people. You probably like to make people happy. That same attribute that serves you well, however, can also get you into big trouble. Take, for example, one of my first projects.

My company was hired to build a creativity-based kids' product for a major toy corporation. Eager to please a new client, we committed to a fairly short schedule and an aggressive list of features. The design wasn't finalized before we started development, and I didn't resist any feature requests. I didn't want the client to think we couldn't deliver what they wanted. After all, none of the individual requests was anything very complicated. More image processing effects, fancy scene transitions, a rollover help system -- anything they wanted, we could do without a problem. Until, that is, the engineers on the team started to raise concerns that they were running out of time to get everything implemented.

In my initial scheduling, I hadn't planned on anything that wasn't in the original specification. I had failed to realize that the original specification was filled with design holes that would require filling with new dialog boxes, help messages, error messages, and other completely necessary features. Each day seemed to add "just a small request," until we realized we would be late for our first major milestone. In an effort to get the project back on track, I tried to work with the client to cut features from the product. This only managed to upset the client, without achieving enough significant cuts to get the project back on track. Ultimately, we shipped the project several weeks late to a client that was less than completely satisfied.

Wanting to avoid my pain, you may be tempted to simply freeze your design and ban feature requests from your project. But when it comes to changing requirements, abstinence is not the answer. In a rapidly changing industry, designs must evolve during development for a product to stay on the cutting edge. When you get feedback from early users such as beta testers, you need to pay attention to the valuable input you are getting. Your goal is to balance flexibility with sound project management. It's not easy, but it can be done.

Case Study: Do You Want to Bet One Month's Salary?

After the failure described above, I was determined to do a better job of preventing feature creep. I was convinced I could do it without being completely inflexible and upsetting the client. At the beginning of the project, however, it looked like my goal would be tough to achieve. The client was asking for a lot of features, and on a very short schedule.

After my previous experience, one thing was clear to me: it's better to have the tough discussions about features at the beginning of the project instead of toward the end of the project. Convinced by a colleague that it was better to do no business than bad business, I risked upsetting the client by raising the feature and schedule mismatch in our first meeting. I realized that the client would not simply want to hear me whine, but would want a solution. Even better would be to offer the client multiple alternative solutions. Armed with a feature list, a short schedule, and a good technical lead that could estimate accurately, I did a preliminary schedule.

At this early stage, most estimates were rough, and covered a range from a low estimate to a high estimate. I understood the product design and it seemed solid, but knew that unexpected issues would come up during development, so I added some extra room to the schedule for an unknown task. I then created three feature lists. We could build the product with all of the features in the long list if we used all the low estimates. Trimming a few features, we could build the medium list if we used an average of the low and high estimates. Trimming a few more features, we could build the short list if we used all the high estimates.

I presented the three feature lists to the client, and tried to explain the different levels of risk in terms they could understand. "If we build the shortest list of features, I am confident we will be on schedule. I'm so confident, that I would bet one month of my salary that we deliver on schedule. In the medium list of features, I would still take that bet, but only if I got 2 to 1 odds. And I wouldn't bet at any odds that we could build the long list of features on schedule." The client opted for the middle set of features, which is what I expected.

In the early meetings to work out design details, I kept an eye on the list of features to make sure it wasn't growing too large. But I also suggested features that I thought would be helpful to the product without adding a lot of work. I knew that I had a little bit of room in the schedule, and I wanted to use that room to build the best product I could for the client. This helped earn the trust of the client. We both felt that we had the same goal: build the best product we can within the required short schedule.

During development, the client requested many minor changes. A few of them I agreed to, since I knew that they really didn't have a big effect on the development effort, and would help the product. But most of the changes I resisted. If I could find an alternative solution, I would present that to the client. They almost always accepted the alternative happily. If I couldn't find an alternative and knew the change would add risk to the project, I simply explained that fact. Given the short schedule and everyone's desire to ship on time, the client understood why I was resisting changes. Since I had offered some features during design and agreed to some changes, the client understood that I had the product's interest at heart.

This project was completed on time and on budget. While not every conversation with the client was easy, in the end we all still respected each other and liked working together. I had learned an important lesson: I had controlled feature creep and also managed to keep the client happy.

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:

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.

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.

Don't 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.

Many cases of feature creep have been documented in articles available on Gamasutra. Some of these include:

Postmortem: Ritual Entertainment's Sin
Ritual Entertainment found both the value and costs of changing requirements:

The Psychology of Artists and Programmers
This article describes a classic case of "developer gold-plating":

Postmortem: Raven Software's Heretic II
Raven Software experienced feature creep that improved their product but caused them to miss their date:

Postmortem: Westwood Studios' Command and Conquer:
Tiberian Sun
Westwood Studios did some feature-trading, and ended up wishing they had cut even more to make room for features that were added:

Postmortem: Surreal Software's Drakan: Order of the Flame
Another case of feature creep causing schedule slips:

Postmortem: Sierra's SWAT3: Close Quarters Battle
A case when the schedule really couldn't move, so the feature set shrank: