Access JumpStart 2.0 | Blog

A Rapid Development Framework for Microsoft Access

A while back I was searching for an alternative to hourly billing (all I knew was there was either hourly billing or fixed cost billing). I wanted to see what others were doing out there. This led me to Jonathan Stark’s Hourly Billing Is Nuts series of articles and the concept of value pricing. Since then, I’ve explored and found other ways of pricing client work as well. I’d like to share 4 methods of pricing that I’ve seen. So in no particular order:

  1. Hourly billing (Rate * Hours): This seems to be the favorite of the industry. It is based on an hourly rate and the concept that time is money. It also is generally the way consulting companies sell consultants. The more qualified and experienced the consulting / programmer is, the more their time is valued and therefore they are more expensive per hour of work. The assumption is, they will be more productive. There’s a kind of factory mentality here. The customer is hiring a worker to do what they want and are willing to pay them for their time.
  2. Fixed Price billing (Cost plus margin): This I believe is the next favorite behind hourly billing. Typically a consultant will try to determine the features the customer is asking for, then determine a fixed cost based on their costs plus a margin of some kind. This generally includes considerations of time, travel, software tools, etc.
  3. Value Pricing: (10% of expected value): This flips the equation on fixed price billing by estimating the value of a business outcome to the client first and considering the price (10% is assumed to be a fantastic deal for the customer/client) they are willing to pay for that outcome. The consutant / programmer considers what they would be willing to do in return for 10% of the perceived value, and quotes a few potential options that they could do to move the customer toward their desired outcome.
  4. Agile methodology pricing (Fixed cost / Flexibile outcome): In this pricing model, the developer agrees to work on a project for a specified time period longer than an hour. Say a week. The customer’s needs are discussed and determined and the developer agrees to have working software by the end of that time period that addresses some of those needs. The customer can choose to discontinue the process at any time once they either have what they are looking for, or no longer wish to spend money on the project.

In future articles, I’ll begin to examine some of the pros and cons that I see in these methodologies.