Eight Tips on How to Manage Feature Creep

Feb 6 2008 by Jacob Gube | 68 Comments

Photograph by Martin Kingsley featuring Post-it notes stuck to a bulletin board.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 with regards 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!

Photo above kindly provided by Martin Kingsley

68 Comments

Kenley Capps

February 19th, 2008

Coming from a background of usually being the developer who has to put on the project management hat often, I would have to agree whole-heartedly with this article. Feature creep can never be completely avoided. This is primarily due to the clients’ natural inability to know what they’re asking for, and furthermore, the fact they will never know exactly what they want from the start. It’s up to us to help guide them in that direction while satisfying their goals and requirements, without bending over backwards.

miramardesign

February 19th, 2008

Great Article and so true.

Number 7 is a biggie. I had a boss promise to move a video sharing site from one host to another in 4 hrs. The php program depended on linux executables(ffmpeg etc) on the server, when we changed the host the ffmpeg installed was different so the video upload script broke.

It took 2 weeks to do our 4 hr migration. lol

Lori

February 19th, 2008

Don’t show this to my webmaster!

AkitaOnRails

February 19th, 2008

There is no Silver Bullet. I’ve experienced everything: pure ad-hoc, PMP, CMMi, some Agile practices (though not ‘purely’ Agile – whatever that means). None of them help at decision-making. There is absolutely NO process that defines ‘decision’. So, there is no recipe for what is a ‘good’ or ‘bad’ decision. Feature creep is the direct outcome of a bad decision early on. Too bad we can’t predict the future. The only one thing that can lead to better decision-making is Experience and Guts. Just that. Amateurs will make more bad decisions than Senior personnel, and this is a fact.

Andy

February 19th, 2008

I usually find it’s the most demanding clients that feature creep the most, while paying me the least.

Taking on a client you sense to be a bottom-feeder is just like unprotected sex… oh so tempting, but the consequences can REALLY suck.

Michael Ott

February 19th, 2008

Number 6: Bingo. I say this all the time.

Thanks for the affirmation.

Shycon

February 19th, 2008

Great post… even greater domain name! Six sounds like about the right number…

Chad

February 19th, 2008

Some tips on tactfully talking to clients when they introduce new features would be helpful. I find it hard to say “this wasn’t in the original specs” without coming across defensive.

Patrick Allmond

February 19th, 2008

This goes well with my post about 5 ways to screw up a web project:

http://stopdoingnothing.com/2007/12/10/5-ways-to-screw-up-a-web-project/

Bottom Line: Accept and embrace change. But explain it’s impact and ensure your clients are willing to accept the change in scope or the change in cost. Or another I way I like to explain it: On any project…

1. You can have it right,
2. You can have it fast,
3. And you can have it cheap.

… but you only get two out of the three!

Keep up the great posts.
Patrick

Jacob Gube

February 19th, 2008

Thank you all for your positive and re-affirming comments.

Kenly: Glad to see other web developers sharing the same situation as me where a lot of times, I’m not only the lead developer but the lead project manager. When I first started out, I thought someone else would be doing the logistics, the budgeting (and justification), the requirements-gathering, the dealing with the client, while I get to do all the fun stuff like the web design or developing the web application or re-tooling OS apps for our custom needs. I guess it’s a good sign when you’re entrusted with these responsibilities though.

Miramadesign: I learned #7 the hard way, but it’s all part of appeasing the higher-up’s and proving that you’ve got what it takes. I strongly believe though, that it’s a lot better to under-promise and over-deliver than vice versa.

AkitaOnRails: I agree with you 100% that there isn’t a step-by-step guide on how to manage feature creep. These tips come from my own experiences and from what I’ve seen my colleagues face on a daily basis. I also agree that there’s no better way to learn what works for you than by experiencing it first hand.

Andy: Very colorful analogy :)

Shycon: You’re the first person to comment on the website’s name! I was considering Nine Revisions but that seemed too much. I got the inspiration from my earlier freelance work (web design, identity/branding design, print design). I ended up providing 2-6 revision sets before the client settled on the final design.

Chad: I struggled with this issue when I first started out. I remember an experience when I said “Yeah, we can do that… depending on your budget”. Poor choice of words (apparently) because the client was frustrated and offended that the feature requested wasn’t part of the original project scope. Thinking back now, there’s at least 10 different ways I could have approached that situation in a better way. An article that I’ve been preparing to write is on the topic of conversing with people who don’t have the same computer technology background as us, based on what I’ve learned in the past.

Londoninfotech

February 19th, 2008

thanks. really nice info !

Matt

February 20th, 2008

