Developer

Feature creeps: How to stop them from ruining a project

Feature creeps cost too much money and waste too much time. Find out what you can do to avoid having your project bogged down by these momentum killers.


You’re designing a Web site for a client, and after much work, you’ve finally finished the initial specs. While presenting them to your client, you get these kinds of comments and requests:
  • “Can you make this a drop-down list box instead of a table?”
  • “Can we have a button instead of a link?”
  • “I’m not sure I like the colors.”
  • “I’d like to make a little change in the page flow.”

Welcome, my friend, to the world of feature creeps.

Feature creeps are exactly what they sound like—features and requirements that creep their way into function and design specs and, occasionally, the actual deployment of a site. How can you develop and design a quality site when all requirements and functions are not specified initially? In short, you can’t. But there are a number of steps you can take to keep a project on track.

Reduce the amount of wasted time
“Building a Web site is like building a home. It may be easy to change something small like a light fixture,” said Lee Kaldor, director of operations for ComMark, Inc., a North Dakota-based marketing consultant firm, “but if you want a fireplace when all the walls are up, you have to tear everything apart.”

To get the creepers under control, you must have a solid process that you and your clients follow. All features and specifications must be indicated before you create documentation and certainly before any development gets underway.

You may be thinking, “Clients pay me to deliver what they want.” While this may be true, there are ways to give clients what they want in a systematic way, which reduces time wasted on your part and money wasted on theirs. If you don’t clearly define a process in the beginning, you’ll have feature creeps all the way to production, creating a deployment nightmare.

Creating a process
The first step is creating a process. Start by meeting with your client and the developers involved. Make sure you keep the client and the developer in the same information loop. This way everyone is kept up-to-date, and there is little chance of miscommunication. ”I do not start a project until everything is in hand and on the table,” said Alex Kahl of Kahl Consultants, a firm that designs Web sites for small businesses.

Have your client list all the functions, features, and specifications he or she would like the site to have. From those features, draw up a functional document. This should include all the functions the client wants the site to perform. Have the developers draw up a design document. This document should include the design specs as well as give an estimate of how long it will take the developers to complete the work and how much the project will cost.



Present the design and feature documents to the clients. Notify them of any extensive work that may be involved. At this point, the client has the opportunity to make any feature or function changes. If there are changes, draw up a new design document that reflects those changes and resubmit them to your client.

Have your client sign off on each step of the process. This way, your client is aware of all the work being done, and you have a signature and a way of documenting the process.

You were hired to provide your client with a service, Kahl explained, and “the customer is king.” So give them what they want, just be sure to communicate that the more changes made, the more money it will cost and the more time it will take to get the site up and running. This way, there are no surprises.

Last but not least, hold regularly scheduled meetings with all involved. These meetings should address the progress, issues, problems, and updates of the project. “There is no such thing as too much information” when dealing with clients, said Kaldor. “Rigid disciplined communication dissemination is a must.”

Reiterate to your client that sticking to the process or timeline is crucial. Developers cannot hit moving targets. When changes are made, the development team has to stop, redesign, regroup, and push deployment dates back.
How do you deal with last-minute changes to a Web site design? Give us your thoughts by posting a comment below. If you have a suggestion for an article, please send us a note.

Editor's Picks

Free Newsletters, In your Inbox