Charging for Value vs. Time
In most businesses, the answer would be easy - move to value/results based pricing. This is a little more interesting in the programming world because it is often hard to determine what the time will be to add a particular level of value, and clients often want to make changes that won't increase the value of the deliverable (and may even decrease it) but that will still burn your time and affect your costs.
Many programmers are moving towards Agile development methodologies. After trying a number of XP engineering practices and Agile project management approaches - from SCRUM to Lean I tend to think that agile is the most efficient way of adding business value to clients. However it isn't necessarily the best way to build a profitable consulting business because you're limited to charging by the hour.
We have an interesting hybrid model where our software product line allows us to generate an application very quickly and we deliver those apps for a fixed bid but then charge on an hourly basis for any tweaks the clients want (we also outsource the graphic design and the tweaking of the layouts when we can as those are the areas that can burn the most time in inconsequential changes).
It works quite well as we don't really want to work on an hourly basis so we do our best to keep the tweaking to a minimum and the client has control over how much the project costs. We guarantee to deliver something that meets the spec for a fixed bid so they don't have to worry about how long it'll take us to code a newsletter system or a custom content management system, but they have to pay by the hour for the tweaking at the end of the project so we don't lose money on picky clients - they just pay for more hours at the end in the tweaking phase.
What do other people do to get beyond just making an hourly rate (especially in a world where open source is replacing licensed software in many situations)?
Input appreciated!
One thing we have done are service packs. Prepaid hours that a client can buy ahead of time at slight discount. We can then do whatever tasks are allowed under that package and burn up hours as they identify. (for us it is templates, basic graphic service, content stuff, etc, no app dev). Great to get cash upfront and great for items that are unclear in length or lots of little things over a medium period of time. No need to get approval for little things each time, just use the existing service pack and make it happen.
The main issue I traditionally have with fixed price contracts is the expectations. Most clients don't understand that the cost of a project is controlled by them as much as us. How picky are they going to be? How quickly will they identify what they really want the app to do. You can write detailed specs, but they never cover everything and end up costing everyone a lot of time, so while I agree that many clients want a fixed bid, it often isn't in their best interests - especially in speculative/highly custom apps to give them one. It is however a good deal for the consulting firm. Hmmmm.
Using wireframes to define the pages is a great way to reduce the potential of project creep and can be put together really quickly before you even quote. This is much quicker than writing detailed specifications which most of the time the client doesn't understand.
You might be interested in a book called Spin Selling. It's all about asking questions to find out the value. SPIN is an acronym for "Situation, problem, implication, and Needs Pay Off".
I think a lot of programmer consultants focus on the situation / problem; without truly understanding the implications of the development.
I was partner at a company here in Brazil so I wasn't allowed to "rule", but with one project that I did everything - sell, understand the project, write it down and even helped within the developing part - it went really well and, most important, the client discovered that the project they wanted at first wasn't necessary at all. It was such a big "goal" that I'm trying to apply it to clients that contact me now that I'm freelancing for a while.
But let's face it and be honest with ourselves (and yes, I read the article you linked to as well) ... in the end, we all have an "acceptable range" in mind as to where we would "prefer" to end up on any given project. I say "acceptable range" because there is definitely a "low" end for each of us, whether that "magic" number is $50 per hour or $500 per hour. The problems always tend to arise on those projects where you just don't know how much time something is going to take too! Estimating the "unknown" is always tricky in our business, isn't it? Besides, from the clients perspective, how would you like to hear, "well, we think it'll take 40 hours, but it might take 80, so we'll charge you the 80 hours just to be safe." Then, what if the project goes out to 100+ hours?
Also, "value" could be perceived differently by you and your client. If your proposal is significantly higher than your competitors, then of course you should be bringing something more to the table (significantly more) than you competitors. Whether your "value" is "done right the first time" or whatever you define your "value" to be, then hopefully you're getting the opportunity to show that to the client. Unfortunately, so many prospective clients out there look at the bottom line. There have been a number of occasions when we've come in much higher on a project than our competitors. Sometimes we've won them and sometimes we've lost them.
We've recently been discussing changing up how we estimate a project by breaking them up into 2 different stages (an idea I "borrowed" from a fellow developer). The first stage centers around building a "static" prototype with HTML/CSS. So no major programming would really be done in the first stage. Then the second stage would be bringing the prototype to life. So, this would mean that I would actually hold off on designing my database, etc. until after the client has approved the static prototype. I've heard this approach referred to as "Interface Driven Architecture." I'm still trying to wrap my brain around how to get a client to go for this approach because we couldn't truly estimate the second stage until the first stage has been completed. However, if we could go with this approach, we would have a much better handle on the actual time needed to build it out. We're still toying with the idea.
Then again, maybe I'm just so entrenched in "hours" it's difficult to think beyond that. However, I don't think that thinking in terms of "hours" is such a bad thing. I still believe most of us have a "range" that we find comfort in ... so I guess thinking "above" that range could potentially be a first step in the right direction ...
I love our business. We get to think, and get paid for it ... I think.
Well, there's my ten pesos.
1. The client wanted a $$$ for the entire project, not step 1 is "$ x" and step 2 "we will see";
2. The client can't handle the "static prototype", 'cause it do not deliver real data interaction. In fact, I've had a project where the client can't say if everything was ok until we fed the database with <i>actual data</i> so they can compare to whatever they were using before.
Don't know if it's a "Brazilian problem" or if it's about everybody out there, but here, this approach doesn't worked, alone. But inside a given project I still do it to minimize the damages of changing input forms and things like that.
I use a similar approach where neither I nor the client really knows how they want their app to function and it isn't that hard to sell. I simply say that like designing a house, there's architecture and then building. If they say they know exactly what they want and don't need architect then I say "great, we'll sit down for a morning and you describe all of the tasks people need to be able to complete, step by step with the default, alternate and error paths and I'll get you a quote". When they try they often realize they DON'T know what they want and that is when I'll recommend a discovery phase. If they DO know what they want, it gives me the info I need to fixed bid quote so we're good anyway.
@Fernando, If you want to try a step by step approach, one way to sell it is as follows. Let me work with you to create the highest value user stories. I can either work hourly or give you a fixed bid, but that'll assume only two rounds of revisions, within the spec, so if you end up doing more tweaking you may want to put some more money aside for that. Then we'll have really valuable stories live and making you money. From there we can look at the next stories, I'll give you an estimate or a bid and you can decide whether or not they are worth building. Fact is you are never "done" with an application - you just hit a point where the next stories aren't economically justifiable. By going agile you just make that explicit, get working software quicker and lower the risk of the project as the client can make lots of smaller go/no go decisions rather than one big one.
Yes, it's actually Clark (and Ben) who I "borrowed" the idea from.
You also bring up some interesting thoughts here. I'm going to have to bring some of this to my AE and "brain rain" on this a bit. I really like the Agile methodology and actually find myself blending Agile with Waterfall in my projects anyway.
Thanks for sharing some of your thoughts and ideas here.
that being said, would it not be your responsibility to point out what is fluff and will cost a lot based on the time it would take?
one thing i have used when friends/family ask me about personal/business websites, i always tell them to go out and find something they like that does the things they want it to do... bring it back to me, and we can talk about how complex it is or what you want it to do different. i find this works pretty well for many reasons... the main being i'm not creative. i feel confident that i can do just about anything if i can see it though.
i would further suggest that it would help to know what they want to pay. i realize most folks wouldn't want to put that out there, as they would be afraid of being exploited. my suggestion for that would be having published pricing or at least provide a copy of contracts with itemized levels of complexity.
well... those are my thoughts.