Re: Billable hours versus fixed bidding and flat rates for IBM i developers

This raises a question. Does one itemize labor or just lump sum it?
Years ago in a service shop where we were billing time and materials we were itemizing labor and getting complaints from a few about paying for coffee breaks, etc. We decided to change our billing practice to having one line listing labor at one totaled figure. We did our first billing run and geared up for an onslaught of questions. The phone did not ring even once. Same the second run, and the third. At that point we became suspicious that people were so upset that they were refusing to call us, so we phoned a few of the customers and asked them for their reactions. They liked the lump sum.

As time went on, we realized the only ones upset now were customers who were always upset anyways, and an occasional situation where we'd had a communication failure.



Jon Paris wrote:

I'm 100% in agreement with Simon's philosophy. I don't want to work for people who don't value the fact that I'm honest about my billings. In fact I have always tended to under bill rather than over. I have however worked in situations where the client (assumedly based on past experience) was convinced that the bill was being loaded. On one occasion after a number of snide comments I offered to re-do the bill because he was so convinced it was wrong. When he got the revised bill it was for 15 hours more than the original. He didn't whine so much after that.

I don't participate in the office birthday parties and such
- I'm not an employee, I'm a consultant.

I have to disagree with Michael on this point though. On a client site if I'm doing my job right, most of the time I'm part of the team - and as a team member would join such gatherings if invited - BUT - I would also make very sure not to bill for the time.

Since it is Sunday - I'll share my best over-billing story. About 20 years ago the consulting house I was working for was called in to recover a project where the prime contractors had been fired. We couldn't understand why all the programs were so huge. 10s of thousands of source lines in every program. Turns out that the programs were developed and tested using COPY members for all file and working variable definitions. But because the vendor was being paid by the line of code, when it came to handing a program over to the customer the COPY definitions (needed or not) were all manually copied into the program source. Part of the reason that the system was such a mess was that the handover point was only the beginning of the customer test cycle. All changes made to fix problems were (you guessed it) applied to the individual program. And even when a problem recurred in other programs, it was fixed independently. Often with a different method! Took a team of four several weeks to get fixes to the copy books straightened out and then begin to sort out the rest of the mess. The customer sued the first vendor - but the contract was watertight and they quickly gave up - but they never signed another "lines of code" contract!

Jon Paris

www.Partner400.com
www.SystemiDeveloper.com


------------------------------------------------------------------------


No virus found in this incoming message.
Checked by AVG - http://www.avg.com Version: 8.0.176 / Virus Database: 270.10.16/1926 - Release Date: 1/30/2009 5:31 PM