Okay, I swear I am not new to this but it gets me every time.<p>1. Client gives requirements for software, we quote a price (hourly, not fixed price) to complete it.<p>2. Client comes back with requirements that are not in scope (were listed nowhere nor mentioned anytime earlier) and only thought they would be done because ... well, he needs/wants them and assumed we'd know that because they are so important.<p>I know we are in the right, both contractually and ethically, but that all matters little if you have a really pissed off client. Okay, so what are your tips for dealing with this situation?<p>The best combat may be to just bloat your estimates - like A LOT - but technically we already do this just to handle give within KNOWN scope so this would be even more. Plus it's not always an option when other people are estimating/trying to be competitive. And I'm dealing with a situation now where he'd pretty much blow past any reasonable buffer anyways.<p>Anyways, maybe it's just always a sucky situation but I'd appreciate any tips/tricks/advice/support/encouragement my fellow HNers can share.<p>Thanks!
I suggest that your client's apparent anger is nothing more than a negotiation tactic - whether they are consciously aware of this or not.<p>If you have agreed a list of requirements and a price, and you have this written down and signed off by both parties, then you should stick to your guns. Giving in to your client's demands will most likely lead to them asking for more and more things not in the original list. They will simply stomp all over you.<p>When I worked freelance I included a clause that said something along the lines of: "Any additional work required that is not included in this document will be quoted for on a new project basis."<p>I made sure I charged at quite a higher rate than I had done for the original quote, due to the extra effort involved in ensuring that the new request(s) didn't break functionality elsewhere or result in me having to refactor significant portions of code.
It is called managing expectations, and it requires communication, communication, communication.<p>You may have the contract on your side, but in the end, building a successful freelance practice depends heavily on repeat business, so it is up to you, the expert on the subject, to bring this issues up early enough and make sure they actually understand what you are talking about.<p>(I feel your pain)
This is a terribly common refrain. Perhaps all freelance developers in a given area should collaborate (read: collude) and come up with an agreed upon, open source scope of work document framework? That way, setting aside variables like price, feature requests, and time estimates, there can at least be a common structure that developers in a particular geography can rally around to at least attempt to minimize the impact of this type of problem.<p>This is the precise reason why I am trying my best to come up with my next start up idea, client work is a drain...
i would try to cut scope on other items or at least compare the value of this item to other items. To do this you need a deep understanding of the core value of the app and how each feature contributes to the value.<p>Ultimately tell him your bid is based on hours and you are fine to switch things around.
It depends on what the new stuff involves. If it's details on already-decided features, just tell them "well that's going to take some more hours than already estimated," and if it's for things that are out of scope (design is a common one), just say, "that'll be extra." Have a sense of the scope and don't be afraid to tell them that will cost more. You should be able to explain the scope as you understand it and why the request falls outside of it. If you treat the agreed-spec like a checklist, it makes it much easier to clarify the amount of work you'll be doing.
You should reply to the clients when you provide the original quote with a very succinct summary/bullet list of what is being provided - SUPER SUCCINCT. and get them to sing-off on <i>that</i><p>So if they come back with anything, and it is not boiled down into the bullet item list of features - its additional service request.<p>This might help them to further think about their product.<p>One thing that always pisses me off when getting a quote from a developer is when they say some large number of hours are required for some nebulous task.<p>"Setup development environment: 40 hours"<p>or something similar.<p>shouldn't your development environment be setup? or streamlined such to not require 40 hours?<p>so, make sure you reply to them with a super succinct understanding of what is to be delivered and this will be the go-to document for any discussion about scope.