Dealing with clients who want more than what's in the contract

Clash Royale CLAN TAG#URR8PPP

.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;

up vote
31
down vote

favorite

8

We have a client with whom we have a contract. The contract scope is very clear and well defined. One day, one of the guys in the client company called and said, "hey, it would be great if you could add feature X to the project!". Feature X was something completely new, imagined by the guys at the client company, and it was nothing trivial to do. By my estimates, it would require 10% more work than the original efforts. By staff's estimates, which are more accurate than mine most of the time, it would be 30% more work.

At the very moment of the call I just said "it's out of the scope of this project. We can talk about it after we're done with the first project." To what guy at client said "ok".

Then came an email from this guy. The tone was something akin to "about that feature we talked about - we think it's going to add a lot of value to the project you guys are undertaking." It was CC'ed to his boss, and his boss's boss. A chain of emails began amongst them, all talking about this feature. I politely sent an email explaining that it would add time and materials to the original estimates, and that we would have to bring more people into the project - all of which involves costs. Also it couldn't be started until the current project is finished, so it should be a separate, follow up project.

Days pass, and we have a meeting. And yes, the hierarchy was all there: guy, guy's boss, and guy's boss's boss were all there. We discussed project status, schedules, support etc. Then guy mentions feature X again.

"As I said in the email", I said, "that would take more time to do, and add extra costs".

"How much extra are we talking about here?", said guy. To which I answered: "45%" (yeah more than staff's estimates, but the plan was to negotiate, with them offering less than 30%, and we eventualy agreeing on that).

"Woa, wait a minute", said guy, "that's a bit over the top... we've already spent a lot of money on that project!" At this moment, guy's immediate boss got into the conversation: "we strongly feel that feature X is necessary for us to consider the project complete. Without feature X, the project is rendered useless."

And then the top boss: "now I know you want to negotiate on this, but I feel this contract is very expensive already. Surely you should add this feature to the current scope, as a courtesy. You can agree to go just a little beyond the contract..."

I was as polite as I can be, but the thing only went downhill from there. They are furious that we are not going to do on the cheap a feature that their guy invented and sold internally. One of my competitors (who is also a personal friend) told me that he was contacted by client company, who wanted "this feature X, but they have a very tight budget for that and our price was 6x more than they were willing to pay".

I think the client will either be missing that feature, or in the end they'll agree to our price (or one of our competitors' prices). I really don't care about getting this job or not, though I do care about the current project being executed to more than perfection.

But how do you kill this problem by the root? This kind of attitude ("come on, just a little more, you don't have to stick to the paper on this") is quite common here. And in case of pissed off clients, how do you do damage control?

clients contracting contract-extension

share|improve this question

edited Oct 29 '13 at 4:17

asked Oct 28 '13 at 16:30

user10483

• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  @JoeStrazzere Did too. But everything is "critical" (their opinion. IMO half of the project is for show, to appease their stakeholders).
  – user10483
  Oct 28 '13 at 16:45
  

  
  
  
  


• 
  
  
  

  
  9
  

  
  
  
  
  
  

  
  If you try to compromise on scope and they get heated then it is clear they are trying to bully free work out of you. I personally have a less than 0 tolerance for this and will make it clear that the next step is my offering to turn in all work thus far and walking away from any pending and future payments. It usually costs far less in the long run than taking on this client for the long term. Just be polite and don't make the client feel stupid about coming back to you if you decide to terminate early. They will sometimes think you are bluffing.
  – maple_shaft
  Oct 29 '13 at 11:41
  

  
  
  
  


• 
  
  
  

  
  4
  

  
  
  
  
  
  

  
  I dont mean to be offensive/rude, but if you don't (yet) have a scope change strategy/policy in place - making software will be a very difficult challenge for you guys. I have barely worked on any project whose scope never changed.
  – happybuddha
  Oct 29 '13 at 17:05
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  @happybuddha this is not a software project, but being a programmer myself I can see how the idea can be applied. That policy is going to be in my contracts from now on.
  – user10483
  Oct 29 '13 at 17:17
  

  
  
  
  


• 
  
  
  

  
  4
  

  
  
  
  
  
  

  
  This question appears to be off-topic because it is about running your business not navigating the workplace. This might be better suited for On Startups or some other Business SE
  – IDrinkandIKnowThings
  Oct 31 '13 at 15:47
  

  
  
  
  

 | 
show 2 more comments

up vote
31
down vote

favorite

8

We have a client with whom we have a contract. The contract scope is very clear and well defined. One day, one of the guys in the client company called and said, "hey, it would be great if you could add feature X to the project!". Feature X was something completely new, imagined by the guys at the client company, and it was nothing trivial to do. By my estimates, it would require 10% more work than the original efforts. By staff's estimates, which are more accurate than mine most of the time, it would be 30% more work.

At the very moment of the call I just said "it's out of the scope of this project. We can talk about it after we're done with the first project." To what guy at client said "ok".

Then came an email from this guy. The tone was something akin to "about that feature we talked about - we think it's going to add a lot of value to the project you guys are undertaking." It was CC'ed to his boss, and his boss's boss. A chain of emails began amongst them, all talking about this feature. I politely sent an email explaining that it would add time and materials to the original estimates, and that we would have to bring more people into the project - all of which involves costs. Also it couldn't be started until the current project is finished, so it should be a separate, follow up project.

Days pass, and we have a meeting. And yes, the hierarchy was all there: guy, guy's boss, and guy's boss's boss were all there. We discussed project status, schedules, support etc. Then guy mentions feature X again.

"As I said in the email", I said, "that would take more time to do, and add extra costs".

"How much extra are we talking about here?", said guy. To which I answered: "45%" (yeah more than staff's estimates, but the plan was to negotiate, with them offering less than 30%, and we eventualy agreeing on that).

"Woa, wait a minute", said guy, "that's a bit over the top... we've already spent a lot of money on that project!" At this moment, guy's immediate boss got into the conversation: "we strongly feel that feature X is necessary for us to consider the project complete. Without feature X, the project is rendered useless."

And then the top boss: "now I know you want to negotiate on this, but I feel this contract is very expensive already. Surely you should add this feature to the current scope, as a courtesy. You can agree to go just a little beyond the contract..."

I was as polite as I can be, but the thing only went downhill from there. They are furious that we are not going to do on the cheap a feature that their guy invented and sold internally. One of my competitors (who is also a personal friend) told me that he was contacted by client company, who wanted "this feature X, but they have a very tight budget for that and our price was 6x more than they were willing to pay".

I think the client will either be missing that feature, or in the end they'll agree to our price (or one of our competitors' prices). I really don't care about getting this job or not, though I do care about the current project being executed to more than perfection.

But how do you kill this problem by the root? This kind of attitude ("come on, just a little more, you don't have to stick to the paper on this") is quite common here. And in case of pissed off clients, how do you do damage control?

clients contracting contract-extension

share|improve this question

edited Oct 29 '13 at 4:17

asked Oct 28 '13 at 16:30

user10483

• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  @JoeStrazzere Did too. But everything is "critical" (their opinion. IMO half of the project is for show, to appease their stakeholders).
  – user10483
  Oct 28 '13 at 16:45
  

  
  
  
  


• 
  
  
  

  
  9
  

  
  
  
  
  
  

  
  If you try to compromise on scope and they get heated then it is clear they are trying to bully free work out of you. I personally have a less than 0 tolerance for this and will make it clear that the next step is my offering to turn in all work thus far and walking away from any pending and future payments. It usually costs far less in the long run than taking on this client for the long term. Just be polite and don't make the client feel stupid about coming back to you if you decide to terminate early. They will sometimes think you are bluffing.
  – maple_shaft
  Oct 29 '13 at 11:41
  

  
  
  
  


• 
  
  
  

  
  4
  

  
  
  
  
  
  

  
  I dont mean to be offensive/rude, but if you don't (yet) have a scope change strategy/policy in place - making software will be a very difficult challenge for you guys. I have barely worked on any project whose scope never changed.
  – happybuddha
  Oct 29 '13 at 17:05
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  @happybuddha this is not a software project, but being a programmer myself I can see how the idea can be applied. That policy is going to be in my contracts from now on.
  – user10483
  Oct 29 '13 at 17:17
  

  
  
  
  


• 
  
  
  

  
  4
  

  
  
  
  
  
  

  
  This question appears to be off-topic because it is about running your business not navigating the workplace. This might be better suited for On Startups or some other Business SE
  – IDrinkandIKnowThings
  Oct 31 '13 at 15:47
  

  
  
  
  

 | 
show 2 more comments

up vote
31
down vote

favorite

8

up vote
31
down vote

favorite

8

8

We have a client with whom we have a contract. The contract scope is very clear and well defined. One day, one of the guys in the client company called and said, "hey, it would be great if you could add feature X to the project!". Feature X was something completely new, imagined by the guys at the client company, and it was nothing trivial to do. By my estimates, it would require 10% more work than the original efforts. By staff's estimates, which are more accurate than mine most of the time, it would be 30% more work.

At the very moment of the call I just said "it's out of the scope of this project. We can talk about it after we're done with the first project." To what guy at client said "ok".

Then came an email from this guy. The tone was something akin to "about that feature we talked about - we think it's going to add a lot of value to the project you guys are undertaking." It was CC'ed to his boss, and his boss's boss. A chain of emails began amongst them, all talking about this feature. I politely sent an email explaining that it would add time and materials to the original estimates, and that we would have to bring more people into the project - all of which involves costs. Also it couldn't be started until the current project is finished, so it should be a separate, follow up project.

Days pass, and we have a meeting. And yes, the hierarchy was all there: guy, guy's boss, and guy's boss's boss were all there. We discussed project status, schedules, support etc. Then guy mentions feature X again.

"As I said in the email", I said, "that would take more time to do, and add extra costs".

