Jonathan, the information you provided was very valuable and offers a lot of insight into not just the financial aspect of billing for services provided but the "lifestyle" portion of doing custom development work.

You approach and attitude to this topic was very refreshing!

Thanks for the contribution!

Sincerely,

Matt Petrowsky

A few people have sent questions and comments about this podcast to me directly, which is nice, but I would prefer if people would post here so everyone can benefit from the conversation. I'll be checking back frequently and look forward to your feedback. Thanks!

I just finished listening to the interview. Interesting points of view - some I agreed with and some I didn't.

I can see how this type of billing would be successful when you are a lone developer and on projects of moderate size but I struggle with seeing how it could be deployed effectively when you are dealing with an office of developers. Seems to me the risks and variables only get compounded under this method.

I do agree that clients would love it but it feels too much like an open checkbook for the client with somewhat "squishy" as you put it completion objectives.

As with any project/value based pricing model objectives have to be clearly defined and some of the examples you mentioned like improved company morale and 50% reduced tech support calls are not very good examples of that. Good sales tools but pretty flimsy and riddled with other variables that you won't have control over and overall I'm not convinced that this is a good measurement to determine whether or not you get paid.

Find out what your client wants and give it to them is often a good theory to follow in many business situations and I truly believe it would be an easier sell since so many other things are purchased in this way. Seems to me mortgage brokers and Wall Street found out what their clients wanted and gave it to them and that didn't work out so well.

In practice, a project/value model sets up a win-loose scenario. Either the developer under bids a job and is working for an hourly rate that may not sustain the company or the developer or they finished the job in fewer hours than they anticipated in the estimate and get paid a ransom for their work - which in my mind equates to overcharging a customer - even though they may feel it is worth the cost.

The truth is there is no perfect solution. Both methods have problems but it is Productive Computing, Inc.'s experience that tells us that the method that is easier to run and manage profitably is the hourly model. Even when you are billing by the hour you are still required to setup expectations and draft objectives that measure your success. The difference is that both the customer and the developer should share the responsibility to manage the project and its costs and I believe this is fair since most of what we are doing is invention which requires flexibility from both parties.

Perhaps the bigger question is what expectations are you setting up in the beginning of the relationship? As long as those expectations are being met and exceeded you will have a happy client and the billing/estimation process has to be developed to support meeting those expectations and guarantee making a profit every time.

Very interesting topic and I really appreciate the time you have taken to share your thoughts and processes. It is through this constant sharing of ideas that we can all take away something to help us develop our own blueprint for success.

Thanks!

Keith Larochelle
CFO
Productive Computing, Inc.

Hello Matt and Jonathan!

I really enjoyed your podcast on value-based billing. My clients, of course, would love it! I would love the 100-percent-customer-satisfaction aspect, as I hate to say things like, "Sorry, adding that functionality would be outside our original scope of work," or "Sure, we can add that, but it's gonna cost you."

In spite of the possible drawbacks, I'd like to try out the value-based billing as Jonathan suggested: on a small project with one client who really knows what their objectives are.

Thanks for sharing this information.

Always Thinking the Best for You!

Audrey

I highly reccomend developers listen to this. Great points were made by both Jonathan and Matt regarding billing methods. Also, anyone that's on the road a lot should have a wireless card. The ATT card has a faster top speed but in far fewer areas. The Verizon cards ( USB-dongle ) seems to be fast enough and in far more locations.

Keep up the great podcasts. I'd love to hear FMT podcasts with an IT slant as well. FileMaker Server, networking, servers.. things like that.

regards
Scott Karch
Facility Wizard Software

Hi all -

There is a thread going over on the awesome Joel On Software blog that is relevant to this discussion. If you are interested, here's the link:

Joel On Software

Cheers!
j

this is a hot topic for me as well and was pleased to hear you guys talking about it. i've been doing value-based pricing for a long time now and my clients and my wallet are much happier. but there was a single event in my career that made me see the light officially.