“The only one thing that can lead to better decision-making is Experience and Guts. Just that. Amateurs will make more bad decisions than Senior personnel, and this is a fact.”

But at the same time, Amateurs’ll make a choice or come up with ideas Senior personnel wouldn’t approve of.. i.e., they’d willing to try things the Senior programmers wouldn’t, and this can lead to either success or failure.

Laars Johnsen

February 20th, 2008

I find it absolutely astonishing that Scrum was not even mentioned here, because it solves all of the problems you’re describing here. Not just theoretically, but in real-world, nuts-and-bolts practice. It makes change easy to manage and enables you to retain the “customer is always right” approach to doing business. The result is happy developers and DELIGHTED customers.

The PMI mentailty of the faster/better/cheaper constraints (“pick any two”) fails to account for two important factors that CAN deliver all three: (1) skill (always choose the most talented engineers), and (2) processes (choose a methodology that serves the needs of both customers and developers). They’re not mutually exclusive, unless you’re trying to cling to the doomed-to-fail waterfall approach.

Dheeraj Kapoor

February 20th, 2008

Insightful article for everyone who is dealing with client project management. I especially liked #3 as I lost many arms before I learned it hard way. Keep the good work up!!
DK

John Murray

February 20th, 2008

1. Specification of requirements must be complete & unambiguous at the start of the project.
2. Specification of requirements must be signed off by the customer before work begins.
3. Feature creep can be allowed, but the customer must realise the impact that this has on timescales and budget.
4. ‘Timeboxing’ is a useful process to help in this. Project is broken down into primative deliverables, each with a milestone. Project is refined as progress is made.

Andreas

February 20th, 2008

True, i would defenetely agree to all of these, however no matter how many of these items you implement, scope creep will eventually,,creep back in in some way or other,,,even if it is simple changes… i found prototyping to be a good way of solving (sometimes creating) problems. Plus loccking features down is also a good way of getting things out the door on time to cost,scope and quality….

Chris

February 20th, 2008

I agree. Scope creep is an unavoidable part of the development process. It should be tamed early in the project however, lest it turn from scope creep into the scope monster that ate [insert major metropolitan area here]. All valid points here.

Scott

February 20th, 2008

Good post. To address your question about whether “feature creep [should] be accepted as part of any project.”

Any good project will inherently have scope creep because the project is going to evolve as the project team (strategists, designers, developers) collaborates to create a solution for the client. If a project is not evolving from the proposal to discovery to execution, you’re most likely letting the client dictate too much about the project (or vice-versa). The most successful projects are cooperative, and with cooperation comes scope creep.

Kim Beasley

February 20th, 2008

I am so thankful that you put into words what all web designers experience on web projects. The one thing that stood out to me was that you should research before committing to a project. I whole-heartedly agree that this is an important thing to do because it helps you to have a firm understanding of what you are getting into.

Also, when feature creep tries to happen, I always refer back to the contract and then I explain that if it is out of scope, there could be additional cost. There is a statement in my web project contracts that states if additional request occur that are out of scope for the project that additional fees will be applied.

Kim Beasley
http://www.CustomizeWordPress.com

Jeb Banner

February 20th, 2008

thanks for the post, I strongly agree and have forwarded it to a number of associates who found it very useful, keep up the good work

Tony

February 21st, 2008

Another strategy for scope creep is to identify all the “great ideas for enhancements” and such as Phase 2 projects, and essentially refuse to add them to Phase 1 until it is complete. Then, after the original (Phase 1) project is completed within scope, you automatically have another Phase of the project lined up, and so the relationship can continue in a series of discrete projects rather than one, never-ending, relationship of woe.

John

February 22nd, 2008

If the clients were always right, they wouldn’t need me in the first place.

Evan Hamilton

February 22nd, 2008

