Larry,

Thanks. These discussions are so important since cost estimating and business sense are not taught in the regular CPS classes we all have taken.

Someday I may take up moonlighting and I'll have accumulated a lot of wisdom before I ever start. Meanwhile, David, and others like him will be more successful as a result of this advice.



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