Digg

Discover the best of the web!
Learn more about Digg by taking the tour.

How To Manage Feature Creep: 8 Simple Tips

sixrevisions.com — Feature creep (also known as scope or requirement creep) is the term used for additional requirements that get tacked on outside of the original project scope. Here's some essential ways to help you manage feature creep on your own projects.

Bury

jggube 156 days ago, made popular 155 days ago

658 diggs
digg it

frugalweb, on 02/20/2008, -7/+3excellent suggestions for the web designer
thetanbark, on 02/20/2008, -0/+19I 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.
- liquidpele, on 02/20/2008, -0/+5Similar with customers. Most people tell you if you start a business, watch out for the 5% of customers that demand unreasonable things. They're the ones that will never be satisfied no matter what, and they're your customer because other companies actively tried to get rid of them. Better to get rid of them yourself too, because they're usually the ones that pay the least and cause the most headaches and they're typically just not worth it.
- tgc1, on 02/20/2008, -0/+2That's why you really need to enforce a deliverables list. If it's not on the list, it's not going to get magically put in later. Unless we renegotiate a contract.
- brundlefly76, on 02/20/2008, -2/+1Feature creep isn't a client problem - its the contractors failure to clearly define expectations.
BScan, on 02/20/2008, -1/+5"Accept that feature creep will happen." - that's something so true :)
Nice tips.
meshman, on 02/20/2008, -13/+3"6. Shed the “Customer is Always Right” mentality."

You're fired. Don't think so? Tell the customer that. You're fired.
- JonnyCasino, on 02/20/2008, -0/+8In Customer Relations, we all know that "the customer is always right." But, I think you missed his point in this section. What I took from it, and from personal experiences, there is a trap when it comes to always wanting to please your clients or customers; moreover, it is a dangerous route to repute yourself as the guy [or gal] who always says "yes". It's simple! IF what your client [internal or external] is suggesting will affect the COST, SCHEDULE, and/or RISK of your project then it needs to be communicated. And sometimes, that will force you to put your foot down for the benefit of your company and your client. Now, there are ways to shed the "Customer is Always Right" mentality by giving the appearance of power to your customers but still stick to your guns in your proposed changed management process. So perhaps accommodating your customers to reach the same satisfying goal means to shed their lack of knowledge that might ultimately jeopardize your reputation, not to mention a possible failure.
- MajorDamage, on 02/20/2008, -0/+5The customer is not always right and they should be told when they are not. It is all in the approach. Give the customer what they need, not what they want.
  In the context of this article, the customer needs functional, profitable software. What they want is to add features galore. This article gives you some ideas on how to break it to them they are not right and to get them what they need.
- BingoPower, on 02/20/2008, -0/+5The client's I deal with expect me to tell them they are wrong if they are, indeed, wrong. Failure to do so means we both know I haven't done my job properly. A good example of this is when you're replacing a client's legacy system (e.g excel/paperwork/etc) with a fully functioning application. They cling to their old policies and paperwork like it was made out of rockinghorse-*****, and you have to guide them out of that mentality, even if they think they're right (why hold on to the old stuff if they're paying for this new-fangled app to save them time and money?)
  
  You obviously haven't been in this business long.
  - RobotBuddha, on 02/20/2008, -0/+3Depends what business it is. I could see it holding for a lot of sales positions. But in long term relationships involving design, it 'will' come back to bite one if he just nods and agrees with statements he knows to be unfeasable.
    - BingoPower, on 02/20/2008, -0/+1Agreed, but the article in question was pretty much specifically software-design. The grinning salesman with a quota is a whole new ballgame.
- link5280, on 02/20/2008, -0/+3You will never finish a project if you allow the customer to continuously add features. You develop requirements and stay within scope, always. If a feature must be added or requirement modified the project must be reevaluated and re-budgeted accordingly, nothing is free. Satisfying the customer is a goal but not at the expense of losing money.
cappslocke, on 02/20/2008, -0/+16From usually being the developer who also has to put on the project management hat often, this article hits it home. You can't prevent feature creep. The client will never know what they want from the get go. Even if they do have a good idea, they can never communicate it to you. You can never create a specs outline detailed enough to cover all possibilities. That's why I always sell an iterative, segmented set of phases to the client so when feature creep sets in, we can push some of that to a proposed phase.
Aidenf77, on 02/20/2008, -0/+6It's helpful when time-lines start to be discussed to use that to your advantage. If features have been talked about, and a time-line has been agreed upon for those features, then drawing upon the agreed upon deliverables always helps to contrast additional "feature creep." In order to provide good client service, it helps to be able to say "yes, we can do that too.... but at x time and at y price." Once the prices start to inflate, that helps to trim the feature creep to exactly what the customer needs; instead of all the things they want. To some clients, the "price" is in the time it takes, more than in the bill they receive at the end of the project. I was just in a meeting yesterday, as the project manager for a new CMS driven web scheduling application, and it's almost like we had two conversations with the client. The first one pertained to what we were agreeing to do and how long we projected that it would take based on those things, and the second one was about all the additional things the client would like to someday see. In this way, the client (usually) can walk away content. The theory goes that if we meet or exceed their expectations for what they need, then we might just score future contracts for what they want.
dylandaring, on 02/20/2008, -6/+118 steps? How about four - K.I.S.S
- liquidpele, on 02/20/2008, -2/+6God I hate digg. Why is this at -3?
  KISS = Keep It Simple Stupid, and is a staple of good engineering practice.
