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.