i did an AppleScript automation development gig for a used car catalog. during the evaluation stage we came to the conclusion that this system i was building would save them approximately 80,000/year. this job had some particulars that i hadn't dealt with before and i wasn't confident in giving a solid development time estimation. so i went out on a limb and charged them 25% of the value of this product for one year, $20,000. the system took me months to complete and was not easy. but that wasn't the part that sold me on flat billing. about a year later i had another potential client come to me with an almost identical need, this time it would be saving them about $100,000/year. long story short, i charged them a flat fee of $25,000. i was able to reuse about 90% of my code from the first one and i had the system up and running for them in a week.

one week. $25,000. i haven't looked back since. and they couldn't have been happier, they are still a client to this day.

bottom line is putting time constraints on a job puts pressure on everyone, and creates a level of distrust, even if at a subconscious level. you work is worth what it is worth, regardless of how it got there. it's not for everyone but i simply can't recommend it enough. great podcast!

one more thing to add is that the only place where i've found flat billing not to make sense is in one-on-one informal training gigs, basically b/c there is no way for them to know what they want as a finished "product". they may be totally new to what i'm teaching them and after seeing it for a few hours, they may decide it's not right for them and move on. in those situations i allow folks to purchase my time in pre-paid chunks. that said, i offer things like full day training classes or a complete ground-up full blow "master class" for a flat fee. the "product" in those cases is them walking out of there knowing what they want to know.

ok, ONE more thing.

just wanted to iterate that throwing around dollar amounts in my above comment was not meant to um, throw around dollar amounts for the sake of doing it. i can see how that might be seen as obnoxious. it's totally not something i normally discuss, especially in public. but i thought it a good way to illustrate the situation that convinced me to make such a move. i was young and quite broke when i made that business change and it was a huge wake up call that i feel lucky happened back when it did. for the record, i haven't had anything that lucky happen since. it was a very right place, right time situation. just wanted to make sure i wasn't trying to come off as some kind of high roller who rakes in the big bucks on the regular and brags about it. i'm a solo operation and eek by like any other freelancer out there. =)

Very interesting stuff. Very compelling case study. Value based billing and similarly project priced billing do sound like they have advantages - especially the "big payoff" when you can leverage existing code to increase your hourly rate to accomplish the job.

Have you encountered problems where the client isn't honest with describing how much the project will save them? If they know that what they say will impact the cost, wouldn't it stand to reason that they would low ball its importance?

Keith Larochelle
CFO
Productive Computing, Inc.

I couldn't agree with you more on your expectations comment. The value of any product or serice is what the customer agrees to pay for during the estimating process. If projects come in more than what is agreed then there is always some level of discomfort experienced by the customer.

I also really like the idea of finding out how much money a project will save or generate for a client. This is a very valuable piece of information for the sales guys to know no matter how you price the job for the client.

Keith Larochelle
CFO
Productive Computing, Inc.

In case it isn't already clear, I think I should point out that there are two things going on with my approach:

1) I give the client a fixed bid for a project.
2) I base the project fee on the value to the client, rather than the cost to me.

It would certainly be possible for someone to do #1 without #2. I wouldn't recommend it, but it is technically possible.

i agree. i haven't had a situation where the value to the customer wasn't either A: totally obviously clear or B: totally UNclear and wondering why they are even calling me.

i've told more than a few potential customers that their problem isn't the workflow thing they want me to fix, but rather a level up with some overarching bottleneck that i simply cannot help them with. sometimes it takes outside eyes to see a problem.

haven't had anyone try and hide something from me. typically my scenarios are just as Jonathan described above. they come out and say we're paying this many people this much money to do this silly manual task, can you fix that? sometimes i can, sometimes i can't. i make it a rule to never apply "bandaids". if i can't offer a real sustainable solution then i'll humbly offer my advice and happily offer to come back later.

i also agree with Jonathan's comments from the podcast where he talks to the effect of; the client should not be dictating the project. if the client knew how to accomplish what they wanted then what the heck am i there for? the only thing i ask of a customer is "what do you want out of this?". it's up to me to figure out the how, why and technicalities.

in my experience, a client who does not have to hear, think about or try to understand technobabble is a much happier client. if they have some kind of in-house IT i make friends with them if i need to. my goal is to understand what they want and walk away. the next time they see my ugly face should be the day i walk back in with a working solution, flip the switch to ON and watch them smile. my 2 cents, ymmv.

