<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:georss="http://www.georss.org/georss" xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#" xmlns:media="http://search.yahoo.com/mrss/"
		>
<channel>
	<title>Comments on: 5 Ways to Deal with Difficult Clients</title>
	<atom:link href="http://webworkerdaily.com/2008/07/25/dealing-with-difficult-clients/feed/" rel="self" type="application/rss+xml" />
	<link>http://webworkerdaily.com/2008/07/25/dealing-with-difficult-clients/</link>
	<description>Rebooting the workforce</description>
	<lastBuildDate>Wed, 25 Nov 2009 20:29:46 +0000</lastBuildDate>
	<generator>http://wordpress.com/</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: ben</title>
		<link>http://webworkerdaily.com/2008/07/25/dealing-with-difficult-clients/#comment-300314</link>
		<dc:creator>ben</dc:creator>
		<pubDate>Sat, 26 Jul 2008 21:35:00 +0000</pubDate>
		<guid isPermaLink="false">http://webworkerdaily.wordpress.com/?p=3008#comment-300314</guid>
		<description>The principal benefit of sticking to T&amp;M is that most devs&#039; billables consist of labor, and hours worked is a hard metric to argue.

At the end of the day, a haggling account is a haggling account. The difference is that when you have a document to which both parties have agreed, and it states the terms of payment, clients inclined to haggle have less leverage.

I usually resolve the issue by reviewing invoices with clients before they&#039;re officially sent - I know where I&#039;ve screwed up and taken too long to do something, and underbill accordingly. I&#039;ve never actually had to haggle over line items on an invoice.

The best part of T&amp;M is that when you set a budget, you have a target you can beat... and a mechanism by which client contacts can be held accountable for their refusal to come to final decisions.  This differing dynamic makes life a lot easier when it&#039;s time to tell a client to fish-or-cut-bait.</description>
		<content:encoded><![CDATA[<p>The principal benefit of sticking to T&amp;M is that most devs&#8217; billables consist of labor, and hours worked is a hard metric to argue.</p>
<p>At the end of the day, a haggling account is a haggling account. The difference is that when you have a document to which both parties have agreed, and it states the terms of payment, clients inclined to haggle have less leverage.</p>
<p>I usually resolve the issue by reviewing invoices with clients before they&#8217;re officially sent &#8211; I know where I&#8217;ve screwed up and taken too long to do something, and underbill accordingly. I&#8217;ve never actually had to haggle over line items on an invoice.</p>
<p>The best part of T&amp;M is that when you set a budget, you have a target you can beat&#8230; and a mechanism by which client contacts can be held accountable for their refusal to come to final decisions.  This differing dynamic makes life a lot easier when it&#8217;s time to tell a client to fish-or-cut-bait.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Avonelle Lovhaug</title>
		<link>http://webworkerdaily.com/2008/07/25/dealing-with-difficult-clients/#comment-300220</link>
		<dc:creator>Avonelle Lovhaug</dc:creator>
		<pubDate>Fri, 25 Jul 2008 18:54:10 +0000</pubDate>
		<guid isPermaLink="false">http://webworkerdaily.wordpress.com/?p=3008#comment-300220</guid>
		<description>I&#039;m not sure how avoiding fixed cost work will help web workers deal with difficult customers. In my experience, customers are difficult regardless of whether you are dealing with fixed fee or hourly pricing. In fact, I have seen difficult customers nitpick every minute when being billed on the basis of time (&quot;Why did that take you 2 hours? It should have only taken you ten minutes!&quot;, etc.) Ugh.

I do only fixed bid work and am very happy. I do break things down as you described, although I don&#039;t think of it as &quot;escape points&quot;. But I don&#039;t provide a fixed bid for development work until I&#039;m fairly confident I know what it will contain (i.e. I&#039;ve have a design or something else that helps me to size it appropriately). But I agree that those &quot;escape points&quot; are good - for both me and the customer. If they aren&#039;t comfortable working with me, they can always take the design to someone else to code.</description>
		<content:encoded><![CDATA[<p>I&#8217;m not sure how avoiding fixed cost work will help web workers deal with difficult customers. In my experience, customers are difficult regardless of whether you are dealing with fixed fee or hourly pricing. In fact, I have seen difficult customers nitpick every minute when being billed on the basis of time (&#8220;Why did that take you 2 hours? It should have only taken you ten minutes!&#8221;, etc.) Ugh.</p>
<p>I do only fixed bid work and am very happy. I do break things down as you described, although I don&#8217;t think of it as &#8220;escape points&#8221;. But I don&#8217;t provide a fixed bid for development work until I&#8217;m fairly confident I know what it will contain (i.e. I&#8217;ve have a design or something else that helps me to size it appropriately). But I agree that those &#8220;escape points&#8221; are good &#8211; for both me and the customer. If they aren&#8217;t comfortable working with me, they can always take the design to someone else to code.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
