"Howard Brazee" <howard@[EMAIL PROTECTED]
> wrote in message
news:rn1es3tmh3hfa5id1o6nohsctdpj76lmtb@[EMAIL PROTECTED]
> On Thu, 28 Feb 2008 12:33:46 -0600, Robert <no@[EMAIL PROTECTED]
> wrote:
>
>>Contracting companies routinely pay for billable hours; straight time
for
>>overtime.
>
> But I've done contract work where we had to post 40 hours of work
> regardless of how much over we worked.
What I have found to be a reasonable solution to this, certainly for more
intangible services like "consultancy"...) is to bill in units of
"professional days". For straight task oriented services like programming,
billing in hours may make sense.
I bill by the day, where a day is not less than 6 hours. My daily rate is
around the middle of the market; I charge less than IBM, but more than
some
consultancies. (I justify this by track record and a conditional money
back
guarantee. So far, I have never had to refund, but I came alarmingly close
on one occasion :-))
Usually, I do more than 6 hours (obviously, it depends on what is
needed...), occasionally I will do much more than 6 hours, and sometimes I
do the 6 hours. Some days I provide value that is many times more than
they
have paid me; other days I don't. Overall, I deliver what I promised
them,
in the time I promised them. By billing in days, it is much easier to
budget
(for them and for me), but, much more importantly, measuremant can be made
against goals achieved, rather than hours worked on tasks.
Goal orientation is much more important than task orientation and I
discuss
why this is in the book I am currently writing and which is now
approaching
completion. Each day, on arrival in the office, I set myself goals to be
achieved that day. (They are usually a subset of the things required to
achieve the overall goals which have been decided by the project team.) I
don't go home until they are achieved, or I am satisfied that nothing more
can be done right now.
When projects are task oriented, measurement of progress tends to be in
terms of hours worked on various tasks. This is patently silly, and reeks
of
a management mind set that doesn't really understand achievement.. Until a
goal is achieved, no amount of hours worked mean anything.
(It's a bit like the principle of Physics which says that you can apply as
much force as you like to an object, for as long as you like, but until it
moves, no "work" is done.)
If work is estimated and planned properly (and I know this is not often
the
case...) there is no reason why anyone should need to work overtime.
Timeboxing tends to clarify the mind with regard to goals and time
available.
On my projects, people work overtime only when they screwed up and need
to
repair something. I never ask them to do so, and I don't pay them
overtime.
When teams achieve goals there is a celebration, and I often pay for this
out of my own pocket if the corporate culture is such that they won't. On
a
few occasions, Directors, seeing how successful this approach can be, have
picked up the tab and rethought the company policy. Rewards and incentives
for achievement are better for all concerned than requiring overtime and
then resenting having to pay it.
Pete.
--
"I used to write COBOL...now I can do anything."
|