I have been making a push for value based billing at my shop but my argument tends to center around concrete requirements. Are you putting such a focus on customer satisfaction that you are not concerned about scope creep? Do you simply push all new feature requests to the next phase?

How do you bend with out breaking?

there is no creep. as far as any potential "features" go, i give them a few options to choose from. based on which package they want, any included features are detailed and agreed upon. if i'm halfway through and they suddenly just remember the most important feature in the world then i'll do the only safe thing at that point and tell them "maybe later." i've tried to add in features in the middle of development and its bitten me pretty bad.

had a customer think of something pretty cool they wanted to add into a solution when i was about 90% of the way through. not only did i agree to add it, i got all excited about it with them and went on and on about how much power it would add to the system. long story short, 2 days of work later and i simply wasn't going to be able to make it happen alongside all of the code i'd already written. there was no way without redoing half of my work. had to do the walk of shame back to them and tell them i couldn't do it. it was a huge drag.

since that, i never, ever wedge in features during development that weren't part of the original plan. it's just not worth it. anything new definitely gets pushed to a *possible future revision. i say possible because sometimes it isn't. i never promise. i always say "maybe later". then when the time comes we sit down and thoroughly review it and if its possible it becomes a new project and if not then too bad. if you don't bend, you can't break.

Wow, I can't believe how similar teej's experience is to mine.

My stock reply when a client comes up with a "dealbreaker" feature in the middle of a project is:
A) I'll put it on the v2 list (i.e. version 2). Once you feel v1 is done, I'll quote this feature and any others on the v2 list for you.
B) Yes, that's a sweet idea, but if it was really that critical you wouldn't you have thought of it earlier?

The nice thing about the v2 list is that it gives the client incentive to agree that v1 is in fact done so we can move on to v2. Frankly, I can't remember a time when anyone has ever moved on to the v2 list. Not once.

It's worth mentioning that before the project starts, I make sure to tell the client that I consider it my job to keep the project on track, even if that means saying no to them along the way. That way, when I have to invoke the "That's a great idea! I'll put it on the v2 list and quote it when we are done with v1," comment (which happens at least once on most projects), they are always cool with it.

It's also worth mentioning that my "spec" is very high level - focused on overall business goals and the most critical (i.e. obvious) use cases. Nothing nitty gritty - talking about the details in advance is a waste of time for everyone - it's either just hand waving or takes longer to nail down than to build.

I am all about releasing working code early and often and using it to define the project as it reveals itself to the team. I guess I fall into the XP or Agile camp in that sense, although I don't think of it like that. For example, when I have a question whether I should build some feature this way or that, I just pick one and build it. If the customer doesn't like it, I say "Well, I could also do it this other way. What do you think about that?"

In the past in this same situation, I'd have picked up the phone or typed up a long email with screen shots and mock ups of both options... total waste of time for me and the client. It takes less time to just build the thing twice. And, you end up bugging the client less because you have fewer questions. Best of all, they usually will like what you did in the first place, so you've save you and them a ton of time. Win, win, win...

:-)

this discussion is just awesome. ha, when i heard this podcast in the car i thought "yes! i'm not alone. and i'm not crazy." and speaking of saving time; a good friend of mine is a pretty hardcore PHP guy. he builds fairly large custom e-commerce systems. after hearing this interview i had a nice 2 hour skype chat with him, and demanded he listen to this podcast. i think he's seeing the light. Jonathan you definitely got him thinking, thanks! you're a much better speaker than i am. our summarized conversation...

so he builds these monster PHP shopping carts for people. he codes each project by hand, from scratch. every time. i asked why he doesn't reuse code. his reply: because i charge by the hour. they want a custom solution so i build them one from scratch. takes longer, therefor i make more money. --and that grand total of all your hours a month later; would that be an outrageous amount to ask for if you could deliver the same solution in a week? his reply: ha, no! if i could turn over that kind of cart in a week i should charge twice as much. looooong silence, followed by a few expletives. =)

