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 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!
35 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.
Leave a Comment