"How much extra are we talking about here?", said guy. To which I answered: "45%" (yeah more than staff's estimates, but the plan was to negotiate, with them offering less than 30%, and we eventualy agreeing on that).

"Woa, wait a minute", said guy, "that's a bit over the top... we've already spent a lot of money on that project!" At this moment, guy's immediate boss got into the conversation: "we strongly feel that feature X is necessary for us to consider the project complete. Without feature X, the project is rendered useless."

And then the top boss: "now I know you want to negotiate on this, but I feel this contract is very expensive already. Surely you should add this feature to the current scope, as a courtesy. You can agree to go just a little beyond the contract..."

I was as polite as I can be, but the thing only went downhill from there. They are furious that we are not going to do on the cheap a feature that their guy invented and sold internally. One of my competitors (who is also a personal friend) told me that he was contacted by client company, who wanted "this feature X, but they have a very tight budget for that and our price was 6x more than they were willing to pay".

I think the client will either be missing that feature, or in the end they'll agree to our price (or one of our competitors' prices). I really don't care about getting this job or not, though I do care about the current project being executed to more than perfection.

But how do you kill this problem by the root? This kind of attitude ("come on, just a little more, you don't have to stick to the paper on this") is quite common here. And in case of pissed off clients, how do you do damage control?

clients contracting contract-extension

share|improve this question

edited Oct 29 '13 at 4:17

asked Oct 28 '13 at 16:30

user10483

We have a client with whom we have a contract. The contract scope is very clear and well defined. One day, one of the guys in the client company called and said, "hey, it would be great if you could add feature X to the project!". Feature X was something completely new, imagined by the guys at the client company, and it was nothing trivial to do. By my estimates, it would require 10% more work than the original efforts. By staff's estimates, which are more accurate than mine most of the time, it would be 30% more work.

At the very moment of the call I just said "it's out of the scope of this project. We can talk about it after we're done with the first project." To what guy at client said "ok".

Then came an email from this guy. The tone was something akin to "about that feature we talked about - we think it's going to add a lot of value to the project you guys are undertaking." It was CC'ed to his boss, and his boss's boss. A chain of emails began amongst them, all talking about this feature. I politely sent an email explaining that it would add time and materials to the original estimates, and that we would have to bring more people into the project - all of which involves costs. Also it couldn't be started until the current project is finished, so it should be a separate, follow up project.

Days pass, and we have a meeting. And yes, the hierarchy was all there: guy, guy's boss, and guy's boss's boss were all there. We discussed project status, schedules, support etc. Then guy mentions feature X again.

"As I said in the email", I said, "that would take more time to do, and add extra costs".

"How much extra are we talking about here?", said guy. To which I answered: "45%" (yeah more than staff's estimates, but the plan was to negotiate, with them offering less than 30%, and we eventualy agreeing on that).

"Woa, wait a minute", said guy, "that's a bit over the top... we've already spent a lot of money on that project!" At this moment, guy's immediate boss got into the conversation: "we strongly feel that feature X is necessary for us to consider the project complete. Without feature X, the project is rendered useless."

And then the top boss: "now I know you want to negotiate on this, but I feel this contract is very expensive already. Surely you should add this feature to the current scope, as a courtesy. You can agree to go just a little beyond the contract..."

I was as polite as I can be, but the thing only went downhill from there. They are furious that we are not going to do on the cheap a feature that their guy invented and sold internally. One of my competitors (who is also a personal friend) told me that he was contacted by client company, who wanted "this feature X, but they have a very tight budget for that and our price was 6x more than they were willing to pay".

I think the client will either be missing that feature, or in the end they'll agree to our price (or one of our competitors' prices). I really don't care about getting this job or not, though I do care about the current project being executed to more than perfection.

But how do you kill this problem by the root? This kind of attitude ("come on, just a little more, you don't have to stick to the paper on this") is quite common here. And in case of pissed off clients, how do you do damage control?

clients contracting contract-extension

share|improve this question

edited Oct 29 '13 at 4:17

asked Oct 28 '13 at 16:30

user10483

share|improve this question

share|improve this question

edited Oct 29 '13 at 4:17

edited Oct 29 '13 at 4:17

edited Oct 29 '13 at 4:17

asked Oct 28 '13 at 16:30

user10483

asked Oct 28 '13 at 16:30

user10483

asked Oct 28 '13 at 16:30

user10483

• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  @JoeStrazzere Did too. But everything is "critical" (their opinion. IMO half of the project is for show, to appease their stakeholders).
  – user10483
  Oct 28 '13 at 16:45
  

  
  
  
  


• 
  
  
  

  
  9
  

  
  
  
  
  
  

  
  If you try to compromise on scope and they get heated then it is clear they are trying to bully free work out of you. I personally have a less than 0 tolerance for this and will make it clear that the next step is my offering to turn in all work thus far and walking away from any pending and future payments. It usually costs far less in the long run than taking on this client for the long term. Just be polite and don't make the client feel stupid about coming back to you if you decide to terminate early. They will sometimes think you are bluffing.
  – maple_shaft
  Oct 29 '13 at 11:41
  

  
  
  
  


• 
  
  
  

  
  4
  

  
  
  
  
  
  

  
  I dont mean to be offensive/rude, but if you don't (yet) have a scope change strategy/policy in place - making software will be a very difficult challenge for you guys. I have barely worked on any project whose scope never changed.
  – happybuddha
  Oct 29 '13 at 17:05
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  @happybuddha this is not a software project, but being a programmer myself I can see how the idea can be applied. That policy is going to be in my contracts from now on.
  – user10483
  Oct 29 '13 at 17:17
  

  
  
  
  


• 
  
  
  

  
  4
  

  
  
  
  
  
  

  
  This question appears to be off-topic because it is about running your business not navigating the workplace. This might be better suited for On Startups or some other Business SE
  – IDrinkandIKnowThings
  Oct 31 '13 at 15:47
  

  
  
  
  

 | 
show 2 more comments

• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  @JoeStrazzere Did too. But everything is "critical" (their opinion. IMO half of the project is for show, to appease their stakeholders).
  – user10483
  Oct 28 '13 at 16:45
  

  
  
  
  


• 
  
  
  

  
  9
  

  
  
  
  
  
  

  
  If you try to compromise on scope and they get heated then it is clear they are trying to bully free work out of you. I personally have a less than 0 tolerance for this and will make it clear that the next step is my offering to turn in all work thus far and walking away from any pending and future payments. It usually costs far less in the long run than taking on this client for the long term. Just be polite and don't make the client feel stupid about coming back to you if you decide to terminate early. They will sometimes think you are bluffing.
  – maple_shaft
  Oct 29 '13 at 11:41
  

  
  
  
  


• 
  
  
  

  
  4
  

  
  
  
  
  
  

  
  I dont mean to be offensive/rude, but if you don't (yet) have a scope change strategy/policy in place - making software will be a very difficult challenge for you guys. I have barely worked on any project whose scope never changed.
  – happybuddha
  Oct 29 '13 at 17:05
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  @happybuddha this is not a software project, but being a programmer myself I can see how the idea can be applied. That policy is going to be in my contracts from now on.
  – user10483
  Oct 29 '13 at 17:17
  

  
  
  
  


• 
  
  
  

  
  4
  

  
  
  
  
  
  

  
  This question appears to be off-topic because it is about running your business not navigating the workplace. This might be better suited for On Startups or some other Business SE
  – IDrinkandIKnowThings
  Oct 31 '13 at 15:47
  

  
  
  
  

1

1

@JoeStrazzere Did too. But everything is "critical" (their opinion. IMO half of the project is for show, to appease their stakeholders).
– user10483
Oct 28 '13 at 16:45

@JoeStrazzere Did too. But everything is "critical" (their opinion. IMO half of the project is for show, to appease their stakeholders).
– user10483
Oct 28 '13 at 16:45

9

9

If you try to compromise on scope and they get heated then it is clear they are trying to bully free work out of you. I personally have a less than 0 tolerance for this and will make it clear that the next step is my offering to turn in all work thus far and walking away from any pending and future payments. It usually costs far less in the long run than taking on this client for the long term. Just be polite and don't make the client feel stupid about coming back to you if you decide to terminate early. They will sometimes think you are bluffing.
– maple_shaft
Oct 29 '13 at 11:41

If you try to compromise on scope and they get heated then it is clear they are trying to bully free work out of you. I personally have a less than 0 tolerance for this and will make it clear that the next step is my offering to turn in all work thus far and walking away from any pending and future payments. It usually costs far less in the long run than taking on this client for the long term. Just be polite and don't make the client feel stupid about coming back to you if you decide to terminate early. They will sometimes think you are bluffing.
– maple_shaft
Oct 29 '13 at 11:41

4

4

I dont mean to be offensive/rude, but if you don't (yet) have a scope change strategy/policy in place - making software will be a very difficult challenge for you guys. I have barely worked on any project whose scope never changed.
– happybuddha
Oct 29 '13 at 17:05

I dont mean to be offensive/rude, but if you don't (yet) have a scope change strategy/policy in place - making software will be a very difficult challenge for you guys. I have barely worked on any project whose scope never changed.
– happybuddha
Oct 29 '13 at 17:05

@happybuddha this is not a software project, but being a programmer myself I can see how the idea can be applied. That policy is going to be in my contracts from now on.
– user10483
Oct 29 '13 at 17:17

@happybuddha this is not a software project, but being a programmer myself I can see how the idea can be applied. That policy is going to be in my contracts from now on.
– user10483
Oct 29 '13 at 17:17

4

4

This question appears to be off-topic because it is about running your business not navigating the workplace. This might be better suited for On Startups or some other Business SE
– IDrinkandIKnowThings
Oct 31 '13 at 15:47

This question appears to be off-topic because it is about running your business not navigating the workplace. This might be better suited for On Startups or some other Business SE
– IDrinkandIKnowThings
Oct 31 '13 at 15:47

 | 
