>Dave,
>
>I'm just getting to this thread. I've never done an independent contract, but Jim Duffy, in the course of the class I took from him, said something interesting that you don't usually hear.
>
>He said that he prices based on the amount of work the computerized system will replace. If the computerized system replaces 3 bookkeepers who work for a year at $32,000 apiece then say anything under $96,000 will still be cost-effective for the customer. Then he decides whether he can do the project for under $96,000 and still make money. If not, he doesn't take the contract.
>
>It's one more point of view to add to your mix of ideas. As I said, I've never done consulting (yet!).

Hi Cindy,
Jim Duffy's approach is the cornerstone behind effective fixed-price pricing models (IMO). Too many developers (again my opinion) see fixed price contracts as a one sided affair in favor of the client. They been have been burned in the past because they estimated something and it took longer than expected (for whatever reason) and they ended up losing money.

One of the reasons for this is the way the project was priced. The developer looks at the project, figures out how long it will take and multiplies that times their hourly rate. The they all add the "fudge" factor. This is to make up for errors in estimating and any unforseeable problems.

Some developers have a better system of estimating than others. Some will break the project into very small parts and use that to do the estimating. This is very effective because as a task gets smaller, the margin for error in estimating the time to complete becomes smaller.

But to me, this is the wrong approach. This is a time and material esitmate applied to a fixed price contract. The two don't mesh. Fixed prices should be negotiated based on the value of an application not how much it cost to produce. Jim's example based the value on the number of people it would replace. This is easy to judge. What is not easy to judge in advance is increased productivity or better access to data results in marketing successes that increase revenue.

The biggest questions that needs answering from a client are (other than what they want which rarely gets answered until the end *s*):
1. What is worth to them?
2. How much are they willing to pay to acquire that worth?

The answers are usually not the same.

Just another point to ponder. Whil Hentzen once talked to a group I participated in and his approach was to break a project up into two projects. The first was a time and material project to gather requirements and write a functional specification. At the end of this time, the client had a document they could farm out to anyone they wanted to actually do the work for a fixed price bid. The second part was the fixed price contract to actually build the application. Whil usually got the second part (although it was not a given) because he was very familiar with the work needed.

Just my $0.02.