if you can give your customer a killer solution in even less time, that is seen by them as a major value ADD. especially if its something mission critical. imagine planning your business launch around a 2 month wait for your shopping cart to be built, and then find out it can be done in 10 days?! the words "pleasant surprise" come to mind. they are now launching their business a month ahead of schedule and you're the golden boy who made it happen. it's definitely a win-win.

i'm lucky enough to be in a market where reusing code is easy. i assume there are some out there, maybe in compliance audited situations or something that might not have that luxury?

a few questions for the hourly billers out there: do you purposely not reuse reusable code or resources and go from scratch simply because it adds hours to the job? it's not a negative thing, seeing as that's how you get paid. it makes sense to do so. or, do you indeed reuse code so you can whiz through a project and knock it out quickly to free up time for more work? that also makes sense. now, would it make sense to reuse code, whiz through the project and charge the same amount you would have for doing it the long way? i'd be interested to hear from some people who know that their clients wouldn't go for it, and why. there definitely are plenty of folks out there that can't possibly see something being valuable if it's not complicated or didn't take a long time to build. i'd really like to start preparing dialog for when we do encounter those people. i've been lucky, my customers love the fast delivery. but it's bound to happen at some point and i'd like to be ready for it.

as an aside, i have an observation. of any of the many types of developers i know and work with, by far FileMaker devs seem to talk about "feature creep" more than any others out there. it's so flexible that entertaining those creeping features is not only possible, it can actually be fun! the stuff i have to work with is way more rigid. i have to admit it secretly makes me jealous that i don't do more FileMaker work. it is a damn fun platform.

PS this book is where i first ever got the idea for not charging by the hour: i read it right before that first big scary project where i bit the bullet for the first time and flat billed. it was published in 2000 so the chapter on computers is actually pretty funny now. but there is still a bunch of great info in this thing. i still thumb through it every now and then. dirt cheap, i recommend picking it up.

http://www.amazon.com/Getting-Started-Consulting-Alan-Weiss/dp/0471384550

http://www.amazon.com/Value-Based-Fees-Chargeand-Ultimate-Consultant/dp/...

ooh nice, never heard of this one. ordering now! i really like this guys writing. i usually find reading anything from "guru" types to be tough getting through but Mr. Weis makes it all rather enjoyable.

another thing i haven't mentioned that is a huge plus for me; i find project billing to be a major productivity enhancer. seeing a nice lump sum in the potentially near future really tends to light just the right kind of fire under my butt. i found it also really keeps me on super high quality alert. you are putting your money where your mouth is and i find it becomes more crucial to get it elegant and right the first time. the result is a nice mix of fast but meticulous work that i'm not sure i'd get another way. that can be totally psychological on my part but it works so i'm not going to fight it.

Jonathan, i'd like to bounce something off you. i do a lot of training, mostly one on one sessions for a particular CRM application. can you envision any way to apply value billing to these gigs? it's the only thing i still charge time for. the goal or "product" is fairly clear. the customer wants to either master this application as a whole, or some particular advanced functionality of it. the problem, or should i say my fear, that's keeping me from flat pricing these isn't that i don't know what it's worth. i do know quite precisely what it can do for them. instead, i think my fear is that there is no real way to determine how difficult it will be to get them there. my training clients range in technical prowess anywhere from sys admin to thinks-AOL-is-the-internet. my immediate gut response is "shut up and be a great teacher and they'll get it." but sometimes it just doesn't work out that way. the only thing i could think of might be to do some kind of free consultation where i can try to get a decent idea of how it might go? even still, just because i think it will take someone a few sessions more to get it that doesn't mean it's of any more value to them and i don't feel i have the right to charge them more money. but at the same time, that's time i could be getting paid in full for a single session with someone else. i've been totally hung up on this forever. it's the only place where i see my time equating to value, and its purely because i get so many calls for training. there are weeks where i spend all day, every day just going from one session to the next.

would love to hear your thoughts on this.

Teej wrote -

i found it also really keeps me on super high quality alert. you are putting your money where your mouth is and i find it becomes more crucial to get it elegant and right the first time. the result is a nice mix of fast but meticulous work that i'm not sure i'd get another way. that can be totally psychological on my part but it works so i'm not going to fight it.

I couldn't agree more. I've had the same experience. And you don't have to interrupt yourself to track your hours in the process ;-)