show 2 more comments

4 Answers
4

active

oldest

votes

up vote
14
down vote



accepted

Remember, if the pirates get away with the first ship, they're more likely to try again on another. You really have to stand your ground. The alternative is you lose control of the project, and eventually everyone is miserable. The 'fixed price, fixed deliverable' software job is usually a mistake, for precisely this reason.

Imagine the surgeon is about to put you under, and he's telling you 'We'll get you out of here on schedule and on budget'. The minor detail left unclear is whether you'll be alive. It appears that your client doesn't understand the role of software in a business. To the extent that that is true, they then don't understand what getting good software costs. It would appear, at this point, they're in over their heads as much as you are - they can't afford what they want, although they can probably afford what you've promised to do.

Probably the most politically viable path under the circumstance is finish the project, turn it in, collect your money, and move on. This is the right approach if they are adamant about the budget - give them what they originally agreed to, nothing more, and nothing less. If they're showing signs of being unhappy, discontinue any working relationship beyond that point.

If there is a situation where this is leading to a breakdown in trust, it would make sense to come to an early termination agreement, wrap up loose ends, give them the deliverables you have, and liquidate the contract. Don't bother with spec revisions and a rebid. Let them find another provider. Do not, however, 'lock up' anything. Give them what you've done and what they've paid for so far. If there is no payment yet, consider walking away, gracefully (i.e., with mutual agreement) if possible.

The best approach is to convert the agreement to a time and materials basis and run it as an agile development cycle. In short, instead of a 'fixed price, fixed deliverable', it will be structured with 'milestones'. Subsequent phases are based on 'lessons learned', or evolving requirements. Customer feedback will be encouraged during each development cycle. If you have to meter the work out more slowly to keep the project within their current budget, come to some understanding of how to redeploy your developers so that progress is optimum given the constraints.

If at all possible, convene another meeting with all the higher ups, present some case histories of situations where things like this happened (they're easy to find, including the Big One - Obamacare), and how they ended. If you can find a story that isn't full of fights and lawsuits, see if you can show them the right way forward.

share|improve this answer

answered Oct 29 '13 at 4:32

Meredith Poor

8,8661730

• 
  
  
  

  
  5
  

  
  
  
  
  
  

  
  Selling agile to your client is sometimes a hard thing to do, since the way accounting and budgets typically work don't tend to look favorably on projects without a definite end date and that are constantly ongoing without an end in sight. Other clients are simply sleazy and predatory and don't like Agile on the grounds that they have far less room for bullying and manipulative behavior.
  – maple_shaft
  Oct 29 '13 at 11:26
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  I agree that the OP must stand their ground; however I disagree with "fixed scope, fixed deliverable" being a problem in general. Nor do I think switching to T&M will fix the client relations. If the client has poor internal management or a very fixed budget, then T&M billing is a bad idea as T&M generally leads to cost overruns; which would be a project failure.
  – NotMe
  Jul 25 '14 at 16:00
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  Short, timeboxed sprints are the way to go. In my experience, most clients seem to like them as they get visibility and control. They can say "we spent X and got an MVP proof of concept". Then later: "we spent X and got features Y and Q which we thought were most critical". I've always found it an easy sell.
  – superluminary
  Apr 26 '16 at 11:55
  

  
  
  
  

add a comment | 

up vote
14
down vote

But how do you kill this problem by the root?

You don't get rid of it completely. A way to get close is to have someone on the receiving end who has "been there" in development of whatever you are contracted to do. If you are negotiating with a software developer while working a software dev project, they will understand somewhat the increases in work associated with changing requirements.

What you need to do:

1. Have project scope discussions and documentation at the beginning of projects. Make sure to get buy-in from your stakeholders and agreement from both sides what is being created.


2. For paid contracts, have a "change process" - don't leave this unaddressed. If you specify in advance what happens when features change or additional features are requested, then you can point back to a document both parties agreed on


3. When additional requests do come (not if), pick your battles wisely... don't just reject all of them.


4. If you have to reject them or charge for them, make sure the client knows why. "This feature would require rearchitecting the main part of the database model, which would be significant work." People don't like their ideas being rejected for no reason. But put a justification to it. Depending on where you are at in the process, consider using an analogy.

A great way to describe scope creep's effect on people unfamiliar with your topic is through a house. Describe the project in terms of building a house - you have to get the design done, then you start building a room. The further you go in the process the more complicated it is to add another room. Adding a 30% feature is the same as repainting and recarpeting the entire house.

The further removed the stakeholders are from the actual implementation/project work, the more important it is to discuss things in analogies and providing explanations as to why it would result in enough additional work to your stakeholders. They might think, "it's only a few min of work COME ON" when it is 100 hours of work (or vice versa).

"it's out of the scope of this project. We can talk about it after we're done with the first project."

Change this to something more like:

• "Well, we can look at it, but right now it'd be a fairly large change to the scope of the project. I can talk with my team and see what they would estimate this would take to implement. Do you want us to investigate what it would take to get your request added to the scope of the project? Can you detail your request a bit more so we can get a more accurate estimate?"

---

Additionally, if you encounter this problem frequently it may benefit you to take some training in negotiation. Each of these requests results in a mini-negotiation.

share|improve this answer

edited Oct 28 '13 at 21:22

answered Oct 28 '13 at 18:13

Elysian Fields♦

96.9k46292449

add a comment | 

up vote
11
down vote

Executive Summary

You ultimately have three choices:

1. Concede the additional work for free


2. Concede the additional work in exchange for something


3. Refuse to take on the additional work and stick to the contract

Deciding which choice to make depends on your evaluation of the business impact of each in a best case/worst case scenario, and taking a risk appropriate to your business.

In the future, you should take care to prevent this sort of thing from happening.

Concede the Additional Work for Free

This has very little upside, but if it is the only way to get money from the client, it may be the only appropriate choice. You need to determine if that's the case.

If this client is important, or if there is a chance they will cancel the entire project and you wouldn't have the resources to recover costs, you may want to consider just giving the feature for free. At the end of the day, an unhappy client may cause more harm than the added cost of implementing the feature.

Trade the Feature for Something Else

If the customer is not essential to the well-being of your business, and you want to take a harder stance against their demands, you can try asking for something else. You do not have to ask for full-value of the additional feature if you are worried that would make them walk away, so use your best judgment to figure out what you can get.

In exchange for this feature you could ask for:

1. A reduction in other features/work


2. An increase in payment


3. Other concessions

Reduction in Other Features/Work

If you have a list of what features and how much time they require, you can add the new feature and show how it would impact other features they have asked for. If you are confident in the amount of work required for each portion, you can negotiate which parts they want to trade the new feature for. This requires that you have firm estimates you can justify to the customer, and runs the risk that they will start attacking your estimates of effort for other portions (especially if they are already complaining about the current contract price).

Increase in Payment

If you can create a firm estimate for the cost of developing, testing, and implementing this additional feature, you can create two separate estimates for the customer:

1. Including the feature to be packaged with the original promised deliverables


2. Including the feature after the original promised deliverables

Giving the customer an idea of how much of an added burden this is to add will make it more likely that they will take the cheaper option (and be grateful), or decide to scrap the feature due to the added cost.

Other Concessions

If this product will require maintenance or after-service in some way, you can negotiate to include this feature in exchange for a service contract paying you X for the next Y months to maintain it. Or if there is other future business that this company will need services like yours for, you can negotiate to have the exclusive right to negotiate (in good faith) for the next project.

Refuse to Take the Additional Work

If you are concerned the customer may abuse any goodwill or shifting of goalposts, even at additional price, then you can simply refuse and refer to the contract. If you do stick to this, be sure to consult a lawyer to see what (if any) potential pitfalls there could be if you stick to the letter of the law, just so you can be sure you get paid.

This has a good chance of making the client unhappy as it suggests you are not willing to meet their needs, but sometimes the best thing to do with a difficult client is to do as little business with them as possible.

An Ounce of Prevention...

Unfortunately, asking for things beyond the scope of the original negotiated contract is quite normal in many cultures/industries. There are many things you can do to try to plan for these changes, and otherwise minimize their impact when they do come up. These solutions are not mutually-exclusive.

Create Detailed Specifications

For large engineering projects, for instance, every single drawing of every single part of the project needs to be initialed and agreed to by the purchaser. By having the customer agree to the detailed design beforehand, it becomes much more difficult to say, "Yes, but I really wanted..."

Negotiate with the Decision-Maker

When you negotiate a contract, negotiate with the person signing the checks. If you don't, the person you negotiate with could just ask their boss to rubber-stamp it, and may even promise the boss that the contract says something that it doesn't to make sure they get it signed (assuming they can negotiate later with the support of their boss).

Add Language to the Contract Handling Changes

Make sure that your contract has language explaining how changes will be handled. I am not a lawyer, but in plain English, a clause that says something like (have a lawyer make it legal):

Changes

The price in this contract is for the work described in Section X. If a change from Section X in scope or schedule is required, the purchaser must provide notice including a detailed description in writing of the proposed changes to the contractor. Upon receipt of such notice, the contractor will provide a response within Y days explaining:

1. Reason for refusal; or


2. Adjusted Price and Schedule for the changes

The contractor is under no obligation to accept any change in scope from this contract. If an estimate is provided, parties will negotiate in good faith to come to a decision to revise this contract based on the changed scope, or to negotiate a separate contract as appropriate.

This will clearly say to the customer, "This agreement is full and complete, and if you want something else, you have to negotiate for it." This goes hand-in-hand with having detailed specifications so that all parties are clear on the scope and schedule of the project.

Estimate Contingency

Depending on your industry and how competitive bids are, you can differentiate yourself by estimating a certain amount of contingency to your costs so that when something comes up, you can say, "We would be happy to do that" without compromising your bottom line. This will make your initial price higher, but it will also give you more flexibility to compromise on certain aspects, which may be easier for some of your customers than getting additional payment after the fact.

Get a Salesman

A good salesperson will check up on customers, and catch some of these problems before they escalate. Depending on the size of your business and the number of clients, you may want to consider getting a salaried salesman (who is primarily salaried rather than paid on commission). If you have several contracts, and you are doing 20% extra work on a team of 10 because of these sorts of requests, even if he only cuts that down to 10% he is paying his own salary (assuming you pay as much as the developers).

share|improve this answer

answered Oct 29 '13 at 1:18

jmac

19.4k763137

add a comment | 

up vote
2
down vote

I mentioned F*** you, pay me, in a comment but essentially this should be covered in your contract.

If it isn't now, it needs to be. You are a professional, and your time is valuable. People like this are sending a very clear message - they do not respect you as a professional or value your time. Sometimes they are in fact terrible people, other times they just want to see what they can get. Based on your side of the story, it sounds like they're the terrible version.

share|improve this answer

answered Oct 29 '13 at 17:39

Wayne Werner

64059

add a comment | 

Your Answer

StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "423"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
convertImagesToLinks: false,
noModals: false,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
noCode: true, onDemand: false,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);

 

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name Email

StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fworkplace.stackexchange.com%2fquestions%2f15341%2fdealing-with-clients-who-want-more-than-whats-in-the-contract%23new-answer', 'question_page');

);

Post as a guest

Name Email

StackExchange.ready(function ()
$("#show-editor-button input, #show-editor-button button").click(function ()
var showEditor = function()
$("#show-editor-button").hide();
$("#post-form").removeClass("dno");
StackExchange.editor.finallyInit();
;

var useFancy = $(this).data('confirm-use-fancy');
if(useFancy == 'True')
var popupTitle = $(this).data('confirm-fancy-title');
var popupBody = $(this).data('confirm-fancy-body');
var popupAccept = $(this).data('confirm-fancy-accept-button');

$(this).loadPopup(
url: '/post/self-answer-popup',
loaded: function(popup)
var pTitle = $(popup).find('h2');
var pBody = $(popup).find('.popup-body');
var pSubmit = $(popup).find('.popup-submit');

pTitle.text(popupTitle);
pBody.html(popupBody);
pSubmit.val(popupAccept).click(showEditor);

)
else
var confirmText = $(this).data('confirm-text');
if (confirmText ? confirm(confirmText) : true)
showEditor();


);
);

4 Answers
4

active

oldest

votes

4 Answers
4

active

oldest

votes

active

oldest

votes

active

oldest

votes

up vote
14
down vote



accepted

Remember, if the pirates get away with the first ship, they're more likely to try again on another. You really have to stand your ground. The alternative is you lose control of the project, and eventually everyone is miserable. The 'fixed price, fixed deliverable' software job is usually a mistake, for precisely this reason.

Imagine the surgeon is about to put you under, and he's telling you 'We'll get you out of here on schedule and on budget'. The minor detail left unclear is whether you'll be alive. It appears that your client doesn't understand the role of software in a business. To the extent that that is true, they then don't understand what getting good software costs. It would appear, at this point, they're in over their heads as much as you are - they can't afford what they want, although they can probably afford what you've promised to do.

Probably the most politically viable path under the circumstance is finish the project, turn it in, collect your money, and move on. This is the right approach if they are adamant about the budget - give them what they originally agreed to, nothing more, and nothing less. If they're showing signs of being unhappy, discontinue any working relationship beyond that point.

If there is a situation where this is leading to a breakdown in trust, it would make sense to come to an early termination agreement, wrap up loose ends, give them the deliverables you have, and liquidate the contract. Don't bother with spec revisions and a rebid. Let them find another provider. Do not, however, 'lock up' anything. Give them what you've done and what they've paid for so far. If there is no payment yet, consider walking away, gracefully (i.e., with mutual agreement) if possible.

The best approach is to convert the agreement to a time and materials basis and run it as an agile development cycle. In short, instead of a 'fixed price, fixed deliverable', it will be structured with 'milestones'. Subsequent phases are based on 'lessons learned', or evolving requirements. Customer feedback will be encouraged during each development cycle. If you have to meter the work out more slowly to keep the project within their current budget, come to some understanding of how to redeploy your developers so that progress is optimum given the constraints.

