Eight Tips on How to Manage Feature Creep

Feature creep, also known as scope or requirement creep, refers to unforeseen requests for additions and changes that are outside the project scope. It typically happens due to inadequate requirements gathering, poor initial planning, and an unclear protocol for change implementation, among other things. In this article, I’d like to discuss eight tips and suggestions, based mostly on my experience, to help minimize and manage the effects of feature creep in your own projects.

1. Accept that feature creep will happen.

That’s right. Here you are thinking that this article’s all about preventing feature creep. On the contrary, I feel that it’s a natural part of any project-based work.

Acknowledging this eventuality will allow you to be prepared when it finally rears it’s ugly code-retrofitting, design-wrecking head. Anticipating unforeseen changes in your plans forces you to be more adaptable, and promotes the development of a solution that’s flexible and malleable to your client’s ever-changing needs.

2. Commit enough time to requirements-gathering.

Easy enough, fairly common sense, but we’re all guilty of rushing the planning phase of projects. Maybe it’s because of time and budgetary constraints, or our eagerness to show our clients tangible results, or the assurance we get that the project’s in the bag once we start it (and won’t be given to competition). Skimping on this step can lead to agony at the end, and can take the form of unanticipated feature requirements because of our failure to establish the client’s actual needs.

Take time to survey the people involved, observe and shadow employees to see how they might use the system you’re developing, and get an accurate estimation of the technical expertise the organization has. An ounce of prevention is worth a few thousand lines of code revision.

3. Giving a hand might cost you your arm.

If you constantly give in to changes, you might be get more of them in the future. Try to set boundaries of what is and isn’t appropriate to revise, this not only prevents unneeded requests for changes, but gives the project strict quality-control guidelines. When you do decide to comply to un-scoped demands, make sure that you indicate that you’re doing something out-of-scope, and that this can cause delays and additional financial requirements.

This may make them re-consider the value of the feature requested, or at least give you an extension in time and budget.

4. Be the devil’s advocate when changes are requested.

You were hired and assigned to the project because of your knowledge and expertise in the solution required. If a client asks for a Flash-based navigation menu, it is your expert obligation to convince them that the CSS-based menu you developed is a much better solution. Don’t be afraid to contradict unwise feature requests; providing well-formed reasons will assure them that you know your “shizznit”, and they may actually allow you to proceed as originally planned.

5. Be task-oriented, not vision-oriented.

Be clear on what it is, exactly, you’re developing for them. Don’t promise a grand, exciting, but ambiguous/ambitious end result. Instead of giving broad generalizations such as “I’ll be developing a search engine optimized website”, try to outline the deliverables that you will provide, such as: “I’ll be using image replacement techniques for sub-headings, creating and implementing a Sitemap.xml, submitting the site to major search engines, and optimizing page titles with relevant keywords”. This makes the project less ambiguous and prevents additional tasks, such as developing a link-exchange program to increase page rank results, which is clearly not part of your duties.

6. Shed the “Customer is Always Right” mentality.

You, more often than not, are a more qualified judge of how things should be developed. You’re not working to get a big tip at the end. You’re working (most probably) on a flat rate fee or an agreed-upon compensation.

All you have to worry about is your reputation and producing an excellent solution. The employer can hate everything about you, but if you’ve provided an amazing profit-generating product, you’ll get hired back to do more. In the end, it’s more about profits and deliverables and less about how your employer loves your “reasonable personality” (because they love nothing more than making a bundle of cash or reducing their overhead due to the solution you developed).

So don’t give in to unwarranted requests and unreasonable timelines simply because you want to be on your employer’s good side. Don’t feel pressured to do something that isn’t in the job description or something you feel will lead to a less desirable end product.

7. Research before committing.

Assuage the temptation to immediately accommodate a change in project scope, no matter how seemingly simple. If you think the budget and timeline can handle a modification in plans, research thoroughly on what the change actually entails before committing. For example, in a CMS development project I was involved in, I was asked if it was possible to migrate the system from our servers, to the client’s.

This wasn’t part of the project scope, as the original plan was to also provide hosting for the system. I agreed to it thinking that a database export/import and file migration would take an hour’s work at most. I failed to account for the fact that our server set-up (being IIS 6.0/Windows and the client’s being Apache/Linux) and server settings were different.

Suffice it to say that it took longer than anticipated and the task is still unfinished.

8. Realize that feature creep is a two-way street.

Clients and employers aren’t (purely) evil. They don’t intend to make our jobs more difficult. Oftentimes it’s our desire to please, to prove our worth, and our perfectionist mentality that can be, in part if not equally, to blame.

If feature creep happens, it’s only because we allow it to. I hope this article was able to impart some tips on how to manage feature creep. The suggestions here are based on my own mistakes in regard to allowing scope creep to affect my projects.

I hope that by reading this, you have better luck in alleviating the impact that features out-of-scope can have on your timelines and budgets.

I’d like to ask: should feature creep be accepted as part of any project, or should it be prevented flat out? Are these tips ideal but unrealistic, and in what sense? Share your thoughts!