- phoenixx, on 02/20/2008, -1/+3You don't necessarily need to keep it simple. The main way to prevent it is to define (with the client) exactly what scope of the project is and what the finished product "looks like." Then get it in writing so when you're in the middle of the project when the client comes back and says they want more, you can show them that it's outside the definition and will cost them to change at the late stage.
Emnsta, on 02/20/2008, -5/+3Starcraft was a good game
- mGARANDEUR1, on 02/20/2008, -2/+2Yeah it was. This article however is pretty lame.
VTJustinB, on 02/20/2008, -1/+6I really like 37signals thoughts on this. Release early, with what you think is the core of your product. Add features iteratively, and for every one you add think about getting rid of two.

"Features" sell but if you add something without going back and improving the usability/experience of existing features (or removing them entirely) then you serve to fail in the longhaul.
- JonnyCasino, on 02/20/2008, -0/+4It looks like the author of this article DOES subscribe to the 37 signals mantras.
  
  He cites the 37 Signal's “Getting Real” online book as a related link to one of his posts and says 'I subscribe to a lot of their philosophies in terms of developing applications, project management, and keeping it simple.'
  
  Great article!
dijo, on 02/20/2008, -4/+6There's a girl in my office so ugly that we call her feature creep
BingoPower, on 02/20/2008, -1/+4Dugg for being SO ***** TRUE.
lacreme, on 02/20/2008, -2/+6please forgive my ignorance.
wtf is creep?
- leodavinci, on 02/20/2008, -0/+9Feature creep is generally referring to software/IT projects, although I am sure it happens in other fields as well. Once you have signed the contract and done all the planning about what X piece of software will do for your client, you actually get to building it. Once you start building it, everybody and their brother at the client will want their little feature added into the program.
  
  It is just features being wanted that were not initially asked for.
- Darkhacker, on 02/20/2008, -0/+3Creep means to come about in a sly or sneaky way. To "creep up on someone" means to sneak up on them or to be "stealthy".
  
  In this case, "feature creep" is where an application is constantly adding new features to the point where you start including stuff that goes outside the original intention of the application. Feature creep becomes really bad when developers start focusing on new features instead of things like correctness, bugs fixing, usability, and performance. This is why I personally advocate extensions for nearly all applications for features that go outside the original scope.
- centran, on 02/20/2008, -0/+5To put it in everyday terms.... Lets say you hire a plumber to install a kitchen sink. The scope of the project is he will install the sink, facet, and piping necessary.
  Feature creep would be in the middle of the install you decide you want a garbage disposal.
  The reason you want to avoid creep is because even though adding a disposal is pretty simple and has to deal with the sink maybe the client will see how "easy" it was and then want one of those spray heads. Again that is reasonable but then the client might want an instant hot water facet and then maybe connect a dishwasher.... and things start to get way beyond the scope of the project.
- adooga, on 02/20/2008, -0/+2It's explained pretty well in the description, at the top of this very page.
- Slade605, on 02/20/2008, -0/+1I was thinking Starcraft Creep, thanks for clearing my confusion.
Sartic, on 02/20/2008, -5/+2Feature creep?
- bejayel, on 02/20/2008, -0/+1When you start building a program, there are certain features that are set and you should not stray away from. As the project moves on, the client will often want little extra features here and there. Accepting too many of these features is known as feature creep (or my preferred term, scope creep)
- adooga, on 02/20/2008, -0/+1Read the description?
lodibug3, on 02/20/2008, -2/+0Whatever you do... don't show this article to my webmaster! lol... http://www.laplanteenterprises.net
- adooga, on 02/20/2008, -0/+1What the ***** is that site? Dude....
BackdoorBeauty, on 02/20/2008, -0/+3It will be interesting to see how Apple handles feature creep with iTunes. Originally it was a lean app with basic features - buy music and make playlists. They have added tons of new functionality - movies, ring tones, the shuffle feature, mini store window, etc. and their product is slowly becoming more and more complicated.