If at all possible, convene another meeting with all the higher ups, present some case histories of situations where things like this happened (they're easy to find, including the Big One - Obamacare), and how they ended. If you can find a story that isn't full of fights and lawsuits, see if you can show them the right way forward.

share|improve this answer

answered Oct 29 '13 at 4:32

Meredith Poor

8,8661730

• 
  
  
  

  
  5
  

  
  
  
  
  
  

  
  Selling agile to your client is sometimes a hard thing to do, since the way accounting and budgets typically work don't tend to look favorably on projects without a definite end date and that are constantly ongoing without an end in sight. Other clients are simply sleazy and predatory and don't like Agile on the grounds that they have far less room for bullying and manipulative behavior.
  – maple_shaft
  Oct 29 '13 at 11:26
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  I agree that the OP must stand their ground; however I disagree with "fixed scope, fixed deliverable" being a problem in general. Nor do I think switching to T&M will fix the client relations. If the client has poor internal management or a very fixed budget, then T&M billing is a bad idea as T&M generally leads to cost overruns; which would be a project failure.
  – NotMe
  Jul 25 '14 at 16:00
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  Short, timeboxed sprints are the way to go. In my experience, most clients seem to like them as they get visibility and control. They can say "we spent X and got an MVP proof of concept". Then later: "we spent X and got features Y and Q which we thought were most critical". I've always found it an easy sell.
  – superluminary
  Apr 26 '16 at 11:55
  

  
  
  
  

add a comment | 

up vote
14
down vote



accepted

Remember, if the pirates get away with the first ship, they're more likely to try again on another. You really have to stand your ground. The alternative is you lose control of the project, and eventually everyone is miserable. The 'fixed price, fixed deliverable' software job is usually a mistake, for precisely this reason.

Imagine the surgeon is about to put you under, and he's telling you 'We'll get you out of here on schedule and on budget'. The minor detail left unclear is whether you'll be alive. It appears that your client doesn't understand the role of software in a business. To the extent that that is true, they then don't understand what getting good software costs. It would appear, at this point, they're in over their heads as much as you are - they can't afford what they want, although they can probably afford what you've promised to do.

Probably the most politically viable path under the circumstance is finish the project, turn it in, collect your money, and move on. This is the right approach if they are adamant about the budget - give them what they originally agreed to, nothing more, and nothing less. If they're showing signs of being unhappy, discontinue any working relationship beyond that point.

If there is a situation where this is leading to a breakdown in trust, it would make sense to come to an early termination agreement, wrap up loose ends, give them the deliverables you have, and liquidate the contract. Don't bother with spec revisions and a rebid. Let them find another provider. Do not, however, 'lock up' anything. Give them what you've done and what they've paid for so far. If there is no payment yet, consider walking away, gracefully (i.e., with mutual agreement) if possible.

The best approach is to convert the agreement to a time and materials basis and run it as an agile development cycle. In short, instead of a 'fixed price, fixed deliverable', it will be structured with 'milestones'. Subsequent phases are based on 'lessons learned', or evolving requirements. Customer feedback will be encouraged during each development cycle. If you have to meter the work out more slowly to keep the project within their current budget, come to some understanding of how to redeploy your developers so that progress is optimum given the constraints.

If at all possible, convene another meeting with all the higher ups, present some case histories of situations where things like this happened (they're easy to find, including the Big One - Obamacare), and how they ended. If you can find a story that isn't full of fights and lawsuits, see if you can show them the right way forward.

share|improve this answer

answered Oct 29 '13 at 4:32

Meredith Poor

8,8661730

• 
  
  
  

  
  5
  

  
  
  
  
  
  

  
  Selling agile to your client is sometimes a hard thing to do, since the way accounting and budgets typically work don't tend to look favorably on projects without a definite end date and that are constantly ongoing without an end in sight. Other clients are simply sleazy and predatory and don't like Agile on the grounds that they have far less room for bullying and manipulative behavior.
  – maple_shaft
  Oct 29 '13 at 11:26
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  I agree that the OP must stand their ground; however I disagree with "fixed scope, fixed deliverable" being a problem in general. Nor do I think switching to T&M will fix the client relations. If the client has poor internal management or a very fixed budget, then T&M billing is a bad idea as T&M generally leads to cost overruns; which would be a project failure.
  – NotMe
  Jul 25 '14 at 16:00
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  Short, timeboxed sprints are the way to go. In my experience, most clients seem to like them as they get visibility and control. They can say "we spent X and got an MVP proof of concept". Then later: "we spent X and got features Y and Q which we thought were most critical". I've always found it an easy sell.
  – superluminary
  Apr 26 '16 at 11:55
  

  
  
  
  

add a comment | 

up vote
14
down vote



accepted

up vote
14
down vote



accepted

Remember, if the pirates get away with the first ship, they're more likely to try again on another. You really have to stand your ground. The alternative is you lose control of the project, and eventually everyone is miserable. The 'fixed price, fixed deliverable' software job is usually a mistake, for precisely this reason.

Imagine the surgeon is about to put you under, and he's telling you 'We'll get you out of here on schedule and on budget'. The minor detail left unclear is whether you'll be alive. It appears that your client doesn't understand the role of software in a business. To the extent that that is true, they then don't understand what getting good software costs. It would appear, at this point, they're in over their heads as much as you are - they can't afford what they want, although they can probably afford what you've promised to do.

Probably the most politically viable path under the circumstance is finish the project, turn it in, collect your money, and move on. This is the right approach if they are adamant about the budget - give them what they originally agreed to, nothing more, and nothing less. If they're showing signs of being unhappy, discontinue any working relationship beyond that point.

If there is a situation where this is leading to a breakdown in trust, it would make sense to come to an early termination agreement, wrap up loose ends, give them the deliverables you have, and liquidate the contract. Don't bother with spec revisions and a rebid. Let them find another provider. Do not, however, 'lock up' anything. Give them what you've done and what they've paid for so far. If there is no payment yet, consider walking away, gracefully (i.e., with mutual agreement) if possible.

The best approach is to convert the agreement to a time and materials basis and run it as an agile development cycle. In short, instead of a 'fixed price, fixed deliverable', it will be structured with 'milestones'. Subsequent phases are based on 'lessons learned', or evolving requirements. Customer feedback will be encouraged during each development cycle. If you have to meter the work out more slowly to keep the project within their current budget, come to some understanding of how to redeploy your developers so that progress is optimum given the constraints.

If at all possible, convene another meeting with all the higher ups, present some case histories of situations where things like this happened (they're easy to find, including the Big One - Obamacare), and how they ended. If you can find a story that isn't full of fights and lawsuits, see if you can show them the right way forward.

share|improve this answer

answered Oct 29 '13 at 4:32

Meredith Poor

8,8661730

Remember, if the pirates get away with the first ship, they're more likely to try again on another. You really have to stand your ground. The alternative is you lose control of the project, and eventually everyone is miserable. The 'fixed price, fixed deliverable' software job is usually a mistake, for precisely this reason.

Imagine the surgeon is about to put you under, and he's telling you 'We'll get you out of here on schedule and on budget'. The minor detail left unclear is whether you'll be alive. It appears that your client doesn't understand the role of software in a business. To the extent that that is true, they then don't understand what getting good software costs. It would appear, at this point, they're in over their heads as much as you are - they can't afford what they want, although they can probably afford what you've promised to do.

Probably the most politically viable path under the circumstance is finish the project, turn it in, collect your money, and move on. This is the right approach if they are adamant about the budget - give them what they originally agreed to, nothing more, and nothing less. If they're showing signs of being unhappy, discontinue any working relationship beyond that point.

If there is a situation where this is leading to a breakdown in trust, it would make sense to come to an early termination agreement, wrap up loose ends, give them the deliverables you have, and liquidate the contract. Don't bother with spec revisions and a rebid. Let them find another provider. Do not, however, 'lock up' anything. Give them what you've done and what they've paid for so far. If there is no payment yet, consider walking away, gracefully (i.e., with mutual agreement) if possible.

The best approach is to convert the agreement to a time and materials basis and run it as an agile development cycle. In short, instead of a 'fixed price, fixed deliverable', it will be structured with 'milestones'. Subsequent phases are based on 'lessons learned', or evolving requirements. Customer feedback will be encouraged during each development cycle. If you have to meter the work out more slowly to keep the project within their current budget, come to some understanding of how to redeploy your developers so that progress is optimum given the constraints.

If at all possible, convene another meeting with all the higher ups, present some case histories of situations where things like this happened (they're easy to find, including the Big One - Obamacare), and how they ended. If you can find a story that isn't full of fights and lawsuits, see if you can show them the right way forward.

share|improve this answer

answered Oct 29 '13 at 4:32

Meredith Poor

8,8661730

share|improve this answer

share|improve this answer

answered Oct 29 '13 at 4:32

Meredith Poor

8,8661730

answered Oct 29 '13 at 4:32

Meredith Poor

8,8661730

answered Oct 29 '13 at 4:32

Meredith Poor

8,8661730

8,8661730

• 
  
  
  

  
  5
  

  
  
  
  
  
  

  
  Selling agile to your client is sometimes a hard thing to do, since the way accounting and budgets typically work don't tend to look favorably on projects without a definite end date and that are constantly ongoing without an end in sight. Other clients are simply sleazy and predatory and don't like Agile on the grounds that they have far less room for bullying and manipulative behavior.
  – maple_shaft
  Oct 29 '13 at 11:26
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  I agree that the OP must stand their ground; however I disagree with "fixed scope, fixed deliverable" being a problem in general. Nor do I think switching to T&M will fix the client relations. If the client has poor internal management or a very fixed budget, then T&M billing is a bad idea as T&M generally leads to cost overruns; which would be a project failure.
  – NotMe
  Jul 25 '14 at 16:00
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  Short, timeboxed sprints are the way to go. In my experience, most clients seem to like them as they get visibility and control. They can say "we spent X and got an MVP proof of concept". Then later: "we spent X and got features Y and Q which we thought were most critical". I've always found it an easy sell.
  – superluminary
  Apr 26 '16 at 11:55
  

  
  
  
  

add a comment | 

• 
  
  
  

  
  5
  

  
  
  
  
  
  

  
  Selling agile to your client is sometimes a hard thing to do, since the way accounting and budgets typically work don't tend to look favorably on projects without a definite end date and that are constantly ongoing without an end in sight. Other clients are simply sleazy and predatory and don't like Agile on the grounds that they have far less room for bullying and manipulative behavior.
  – maple_shaft
  Oct 29 '13 at 11:26
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  I agree that the OP must stand their ground; however I disagree with "fixed scope, fixed deliverable" being a problem in general. Nor do I think switching to T&M will fix the client relations. If the client has poor internal management or a very fixed budget, then T&M billing is a bad idea as T&M generally leads to cost overruns; which would be a project failure.
  – NotMe
  Jul 25 '14 at 16:00
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  Short, timeboxed sprints are the way to go. In my experience, most clients seem to like them as they get visibility and control. They can say "we spent X and got an MVP proof of concept". Then later: "we spent X and got features Y and Q which we thought were most critical". I've always found it an easy sell.
  – superluminary
  Apr 26 '16 at 11:55
  

  
  
  
  

5

5

Selling agile to your client is sometimes a hard thing to do, since the way accounting and budgets typically work don't tend to look favorably on projects without a definite end date and that are constantly ongoing without an end in sight. Other clients are simply sleazy and predatory and don't like Agile on the grounds that they have far less room for bullying and manipulative behavior.
– maple_shaft
Oct 29 '13 at 11:26

Selling agile to your client is sometimes a hard thing to do, since the way accounting and budgets typically work don't tend to look favorably on projects without a definite end date and that are constantly ongoing without an end in sight. Other clients are simply sleazy and predatory and don't like Agile on the grounds that they have far less room for bullying and manipulative behavior.
– maple_shaft
Oct 29 '13 at 11:26

I agree that the OP must stand their ground; however I disagree with "fixed scope, fixed deliverable" being a problem in general. Nor do I think switching to T&M will fix the client relations. If the client has poor internal management or a very fixed budget, then T&M billing is a bad idea as T&M generally leads to cost overruns; which would be a project failure.
– NotMe
Jul 25 '14 at 16:00

I agree that the OP must stand their ground; however I disagree with "fixed scope, fixed deliverable" being a problem in general. Nor do I think switching to T&M will fix the client relations. If the client has poor internal management or a very fixed budget, then T&M billing is a bad idea as T&M generally leads to cost overruns; which would be a project failure.
– NotMe
Jul 25 '14 at 16:00

Short, timeboxed sprints are the way to go. In my experience, most clients seem to like them as they get visibility and control. They can say "we spent X and got an MVP proof of concept". Then later: "we spent X and got features Y and Q which we thought were most critical". I've always found it an easy sell.
– superluminary
Apr 26 '16 at 11:55

Short, timeboxed sprints are the way to go. In my experience, most clients seem to like them as they get visibility and control. They can say "we spent X and got an MVP proof of concept". Then later: "we spent X and got features Y and Q which we thought were most critical". I've always found it an easy sell.
– superluminary
Apr 26 '16 at 11:55

add a comment | 

up vote
14
down vote

But how do you kill this problem by the root?

You don't get rid of it completely. A way to get close is to have someone on the receiving end who has "been there" in development of whatever you are contracted to do. If you are negotiating with a software developer while working a software dev project, they will understand somewhat the increases in work associated with changing requirements.

What you need to do:

1. Have project scope discussions and documentation at the beginning of projects. Make sure to get buy-in from your stakeholders and agreement from both sides what is being created.


2. For paid contracts, have a "change process" - don't leave this unaddressed. If you specify in advance what happens when features change or additional features are requested, then you can point back to a document both parties agreed on


3. When additional requests do come (not if), pick your battles wisely... don't just reject all of them.


4. If you have to reject them or charge for them, make sure the client knows why. "This feature would require rearchitecting the main part of the database model, which would be significant work." People don't like their ideas being rejected for no reason. But put a justification to it. Depending on where you are at in the process, consider using an analogy.

A great way to describe scope creep's effect on people unfamiliar with your topic is through a house. Describe the project in terms of building a house - you have to get the design done, then you start building a room. The further you go in the process the more complicated it is to add another room. Adding a 30% feature is the same as repainting and recarpeting the entire house.

The further removed the stakeholders are from the actual implementation/project work, the more important it is to discuss things in analogies and providing explanations as to why it would result in enough additional work to your stakeholders. They might think, "it's only a few min of work COME ON" when it is 100 hours of work (or vice versa).

"it's out of the scope of this project. We can talk about it after we're done with the first project."

Change this to something more like:

• "Well, we can look at it, but right now it'd be a fairly large change to the scope of the project. I can talk with my team and see what they would estimate this would take to implement. Do you want us to investigate what it would take to get your request added to the scope of the project? Can you detail your request a bit more so we can get a more accurate estimate?"

---

Additionally, if you encounter this problem frequently it may benefit you to take some training in negotiation. Each of these requests results in a mini-negotiation.

share|improve this answer

edited Oct 28 '13 at 21:22

answered Oct 28 '13 at 18:13

Elysian Fields♦

96.9k46292449

add a comment | 

up vote
14
down vote

But how do you kill this problem by the root?

You don't get rid of it completely. A way to get close is to have someone on the receiving end who has "been there" in development of whatever you are contracted to do. If you are negotiating with a software developer while working a software dev project, they will understand somewhat the increases in work associated with changing requirements.

What you need to do:

1. Have project scope discussions and documentation at the beginning of projects. Make sure to get buy-in from your stakeholders and agreement from both sides what is being created.


2. For paid contracts, have a "change process" - don't leave this unaddressed. If you specify in advance what happens when features change or additional features are requested, then you can point back to a document both parties agreed on


3. When additional requests do come (not if), pick your battles wisely... don't just reject all of them.


4. If you have to reject them or charge for them, make sure the client knows why. "This feature would require rearchitecting the main part of the database model, which would be significant work." People don't like their ideas being rejected for no reason. But put a justification to it. Depending on where you are at in the process, consider using an analogy.

A great way to describe scope creep's effect on people unfamiliar with your topic is through a house. Describe the project in terms of building a house - you have to get the design done, then you start building a room. The further you go in the process the more complicated it is to add another room. Adding a 30% feature is the same as repainting and recarpeting the entire house.

The further removed the stakeholders are from the actual implementation/project work, the more important it is to discuss things in analogies and providing explanations as to why it would result in enough additional work to your stakeholders. They might think, "it's only a few min of work COME ON" when it is 100 hours of work (or vice versa).

"it's out of the scope of this project. We can talk about it after we're done with the first project."

Change this to something more like:

• "Well, we can look at it, but right now it'd be a fairly large change to the scope of the project. I can talk with my team and see what they would estimate this would take to implement. Do you want us to investigate what it would take to get your request added to the scope of the project? Can you detail your request a bit more so we can get a more accurate estimate?"

---

Additionally, if you encounter this problem frequently it may benefit you to take some training in negotiation. Each of these requests results in a mini-negotiation.

share|improve this answer

edited Oct 28 '13 at 21:22

answered Oct 28 '13 at 18:13

Elysian Fields♦

96.9k46292449

add a comment | 

up vote
14
down vote

up vote
14
down vote

But how do you kill this problem by the root?

You don't get rid of it completely. A way to get close is to have someone on the receiving end who has "been there" in development of whatever you are contracted to do. If you are negotiating with a software developer while working a software dev project, they will understand somewhat the increases in work associated with changing requirements.

What you need to do:

1. Have project scope discussions and documentation at the beginning of projects. Make sure to get buy-in from your stakeholders and agreement from both sides what is being created.


2. For paid contracts, have a "change process" - don't leave this unaddressed. If you specify in advance what happens when features change or additional features are requested, then you can point back to a document both parties agreed on


3. When additional requests do come (not if), pick your battles wisely... don't just reject all of them.


4. If you have to reject them or charge for them, make sure the client knows why. "This feature would require rearchitecting the main part of the database model, which would be significant work." People don't like their ideas being rejected for no reason. But put a justification to it. Depending on where you are at in the process, consider using an analogy.

A great way to describe scope creep's effect on people unfamiliar with your topic is through a house. Describe the project in terms of building a house - you have to get the design done, then you start building a room. The further you go in the process the more complicated it is to add another room. Adding a 30% feature is the same as repainting and recarpeting the entire house.

The further removed the stakeholders are from the actual implementation/project work, the more important it is to discuss things in analogies and providing explanations as to why it would result in enough additional work to your stakeholders. They might think, "it's only a few min of work COME ON" when it is 100 hours of work (or vice versa).

"it's out of the scope of this project. We can talk about it after we're done with the first project."

Change this to something more like:

• "Well, we can look at it, but right now it'd be a fairly large change to the scope of the project. I can talk with my team and see what they would estimate this would take to implement. Do you want us to investigate what it would take to get your request added to the scope of the project? Can you detail your request a bit more so we can get a more accurate estimate?"

---

Additionally, if you encounter this problem frequently it may benefit you to take some training in negotiation. Each of these requests results in a mini-negotiation.

share|improve this answer

edited Oct 28 '13 at 21:22

answered Oct 28 '13 at 18:13

Elysian Fields♦

96.9k46292449

But how do you kill this problem by the root?

You don't get rid of it completely. A way to get close is to have someone on the receiving end who has "been there" in development of whatever you are contracted to do. If you are negotiating with a software developer while working a software dev project, they will understand somewhat the increases in work associated with changing requirements.

What you need to do:

1. Have project scope discussions and documentation at the beginning of projects. Make sure to get buy-in from your stakeholders and agreement from both sides what is being created.


2. For paid contracts, have a "change process" - don't leave this unaddressed. If you specify in advance what happens when features change or additional features are requested, then you can point back to a document both parties agreed on


3. When additional requests do come (not if), pick your battles wisely... don't just reject all of them.


4. If you have to reject them or charge for them, make sure the client knows why. "This feature would require rearchitecting the main part of the database model, which would be significant work." People don't like their ideas being rejected for no reason. But put a justification to it. Depending on where you are at in the process, consider using an analogy.

A great way to describe scope creep's effect on people unfamiliar with your topic is through a house. Describe the project in terms of building a house - you have to get the design done, then you start building a room. The further you go in the process the more complicated it is to add another room. Adding a 30% feature is the same as repainting and recarpeting the entire house.

The further removed the stakeholders are from the actual implementation/project work, the more important it is to discuss things in analogies and providing explanations as to why it would result in enough additional work to your stakeholders. They might think, "it's only a few min of work COME ON" when it is 100 hours of work (or vice versa).

"it's out of the scope of this project. We can talk about it after we're done with the first project."

Change this to something more like:

• "Well, we can look at it, but right now it'd be a fairly large change to the scope of the project. I can talk with my team and see what they would estimate this would take to implement. Do you want us to investigate what it would take to get your request added to the scope of the project? Can you detail your request a bit more so we can get a more accurate estimate?"

---

Additionally, if you encounter this problem frequently it may benefit you to take some training in negotiation. Each of these requests results in a mini-negotiation.

share|improve this answer

edited Oct 28 '13 at 21:22

answered Oct 28 '13 at 18:13

Elysian Fields♦

96.9k46292449

share|improve this answer

share|improve this answer

edited Oct 28 '13 at 21:22

edited Oct 28 '13 at 21:22

edited Oct 28 '13 at 21:22

answered Oct 28 '13 at 18:13

Elysian Fields♦

96.9k46292449

answered Oct 28 '13 at 18:13

Elysian Fields♦

96.9k46292449

answered Oct 28 '13 at 18:13

Elysian Fields♦

96.9k46292449

96.9k46292449

add a comment | 

add a comment | 

up vote
11
down vote

Executive Summary

You ultimately have three choices:

1. Concede the additional work for free


2. Concede the additional work in exchange for something


3. Refuse to take on the additional work and stick to the contract

Deciding which choice to make depends on your evaluation of the business impact of each in a best case/worst case scenario, and taking a risk appropriate to your business.

In the future, you should take care to prevent this sort of thing from happening.

Concede the Additional Work for Free

This has very little upside, but if it is the only way to get money from the client, it may be the only appropriate choice. You need to determine if that's the case.

If this client is important, or if there is a chance they will cancel the entire project and you wouldn't have the resources to recover costs, you may want to consider just giving the feature for free. At the end of the day, an unhappy client may cause more harm than the added cost of implementing the feature.

Trade the Feature for Something Else

If the customer is not essential to the well-being of your business, and you want to take a harder stance against their demands, you can try asking for something else. You do not have to ask for full-value of the additional feature if you are worried that would make them walk away, so use your best judgment to figure out what you can get.

In exchange for this feature you could ask for:

1. A reduction in other features/work


2. An increase in payment


3. Other concessions

Reduction in Other Features/Work

If you have a list of what features and how much time they require, you can add the new feature and show how it would impact other features they have asked for. If you are confident in the amount of work required for each portion, you can negotiate which parts they want to trade the new feature for. This requires that you have firm estimates you can justify to the customer, and runs the risk that they will start attacking your estimates of effort for other portions (especially if they are already complaining about the current contract price).

Increase in Payment

If you can create a firm estimate for the cost of developing, testing, and implementing this additional feature, you can create two separate estimates for the customer:

1. Including the feature to be packaged with the original promised deliverables


2. Including the feature after the original promised deliverables

Giving the customer an idea of how much of an added burden this is to add will make it more likely that they will take the cheaper option (and be grateful), or decide to scrap the feature due to the added cost.

Other Concessions

If this product will require maintenance or after-service in some way, you can negotiate to include this feature in exchange for a service contract paying you X for the next Y months to maintain it. Or if there is other future business that this company will need services like yours for, you can negotiate to have the exclusive right to negotiate (in good faith) for the next project.

Refuse to Take the Additional Work

If you are concerned the customer may abuse any goodwill or shifting of goalposts, even at additional price, then you can simply refuse and refer to the contract. If you do stick to this, be sure to consult a lawyer to see what (if any) potential pitfalls there could be if you stick to the letter of the law, just so you can be sure you get paid.

This has a good chance of making the client unhappy as it suggests you are not willing to meet their needs, but sometimes the best thing to do with a difficult client is to do as little business with them as possible.

An Ounce of Prevention...

Unfortunately, asking for things beyond the scope of the original negotiated contract is quite normal in many cultures/industries. There are many things you can do to try to plan for these changes, and otherwise minimize their impact when they do come up. These solutions are not mutually-exclusive.

Create Detailed Specifications

For large engineering projects, for instance, every single drawing of every single part of the project needs to be initialed and agreed to by the purchaser. By having the customer agree to the detailed design beforehand, it becomes much more difficult to say, "Yes, but I really wanted..."

Negotiate with the Decision-Maker

When you negotiate a contract, negotiate with the person signing the checks. If you don't, the person you negotiate with could just ask their boss to rubber-stamp it, and may even promise the boss that the contract says something that it doesn't to make sure they get it signed (assuming they can negotiate later with the support of their boss).

Add Language to the Contract Handling Changes

Make sure that your contract has language explaining how changes will be handled. I am not a lawyer, but in plain English, a clause that says something like (have a lawyer make it legal):

Changes

The price in this contract is for the work described in Section X. If a change from Section X in scope or schedule is required, the purchaser must provide notice including a detailed description in writing of the proposed changes to the contractor. Upon receipt of such notice, the contractor will provide a response within Y days explaining:

1. Reason for refusal; or


2. Adjusted Price and Schedule for the changes

The contractor is under no obligation to accept any change in scope from this contract. If an estimate is provided, parties will negotiate in good faith to come to a decision to revise this contract based on the changed scope, or to negotiate a separate contract as appropriate.

This will clearly say to the customer, "This agreement is full and complete, and if you want something else, you have to negotiate for it." This goes hand-in-hand with having detailed specifications so that all parties are clear on the scope and schedule of the project.

Estimate Contingency

Depending on your industry and how competitive bids are, you can differentiate yourself by estimating a certain amount of contingency to your costs so that when something comes up, you can say, "We would be happy to do that" without compromising your bottom line. This will make your initial price higher, but it will also give you more flexibility to compromise on certain aspects, which may be easier for some of your customers than getting additional payment after the fact.

Get a Salesman

A good salesperson will check up on customers, and catch some of these problems before they escalate. Depending on the size of your business and the number of clients, you may want to consider getting a salaried salesman (who is primarily salaried rather than paid on commission). If you have several contracts, and you are doing 20% extra work on a team of 10 because of these sorts of requests, even if he only cuts that down to 10% he is paying his own salary (assuming you pay as much as the developers).

share|improve this answer

answered Oct 29 '13 at 1:18

jmac

19.4k763137

add a comment | 

up vote
11
down vote

Executive Summary

You ultimately have three choices:

1. Concede the additional work for free


2. Concede the additional work in exchange for something


3. Refuse to take on the additional work and stick to the contract

Deciding which choice to make depends on your evaluation of the business impact of each in a best case/worst case scenario, and taking a risk appropriate to your business.

In the future, you should take care to prevent this sort of thing from happening.

Concede the Additional Work for Free

This has very little upside, but if it is the only way to get money from the client, it may be the only appropriate choice. You need to determine if that's the case.

If this client is important, or if there is a chance they will cancel the entire project and you wouldn't have the resources to recover costs, you may want to consider just giving the feature for free. At the end of the day, an unhappy client may cause more harm than the added cost of implementing the feature.

Trade the Feature for Something Else

If the customer is not essential to the well-being of your business, and you want to take a harder stance against their demands, you can try asking for something else. You do not have to ask for full-value of the additional feature if you are worried that would make them walk away, so use your best judgment to figure out what you can get.

In exchange for this feature you could ask for:

1. A reduction in other features/work


2. An increase in payment


3. Other concessions

Reduction in Other Features/Work

If you have a list of what features and how much time they require, you can add the new feature and show how it would impact other features they have asked for. If you are confident in the amount of work required for each portion, you can negotiate which parts they want to trade the new feature for. This requires that you have firm estimates you can justify to the customer, and runs the risk that they will start attacking your estimates of effort for other portions (especially if they are already complaining about the current contract price).

Increase in Payment

If you can create a firm estimate for the cost of developing, testing, and implementing this additional feature, you can create two separate estimates for the customer:

1. Including the feature to be packaged with the original promised deliverables


2. Including the feature after the original promised deliverables

Giving the customer an idea of how much of an added burden this is to add will make it more likely that they will take the cheaper option (and be grateful), or decide to scrap the feature due to the added cost.

Other Concessions

If this product will require maintenance or after-service in some way, you can negotiate to include this feature in exchange for a service contract paying you X for the next Y months to maintain it. Or if there is other future business that this company will need services like yours for, you can negotiate to have the exclusive right to negotiate (in good faith) for the next project.

Refuse to Take the Additional Work

If you are concerned the customer may abuse any goodwill or shifting of goalposts, even at additional price, then you can simply refuse and refer to the contract. If you do stick to this, be sure to consult a lawyer to see what (if any) potential pitfalls there could be if you stick to the letter of the law, just so you can be sure you get paid.

This has a good chance of making the client unhappy as it suggests you are not willing to meet their needs, but sometimes the best thing to do with a difficult client is to do as little business with them as possible.

An Ounce of Prevention...

Unfortunately, asking for things beyond the scope of the original negotiated contract is quite normal in many cultures/industries. There are many things you can do to try to plan for these changes, and otherwise minimize their impact when they do come up. These solutions are not mutually-exclusive.

Create Detailed Specifications

For large engineering projects, for instance, every single drawing of every single part of the project needs to be initialed and agreed to by the purchaser. By having the customer agree to the detailed design beforehand, it becomes much more difficult to say, "Yes, but I really wanted..."

Negotiate with the Decision-Maker

When you negotiate a contract, negotiate with the person signing the checks. If you don't, the person you negotiate with could just ask their boss to rubber-stamp it, and may even promise the boss that the contract says something that it doesn't to make sure they get it signed (assuming they can negotiate later with the support of their boss).

Add Language to the Contract Handling Changes

Make sure that your contract has language explaining how changes will be handled. I am not a lawyer, but in plain English, a clause that says something like (have a lawyer make it legal):

Changes

The price in this contract is for the work described in Section X. If a change from Section X in scope or schedule is required, the purchaser must provide notice including a detailed description in writing of the proposed changes to the contractor. Upon receipt of such notice, the contractor will provide a response within Y days explaining:

1. Reason for refusal; or


2. Adjusted Price and Schedule for the changes

The contractor is under no obligation to accept any change in scope from this contract. If an estimate is provided, parties will negotiate in good faith to come to a decision to revise this contract based on the changed scope, or to negotiate a separate contract as appropriate.

This will clearly say to the customer, "This agreement is full and complete, and if you want something else, you have to negotiate for it." This goes hand-in-hand with having detailed specifications so that all parties are clear on the scope and schedule of the project.

Estimate Contingency

Depending on your industry and how competitive bids are, you can differentiate yourself by estimating a certain amount of contingency to your costs so that when something comes up, you can say, "We would be happy to do that" without compromising your bottom line. This will make your initial price higher, but it will also give you more flexibility to compromise on certain aspects, which may be easier for some of your customers than getting additional payment after the fact.

Get a Salesman

A good salesperson will check up on customers, and catch some of these problems before they escalate. Depending on the size of your business and the number of clients, you may want to consider getting a salaried salesman (who is primarily salaried rather than paid on commission). If you have several contracts, and you are doing 20% extra work on a team of 10 because of these sorts of requests, even if he only cuts that down to 10% he is paying his own salary (assuming you pay as much as the developers).

share|improve this answer

answered Oct 29 '13 at 1:18

jmac

19.4k763137

add a comment | 

up vote
11
down vote

up vote
11
down vote

Executive Summary

You ultimately have three choices:

1. Concede the additional work for free


2. Concede the additional work in exchange for something


3. Refuse to take on the additional work and stick to the contract

Deciding which choice to make depends on your evaluation of the business impact of each in a best case/worst case scenario, and taking a risk appropriate to your business.

In the future, you should take care to prevent this sort of thing from happening.

Concede the Additional Work for Free

This has very little upside, but if it is the only way to get money from the client, it may be the only appropriate choice. You need to determine if that's the case.

If this client is important, or if there is a chance they will cancel the entire project and you wouldn't have the resources to recover costs, you may want to consider just giving the feature for free. At the end of the day, an unhappy client may cause more harm than the added cost of implementing the feature.

Trade the Feature for Something Else

If the customer is not essential to the well-being of your business, and you want to take a harder stance against their demands, you can try asking for something else. You do not have to ask for full-value of the additional feature if you are worried that would make them walk away, so use your best judgment to figure out what you can get.

In exchange for this feature you could ask for:

1. A reduction in other features/work


2. An increase in payment


3. Other concessions

Reduction in Other Features/Work

If you have a list of what features and how much time they require, you can add the new feature and show how it would impact other features they have asked for. If you are confident in the amount of work required for each portion, you can negotiate which parts they want to trade the new feature for. This requires that you have firm estimates you can justify to the customer, and runs the risk that they will start attacking your estimates of effort for other portions (especially if they are already complaining about the current contract price).

Increase in Payment

If you can create a firm estimate for the cost of developing, testing, and implementing this additional feature, you can create two separate estimates for the customer:

1. Including the feature to be packaged with the original promised deliverables


2. Including the feature after the original promised deliverables

Giving the customer an idea of how much of an added burden this is to add will make it more likely that they will take the cheaper option (and be grateful), or decide to scrap the feature due to the added cost.

Other Concessions

If this product will require maintenance or after-service in some way, you can negotiate to include this feature in exchange for a service contract paying you X for the next Y months to maintain it. Or if there is other future business that this company will need services like yours for, you can negotiate to have the exclusive right to negotiate (in good faith) for the next project.

Refuse to Take the Additional Work

If you are concerned the customer may abuse any goodwill or shifting of goalposts, even at additional price, then you can simply refuse and refer to the contract. If you do stick to this, be sure to consult a lawyer to see what (if any) potential pitfalls there could be if you stick to the letter of the law, just so you can be sure you get paid.

This has a good chance of making the client unhappy as it suggests you are not willing to meet their needs, but sometimes the best thing to do with a difficult client is to do as little business with them as possible.

An Ounce of Prevention...

Unfortunately, asking for things beyond the scope of the original negotiated contract is quite normal in many cultures/industries. There are many things you can do to try to plan for these changes, and otherwise minimize their impact when they do come up. These solutions are not mutually-exclusive.

Create Detailed Specifications

For large engineering projects, for instance, every single drawing of every single part of the project needs to be initialed and agreed to by the purchaser. By having the customer agree to the detailed design beforehand, it becomes much more difficult to say, "Yes, but I really wanted..."

Negotiate with the Decision-Maker

When you negotiate a contract, negotiate with the person signing the checks. If you don't, the person you negotiate with could just ask their boss to rubber-stamp it, and may even promise the boss that the contract says something that it doesn't to make sure they get it signed (assuming they can negotiate later with the support of their boss).

Add Language to the Contract Handling Changes

Make sure that your contract has language explaining how changes will be handled. I am not a lawyer, but in plain English, a clause that says something like (have a lawyer make it legal):

Changes

The price in this contract is for the work described in Section X. If a change from Section X in scope or schedule is required, the purchaser must provide notice including a detailed description in writing of the proposed changes to the contractor. Upon receipt of such notice, the contractor will provide a response within Y days explaining:

1. Reason for refusal; or


2. Adjusted Price and Schedule for the changes

The contractor is under no obligation to accept any change in scope from this contract. If an estimate is provided, parties will negotiate in good faith to come to a decision to revise this contract based on the changed scope, or to negotiate a separate contract as appropriate.

This will clearly say to the customer, "This agreement is full and complete, and if you want something else, you have to negotiate for it." This goes hand-in-hand with having detailed specifications so that all parties are clear on the scope and schedule of the project.

Estimate Contingency

Depending on your industry and how competitive bids are, you can differentiate yourself by estimating a certain amount of contingency to your costs so that when something comes up, you can say, "We would be happy to do that" without compromising your bottom line. This will make your initial price higher, but it will also give you more flexibility to compromise on certain aspects, which may be easier for some of your customers than getting additional payment after the fact.

Get a Salesman

A good salesperson will check up on customers, and catch some of these problems before they escalate. Depending on the size of your business and the number of clients, you may want to consider getting a salaried salesman (who is primarily salaried rather than paid on commission). If you have several contracts, and you are doing 20% extra work on a team of 10 because of these sorts of requests, even if he only cuts that down to 10% he is paying his own salary (assuming you pay as much as the developers).

share|improve this answer

answered Oct 29 '13 at 1:18

jmac

19.4k763137

Executive Summary

You ultimately have three choices:

1. Concede the additional work for free


2. Concede the additional work in exchange for something


3. Refuse to take on the additional work and stick to the contract

Deciding which choice to make depends on your evaluation of the business impact of each in a best case/worst case scenario, and taking a risk appropriate to your business.

In the future, you should take care to prevent this sort of thing from happening.

Concede the Additional Work for Free

This has very little upside, but if it is the only way to get money from the client, it may be the only appropriate choice. You need to determine if that's the case.

If this client is important, or if there is a chance they will cancel the entire project and you wouldn't have the resources to recover costs, you may want to consider just giving the feature for free. At the end of the day, an unhappy client may cause more harm than the added cost of implementing the feature.

Trade the Feature for Something Else

If the customer is not essential to the well-being of your business, and you want to take a harder stance against their demands, you can try asking for something else. You do not have to ask for full-value of the additional feature if you are worried that would make them walk away, so use your best judgment to figure out what you can get.

In exchange for this feature you could ask for:

1. A reduction in other features/work


2. An increase in payment


3. Other concessions

Reduction in Other Features/Work

If you have a list of what features and how much time they require, you can add the new feature and show how it would impact other features they have asked for. If you are confident in the amount of work required for each portion, you can negotiate which parts they want to trade the new feature for. This requires that you have firm estimates you can justify to the customer, and runs the risk that they will start attacking your estimates of effort for other portions (especially if they are already complaining about the current contract price).

Increase in Payment

If you can create a firm estimate for the cost of developing, testing, and implementing this additional feature, you can create two separate estimates for the customer:

1. Including the feature to be packaged with the original promised deliverables


2. Including the feature after the original promised deliverables

Giving the customer an idea of how much of an added burden this is to add will make it more likely that they will take the cheaper option (and be grateful), or decide to scrap the feature due to the added cost.

Other Concessions

If this product will require maintenance or after-service in some way, you can negotiate to include this feature in exchange for a service contract paying you X for the next Y months to maintain it. Or if there is other future business that this company will need services like yours for, you can negotiate to have the exclusive right to negotiate (in good faith) for the next project.

Refuse to Take the Additional Work

If you are concerned the customer may abuse any goodwill or shifting of goalposts, even at additional price, then you can simply refuse and refer to the contract. If you do stick to this, be sure to consult a lawyer to see what (if any) potential pitfalls there could be if you stick to the letter of the law, just so you can be sure you get paid.

This has a good chance of making the client unhappy as it suggests you are not willing to meet their needs, but sometimes the best thing to do with a difficult client is to do as little business with them as possible.

An Ounce of Prevention...

Unfortunately, asking for things beyond the scope of the original negotiated contract is quite normal in many cultures/industries. There are many things you can do to try to plan for these changes, and otherwise minimize their impact when they do come up. These solutions are not mutually-exclusive.

Create Detailed Specifications

For large engineering projects, for instance, every single drawing of every single part of the project needs to be initialed and agreed to by the purchaser. By having the customer agree to the detailed design beforehand, it becomes much more difficult to say, "Yes, but I really wanted..."

Negotiate with the Decision-Maker

When you negotiate a contract, negotiate with the person signing the checks. If you don't, the person you negotiate with could just ask their boss to rubber-stamp it, and may even promise the boss that the contract says something that it doesn't to make sure they get it signed (assuming they can negotiate later with the support of their boss).

Add Language to the Contract Handling Changes

Make sure that your contract has language explaining how changes will be handled. I am not a lawyer, but in plain English, a clause that says something like (have a lawyer make it legal):

Changes

The price in this contract is for the work described in Section X. If a change from Section X in scope or schedule is required, the purchaser must provide notice including a detailed description in writing of the proposed changes to the contractor. Upon receipt of such notice, the contractor will provide a response within Y days explaining:

1. Reason for refusal; or


2. Adjusted Price and Schedule for the changes

The contractor is under no obligation to accept any change in scope from this contract. If an estimate is provided, parties will negotiate in good faith to come to a decision to revise this contract based on the changed scope, or to negotiate a separate contract as appropriate.

This will clearly say to the customer, "This agreement is full and complete, and if you want something else, you have to negotiate for it." This goes hand-in-hand with having detailed specifications so that all parties are clear on the scope and schedule of the project.

Estimate Contingency

Depending on your industry and how competitive bids are, you can differentiate yourself by estimating a certain amount of contingency to your costs so that when something comes up, you can say, "We would be happy to do that" without compromising your bottom line. This will make your initial price higher, but it will also give you more flexibility to compromise on certain aspects, which may be easier for some of your customers than getting additional payment after the fact.

Get a Salesman

A good salesperson will check up on customers, and catch some of these problems before they escalate. Depending on the size of your business and the number of clients, you may want to consider getting a salaried salesman (who is primarily salaried rather than paid on commission). If you have several contracts, and you are doing 20% extra work on a team of 10 because of these sorts of requests, even if he only cuts that down to 10% he is paying his own salary (assuming you pay as much as the developers).

share|improve this answer

answered Oct 29 '13 at 1:18

jmac

19.4k763137

share|improve this answer

share|improve this answer

answered Oct 29 '13 at 1:18

jmac

19.4k763137

answered Oct 29 '13 at 1:18

jmac

19.4k763137

answered Oct 29 '13 at 1:18

jmac

19.4k763137

19.4k763137

add a comment | 

add a comment | 

up vote
2
down vote

I mentioned F*** you, pay me, in a comment but essentially this should be covered in your contract.

If it isn't now, it needs to be. You are a professional, and your time is valuable. People like this are sending a very clear message - they do not respect you as a professional or value your time. Sometimes they are in fact terrible people, other times they just want to see what they can get. Based on your side of the story, it sounds like they're the terrible version.

share|improve this answer

answered Oct 29 '13 at 17:39

Wayne Werner

64059

add a comment | 

up vote
2
down vote

I mentioned F*** you, pay me, in a comment but essentially this should be covered in your contract.

If it isn't now, it needs to be. You are a professional, and your time is valuable. People like this are sending a very clear message - they do not respect you as a professional or value your time. Sometimes they are in fact terrible people, other times they just want to see what they can get. Based on your side of the story, it sounds like they're the terrible version.

share|improve this answer

answered Oct 29 '13 at 17:39

Wayne Werner

64059

add a comment | 

up vote
2
down vote

up vote
2
down vote

I mentioned F*** you, pay me, in a comment but essentially this should be covered in your contract.

If it isn't now, it needs to be. You are a professional, and your time is valuable. People like this are sending a very clear message - they do not respect you as a professional or value your time. Sometimes they are in fact terrible people, other times they just want to see what they can get. Based on your side of the story, it sounds like they're the terrible version.

share|improve this answer

answered Oct 29 '13 at 17:39

Wayne Werner

64059

I mentioned F*** you, pay me, in a comment but essentially this should be covered in your contract.

If it isn't now, it needs to be. You are a professional, and your time is valuable. People like this are sending a very clear message - they do not respect you as a professional or value your time. Sometimes they are in fact terrible people, other times they just want to see what they can get. Based on your side of the story, it sounds like they're the terrible version.

share|improve this answer

answered Oct 29 '13 at 17:39

Wayne Werner

64059

share|improve this answer

share|improve this answer

answered Oct 29 '13 at 17:39

Wayne Werner

64059

answered Oct 29 '13 at 17:39

Wayne Werner

64059

answered Oct 29 '13 at 17:39

Wayne Werner

64059

64059

add a comment | 

add a comment | 

 

draft saved

draft discarded

 

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name Email

StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fworkplace.stackexchange.com%2fquestions%2f15341%2fdealing-with-clients-who-want-more-than-whats-in-the-contract%23new-answer', 'question_page');

);

Post as a guest

Name Email

Sign up or log in

StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name Email

Sign up or log in

StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name Email

Sign up or log in

StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name Email

Name Email

Name

Email

Name Email

Name

Email