

How do you tell nicely tell someone their requests are not in scope? - AmberShah

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!
======
arctangent
I suggest that your client's apparent anger is nothing more than a negotiation
tactic - whether they are consciously aware of this or not.

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.

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."

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.

~~~
AmberShah
This is sort of what happened when they asked for the new features, we
responded with estimates for that work and explained why it wasn't included
... they got pretty upset. Implied WE were the ones playing a game or
something, when of course, from our end this is just totally straightforward.

------
clueless123
It is called managing expectations, and it requires communication,
communication, communication.

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.

(I feel your pain)

------
swalkergibson
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.

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...

------
nametoremember
You could increase your price or you could agree to get what was originally
planned done first and then look at the new extra stuff.

~~~
AmberShah
Well, the problem is that they insist on neither: that both the price stay the
same and that the extra stuff is required. Rock - Me - Hard place.

BUT I do feel bad in these cases because I believe they thought it would be
included. Plus it may truly be necessary for the final product to be useful
for them. So I want to help them, plus, ya know, don't want them pissed at me
:)

~~~
masterzora
Personally, I'd say you just apologise for misunderstanding their intentions,
politely inform them that the new feature is going to cost extra, and then
suggest that, due to the misunderstanding, you're going to reduce your price
for that implementation to $X, where $X is either the price you actually have
in mind (if you don't mind being less than 100% truthful for the sake of
fairness) or a slightly lower price (if you're willing to pay for their
mistake so as to maintain more truthfulness). Yes, it can be hard to admit to
mistakes you didn't actually make, but it's often necessary to not piss off
some people.

------
triviatise
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.

Ultimately tell him your bid is based on hours and you are fine to switch
things around.

------
rhizome
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.

------
phlux
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 _that_

So if they come back with anything, and it is not boiled down into the bullet
item list of features - its additional service request.

This might help them to further think about their product.

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.

"Setup development environment: 40 hours"

or something similar.

shouldn't your development environment be setup? or streamlined such to not
require 40 hours?

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.

~~~
AmberShah
This is good advice, and I think that's what went wrong in this case. We were
told to estimate based on what we had, even though we needed to go deeper. The
rationale was that we couldn't put so much time into a proposal that was so
small. And on a smaller project, more risk was acceptable, which is okay, I
guess, but then this is what happens.

"Setup development environment: 40 hours"

This is ridiculous, though, well UNLESS you are hiring someone to pick up work
on a large existing project, in which case they may actually need the time to
get all the dependencies and get it running. To be clear, our items are always
in chunks of actual functionality, because this makes the most sense to ...
well, everyone. And it makes it easier for them to pick and choose/set
priorities/etc.

------
LilValleyBigEgo
You should take a class in project management.

Seriously. It will help a lot with this type of situation.