This article is great and I fully agree (#4 is particularly validating). That said, I want to be devil’s advocate for the other end of things: developers and clients, don’t let the PM keep you from dreaming and innovating…that stuff is important. Just make sure to listen when they say “no”.

Video

March 1st, 2008

thanks for the post, I strongly agree and have forwarded it to a number of associates who found it very useful, keep up the good work

Jacob Gube

March 4th, 2008

Thank you all for the kind words of encouragement! I write these posts from the heart and your comments only further fuel my passion for web development!

Stay tuned as I’ll be writing more frequently! I’ve got a few potential guest posts in the works, and tons of great ideas that I think the crowd will love!

- Jacob G.

Jonathan

March 5th, 2008

Jacob, I really appreciate these insights. I don’t work in web development. I work in print graphic design, but can see parallels between the two worlds. Keep up the good work.

dennis

March 11th, 2008

jacob…thanks for a great article.

this is a great subject and one that vexes many a designer. it sometimes is very difficult to say “no”, but it is usually ok if you say “yes, i/we can do this” and then continue on to explain the additional cost and time it should require. most clients can decide at that point if it is worth the additional expense or time required.

Paul @ Web Design Ireland

May 19th, 2008

Jacob,

Great stuff (as always). Worth mentioning that its good practice to get everything down on paper (i.e. pre-contract) and make sure the client understands the implications of creep..and the associated costs. Then they will want to work at it to get the initial requirements further refined.

Josh Nankivel

August 30th, 2008

Excellent points! Scope creep is not the enemy if it is managed well. It is critical to have a good change management process in place and steps to ensure that any changes really provide more value than the alternatives. A formal process of reviewing these changes is a great way to ensure that “only the strong survive” when it comes to potential scope changes.

Josh Nankivel
pmStudent.com
The Art of Project Management

Bill Hayward

September 12th, 2008

There is a big difference between scope creep and scope change. Creep can’t happen if the business users have signed off on the requirements. They can however introduce scope change. Change can be controlled and measured.

David Sherwin

December 4th, 2008

Something that I’ve used to shut down scope creep is to have a client sit in on a risk assessment that includes scope creep as one of the risk factors. Once they’ve realized how much risk they add with throwing in new changes through the design and development phase, they start to triage ideas themselves and filter through only the ones that are mission critical (and can still be change ordered).

This generally only works if you have contacts within your client organization that will work on the risk assessment with you collaboratively as a team, and if you generate it early enough in the process that it is truly proactive.

lrt

December 15th, 2008

as a beginner, i’m glad to see i’m not the only one experiencing this problem. usually i don’t mind scope creep as long as its small and reasonable. sometimes clients do get carried away and i have to tactfully explain to them why this will probably push back a release date.

vaziyet

May 1st, 2009

If the clients were always right, they wouldn’t need me in the first place.

yemek tarifleri

May 4th, 2009

This generally only works if you have contacts within your client organization that will work on the risk assessment with you collaboratively as a team, and if you generate it early enough in the process that it is truly proactive.

Hippi

June 12th, 2009

jacob…thanks for a great article…

rap

June 13th, 2009

Jacob, I really appreciate these insights. I don’t work in web development. I work in print graphic design, but can see parallels between the two worlds. Keep up the good work.

dizi izle

June 22nd, 2009

There is a big difference between scope creep and scope change.

youtube izle

June 22nd, 2009

as a beginner, i’m glad to see i’m not the only one experiencing this problem. usually i don’t mind scope creep as long as its small and reasonable.

Aşk mesajları

June 25th, 2009

I agree. Scope creep is an unavoidable part of the development process. It should be tamed early in the project however, lest it turn from scope creep into the scope monster that ate [insert major metropolitan area here]. All valid points here.

NBA

June 28th, 2009

There is a big difference between scope creep and scope change. .. Really Cool

günlük altın fiyatları

July 10th, 2009

thanks for this great article!

aşk sözleri

July 17th, 2009

There is a big difference between scope creep and scope change. Creep can’t happen if the business users have signed off on the requirements. They can however introduce scope change. Change can be controlled and measured.

Mask-Animasyon

August 12th, 2009

There is a big difference between scope creep and scope change. Creep can’t happen if the business users have signed off on the requirements. They can however introduce scope change. Change can be controlled and measured.

gottensikis

August 19th, 2009

agree. Scope creep is an unavoidable part of the development process

lazer epilasyon

September 3rd, 2009

I strongly agree and have forwarded it to a number of associates who found it very useful, keep up the good work

diyaliz

September 18th, 2009

There is a big difference between scope creep and scope change. Creep can’t happen if the business users have signed off on the requirements.

dizi izle

September 18th, 2009

Scope creep is an unavoidable part of the development process…

dizi izle

September 19th, 2009

Thank you for you detailed explanation

LiderPaylasim

October 1st, 2009

Thanks for that.

Sean "Bluefox" Blake

October 20th, 2009

All these tips are crazy helpful when dealing with the creeps that happen, but more importantly, I understand that it will happen, BUT what can we do to prevent it from happening often?

PM Hut

October 21st, 2009

Martin,

I’ve published a whole series on scope creep (9 articles in total). The series starts by explaining what scope creep really is, how to avoid it, and how to deal with it. You can check it here .

ahmet maranki

December 16th, 2009

There is a big difference between scope creep and scope change. Creep can’t happen if the business users have signed off on the requirements.

indir

December 24th, 2009

thank you Jacob Gube.

I’m from turkey. perfect six revisions.

hastalık belirtileri

January 19th, 2010

it’s such a great article. i’ll tell about this to all my friends as soon as possible. thanks for everything.

Geoffrey

February 17th, 2010

I have had quite a few clients want the next Myspace. Yet it had nothing to do with their site or product, they just saw the success of Myspace and suddenly wanted me to make them their own version.

Şiir Dinle

March 15th, 2010

I agree. Scope creep is an unavoidable part of the development process. It should be tamed early in the project however, lest it turn from scope creep into the scope monster that ate [insert major metropolitan area here]. All valid points here.

Cagatay

June 9th, 2010

Thanks for that.

I haven’t submit comment since 2 minutes :S

diziizle

June 29th, 2010

It should be tamed early in the project however, lest it turn from scope creep into the scope monster that ate [insert major metropolitan area here]. All valid points here.

hali yikama

August 21st, 2010

Very successful and wonderful.

Craig

September 20th, 2010

These are eight great tips on how you can manage feature creep, and glad you begun with accept feature creep will happen, this is just part and parcel of web development, but these tips will definitely minimise this!

Gemma

October 11th, 2010

Some of these people here are copying other people’s comments purely just to get their link in. So annoying, Six Revisions need to clamp down on these people.

Now, back to the article. I’ve been having some thoughts about scope creep. I recognise the difference between scope creep and scope change.

I think what I’m going to try with regards to scope change, I will tell clients that if they wish to change a part of the requirements we’ve decided on, if it’s a minor change and they ask me well in advance, then I will implement it at no further cost, as long as I don’t have to outsource. Otherwise, it’ll be at an extra cost, depending on the timing and on whether I need to outsource.

But for scope creep AKA adding extra features that aren’t in the plan, then it’ll be at extra cost, whether I have to outsource or not. Or the other option is to tell the client that I can implement these extras but it will have to be done under a new contract, as a new project. I.e. the current project is to get the essentials in, and then start a new project to add the extras.

Jacob Gube

October 11th, 2010

@Gemma: We’re trying to spot link spammers as much as possible, but as you can see, with a ton of content and the high-volume of comments this site gets, things slip through the cracks. Last month, we received 18,964 spam comments. About 10-15% of that reaches the moderation queue for manual moderation. That’s 1,800+ comments that might be legit that we have to evaluate manually. That does not factor in spam that doesn’t get caught automatically. Last month, there were 955 comments that were spam that were not caught.

So, I apologize for the inconvenience, but I want you to know that we’re hard at work to make sure the comments are as high-quality as possible without taking away the privilege of leaving comments on the site or taking away the ability to link back to your site because you should get some link juice for the comments you write — and if that increases the number of link spam we get quite dramatically, it’s a price we have to pay so that legit commenters can retain their privilege to mention their URL.

Dave Keays

January 23rd, 2011

When it comes to getting paid, a customer holds the purse strings and therefore is always right. The contractor needs to either be tactful when pointing-out a customers mistakes or be willing to walk away a poorer man.

How can you force either strong planning or small iterations (XP) onto a client who doesn’t see the value? Where a client says “I just want it done right” What am I going to say “I want to do it wrong”?

Dan Henry

February 26th, 2011

I think with the way the economy is now, giving invoices can be dangerous for contractors. If we do not get paid, we are consumers too. Remember that

ranjit

May 28th, 2011

Really its true and great article…

omegle

July 13th, 2011

I have had quite a few clients want the next Myspace. Yet it had nothing to do with their site or product, they just saw the success of Myspace and suddenly wanted me to make them their own version.

Peter Drinnan

August 30th, 2011

I give my biggest thumbs up to items 3 and 5

3. Giving a hand might cost you your arm.
5. Be task-oriented, not vision-oriented.

In my current role as a project manager, I have found that it is really important to stand my ground and not let the client feel they can get things out of me because I seem like a friendly guy. It takes strength to stand firm while maintaining a friendly posture and a smile. The key is to NEVER get angry with a client. The moment you do, you have lost.

LW Design

November 21st, 2011

I have a client who things I am a logo vending machine but is reluctant to put money in any longer for further ideas. Problem is he is not making a decision, not knowing what he wants. I have been assertive now in saying that further work will be charged for for any new ideas. I think presenting him with 13 ideas, revising 2 of them with colour variations and modifications 3 times in a shortlist is reasonable enough to now add additional costs for further work. Another thing I find annoying is when the client, on top of this emails his own logo sketch ideas after you have presented a load of ideas already that you were very happy to present.

Leave a Comment

Subscribe to the comments on this article.