I consider myself pretty computer saavy and I had to resort to the help menu for something that should have been obvious. If I had to do this several times, imagine how the older baby boom generation just now getting on board iTunes for the first time must feel. Apple needs to be careful not to alienate a large segment of the population with their continuing feature creep.
- RudeTurnip, on 02/20/2008, -0/+1I wouldn't say the movies, ring tones and TV shows were feature creep, just added support for more filetypes. You can hide them from the menu if you want. The shuffle feature...evolution. Podcast support...again, adapting with the times. Mini store window...definitely feature creep. Overall though, it still basically works the same as it first did.
bxblox, on 02/20/2008, -2/+2I dont manage it, i charge for it.
- bejayel, on 02/20/2008, -1/+3You are clearly not a developer as if you were you would know that most projects have deadlines. You have to make it clear to the client that there is only something like 10% of projects that finish by the deadline so requesting too much else will cost them extra. If you dont manage the projects and deny features, then your firm (or you) will be known as unreliable and you will likely end up worse off than before you started
  - bxblox, on 02/20/2008, -0/+2Actually, I am a developer. I was only reffering to very small projects, where the deadline is much more important to the client than it is to me. If they want something extra, sure they can have it, at a later date and at higher cost. I also did not mean it so literally as just throw in a bucketload of extra features at the last minute. I believe clients that are most unsure about what they want or need are usually the ones who do this and are generally unhappy with the results regardless of the outcome. However a few extra features within reason can be doable, its just a matter of "if you want that, it will cost you this and you will get it by this time."
  - permenentwaves, on 02/20/2008, -0/+2That's not always the case. Deadlines are created from an outline of the project. (or should be) Let the client know that feature X being added is outside current specs and will extend this deadline by n amount and they will either agree or not. If the time shift is unacceptable then it goes into the next phase of the project. Using some common sense should let you know when to eat the cost and when to pass it on. But if your specs are laid out properly then you sure as hell can charge for feature creep. And you have clearly only worked in a limited number of places to have such a single minded belief.
seefresh, on 02/20/2008, -0/+4I love feature creep. I can then say "Sure, I'd love to add that, it'll be another 5 hours of work. You will have to pay for it." It basically means you get some more money out of your project.
Reformed, on 02/20/2008, -0/+10Wow, a tech article on Digg. Since when does Digg have technology content?
- nuggetboy, on 02/20/2008, -0/+2Yes, and unfortunately the submitter placed this in "Lifestyle"
sutherbj, on 02/20/2008, -0/+3Ugh, I thought this was a guide on how not to creep out girls... I'm so lonely.
DorranKame, on 02/20/2008, -1/+2Stolen from FreelanceSwitch....
abledragon, on 02/20/2008, -0/+3I totally agree with the fact that 1) the clients often don't know what they want and 2) poor requirements gathering at the outset provides countless problems down the track. Another problem I've come across is 'shoot from the hip' initial scoping of the project. I've been part of projects that were hopelessly underestimated in the first place, putting everyone under completely unnecessary pressure.
LemonDefragger, on 02/20/2008, -1/+1I got excited because I thought this was a way to get rid of facebook addons.
punchinelli, on 02/20/2008, -0/+3Dugg because of the repeat scenarios I have to live through at work that consist of the project manager not having the balls to say "no"..........
ChayD, on 02/20/2008, -1/+19. Tell change requestors "You are wrong. This conversation is over"
cheekybastard, on 02/20/2008, -1/+1Make sure whoever writes the scope of work knows WTF they are doing, get the customer sign off on the SOW. Then discourage feature creep by overcharging for anything outside of the scope of work, because in the long run it will cost you more time and money than its worth.
derekbender, on 02/20/2008, -0/+2GREAT stuff. I need to start charging hourly....oh well, back to work.
ifknot, on 02/20/2008, -1/+1wow it's like web 'developers' are real programmers or something... buried as old, really old.
Ice9NC, on 02/20/2008, -1/+0Your statement of work, the customer signs, should include a cost and contingency for scope creep.
The customer should be aware, any changes to the original SOW will affect the time line of the project.

http://www.openworkbench.org/

http://en.wikipedia.org/wiki/Project_management
creamy, on 02/20/2008, -1/+1I love the way this article really knows how to handle problem solving:

Cause: "It typically happens due to inadequate requirements gathering"

Solution: "2. Commit enough time to requirements-gathering."
bloggeragent001, on 02/21/2008, -1/+0Hey you always get the best articles.
tjsocr1, on 02/29/2008, -0/+0There is also some more good tips at http://www.lamelime.com =)
weetwg01, on 06/14/2008, -0/+1Some tips on tactfully talking to clients when they introduce new features would be helpful.
http://www.collegegraduatesite.com
mhmdkhamis, on 07/13/2008, -0/+0I totally agree with the fact that 1) the clients often don't know what they want and 2) poor requirements gathering at the outset provides countless problems down the track. Another problem I've come across is 'shoot from the hip' initial scoping of the project. I've been part of projects that were hopelessly underestimated in the first place, putting everyone under completely unnecessary pressure

http://xn--mgbaj0ai2l.xn----ymcae0df5a6fo.com
http://xn--mgbajgnm.xn----ymcae0df5a6fo.com
http://xn--mgbb5aye.xn----ymcae0df5a6fo.com
http://xn--mgbbb9azi.xn----ymcae0df5a6fo.com
Login or register to add a comment

Create a new account or login to join in the conversation on Digg. You'll also be able to Digg stories to help promote things you like.

How To Manage Feature Creep: 8 Simple Tips

Login or register to add a comment