Tuesday, October 07, 2008

Is the Hourly Model Broken? with an answer.

I answer sogrady's question "Is the Hourly Model Broken?" thus:

I look at things this way:

All money (the whole of all the cash available today worldwide) is the future value of monetizeable labor (ml). This in turn is the product of human effort (he), skills (s), and tools (t). For this nifty equation:

ml = he (times) s (time) t

Note that there is no "time" element. It is assumed in the "human effort part". Also, skill includes knowledge.

(skill is a multiplier, so unskilled but not impaired: skill = 1)
(tools is a multiplier, so untooled but not impaired: tools = 1)

Note that tools include material (such as ore, wheat, flour, paper, whatever) and actual tools (computers, hammers, image-editors, trucks and airplanes, etc)

Note that skills include physical and mental abilities, as well as knowledge.

Now, tools are bought my monetized labor, so this creates a recursive equation:

tools = ml = he (times) s (times) t

and eventually leads to

tools = ml = he (times) s

So ultimately tools can be reduced out of the equation.

Which means money is human effort multiplied by skill.

Now, human effort is the activity that performs an output.

Skill is something that applied to human labor allows the reduction of the amount of time used to complete the activity, and/or increase the quality of the output, or even allow the output to be created.

For example, someone with poor English composition skills would take a very long time to write a analysis paper on Virtualization in 2008, regardless of the amount of effort expended. Someone with great English composition skills would be produce that output in much less time. Someone with no knowledge of computers, regardless of English composition skills, might never be able to produce the output.


The hourly model assumes a fixed skill level, and measures output in amount of effort over time.

This model is flawed for information technology because skill varies widely and a very skilled person could produce with very little effort (time) what an average person might take weeks to do.

So you need to stop thinking of "hours" worked, but rather of units of output. Since in the information age, you cannot readily standardize on what a unit is (A quip? A paper? A blog comment? A remark in a call? A reference to your company in the WSJ? Attending a conference?) you end up having to lump these things into "What Analysts Do" (conveniently initialized as "WAD") and applying an arbitrary measure such as hours for billing purposes.

I say create a new billing term such as Work Unit (WU). In your contract, instead of "number of hours included" put " number of Analyst Work Units included" and use those up as you go in the month, then summarize:

Work Units expended from 9/1/2008 to 10/1/2008

Blogging presence: 400
Conference Calls : 1600
Report Preparation: 2800
Report Delivery: 900
Direct converstations with Company empplyees: 800
Twitter: 700
Facebook: 600
Friendster: 500
Digg: 250
Press Releases: 2500
etc: 900
etc: 400
etc: 40

Then, you review that with the client. If they want you to do more or less of each type of category, discuss strategy, tactics, and adjust.

Try to expend all "available work units per month", or roll them over (to accumulate for big projects). Adjust monthly billing to client to reflect their usage.

Finally, don't go crazy on the minute tracking. Ballpark it. The analyst needs to be fair, but who cares if 8 blog comments are worth 320 work units? Are then individual blog comments each worth 40 points? Not really. One might be long and insightful and worth 250, the other 7 might be simple me-toos.

Makes sense?

3 comments:

Simon Stapleton said...

Chris when I first started freelancing in the late 90s the only time currency was the hour. Back then, nobody discussed rates in any other frequency. Now, everything is based on a daily rate or fixed cost. I think hourly rates are pretty much dead, but I think you've described a common-sense model that works. Perhaps it takes a while to get the estimation right.

artbuilders said...
This comment has been removed by the author.
artbuilders said...

Look, estimating jobs are simple... Most clients want a fixed bid. Based on their needs, you come up with a number. Unfortunately it's rarely more than 50% accurate since the client controls much of the cost as a result of content and feature requests. So experience dictates that you should instead offer a price range. Clients will assume the top-end of the range and you will charge it. So you might as well go back to a fixed bid. The math then becomes simple... what will the client pay that won't won't cause you to lose your shirt? Inevitably some jobs you will lose your pants as well. So what's the alternative? Find those rare clients willing to pay hourly. It's probably the most fair way to go for everyone involved. However, that will lead to feelings that you are back in an office punching a time clock (which is not why you went into business for yourself). You are now down to one answer... throw out your best guess and hope the client is still smiling (or pack it up and go work for Developer-Mart ;) See... simple.