[consulting] Lowball offers

[John Saward]

I have been reading the various contributions to this thread with high interest.
I think an appropriate stance to take together, as stake-holders, is one of learning together.

A bit of catharsis may have been necessary for each of us before we get to the point of seeing the opportunity here. I know it was for me.

We assume that we are on this list because we are, or we wish to be, or we wish to link up with - "Drupal Consultants". A consultant is the guy who takes a difficult situation and makes it work. Making it work will always entail some learning. The consultant needs to learn, because difficult situations by definition always entail some yet unknown pathways; the client has something to learn, otherwise why are they not already getting the results they want for the price they imagine is fair and why do they need a consultant?; the developer needs to learn, otherwise she will constantly be taking on work that delivers less than her own self-determined minimum hourly wage, catharting, and moving on to the next. 

And other stake-holders will also be invited to learn, when the consultation process is opened to those other parties.

Without the learning, and the delivery of that learning in such a form as to make it more possible for the client and the developer to have mutually happy outcomes, are we truly consultants?

Clearly some of us have emotions of not being appreciated for the work we do, I know I do: "It's like people think our skills are worthless". I have that initial response. It is not a useful or productive response to hold onto, even if true.

We move on, hopefully, and assume that the client is stating his offer honestly, and does not as yet realise the amount of work and skill and diligence and communication it will take to deliver the results they are expecting. We assume also that he does not yet realise the potential cost to ~himself~ of paying out the budgeted figure to a newcomer who herself does not realise how much will be involved, and in some sense eventually 'walk away' from delivering the expected. 

We might just assume that the client will go through a learning. We observe as others have pointed out, that eventually the work, or the fixing up after the work, or the rescuing from the train-wreck will come back to those of us who do know how much is involved and have the diligence to deliver to that. 

But can we just assume that learning takes place? Or does that learning need some support? And can the learning be sped up, or made less financially painful to each stake-holder?

Asking for the amount of work specified to be delivered for $1000 instead of {insert yr estimate || $10,000} is potentially a recipe for disaster. It is ~possible~ the client will get something like the result they wish for. A much more likely scenario is getting 20% of what they expected, some mess in the other 80%, and the developer becoming resentful because of the amount of work involved and becoming unavailable for further work, whether or not they receive the $1000, and whether or not they communicate that resentment. In that situation who is at fault? The client for expecting to get more than reasonable for the amount they are willing or able to pay? The developer for promising what they cannot deliver for a reasonable, acceptable remuneration? Or the community for allowing this sort of situation to arise again and again across the globe, every day?

Or is it just the way things are and have always been and will always be?

I for one would be very open to joining in an audit/reporting/learning process on this particular job. Why cannot a group of us take it on as a case-study? What would that mean? Well, of course that is yet to be decided. As consultants we consult and advise with the client and formulate a process that would deliver the best possible results and learning to them and all other stake-holders, and be fed back into the community as open-learning on this difficult issue, whilst keeping in mind that the immediate concern is a 'website that does x, y and z'. As consultants we are very interested to find out exactly what does happen when the client out of their own freedom of choice chooses to accept an offer of x to build a website that will take x-to-the-power-of-two amount of work for the developer to deliver. What happens next? who learns? why and why not..... where are the case studies of this painful process and learning already? I only find case-studies of the successes.

I'm perhaps willing to put in some free time on this audit process because it fits in with where my own personal learning wants to go. I am not offering free time for sourcing of developers or project management or identification of solution pathways or analysis or answers to technical questions or technical implementation or configuration or programming. I want to see if together we can identify the learning possibilities here. If this particular project is not suitable I am open to considering working freely like that on another project that comes along.

I recognise it is a tall order for a client and developer to accept the degree of open-ness of process that such a study would entail. And we all know that when a process is observed and audited that observation in itself changes the results.... eg, all parties deliver their best when under audit scrutiny, and the train wreck is avoided because of the auditor's existence and reporting, so it possibly is a difficult area to research and study. But perhaps.. because difficult it is indeed a task for {thunderous applause} "TheDrupalConsultants" ;)



> 
> 
> On 11-03-22 03:32 PM, Tom Geller wrote:
> >> this problem will not go away.
> >
> > Is it really a problem? If these lowballers do a bad job, you'll get
> > the work eventually -- with a better-educated client. If they do a
> > good job, that means the market has shifted, and the rest of us are
> > charging too much
> 
> 

~
John Saward B.Sc.

Doing Drupal since 2005 - #1 Learning: "It's the conversation that gets us there."

www.also.com.au: - We've been here since 1997. We just keep on keeping on. Rebuilding periodically.
www.drupal.com.au - Project management, Drupal development, Customer support.

john at also.com.au | 03 5968 1541 | 0418 610 706
Skype: studioalso | FB: john.saward (personal) | FB: studioalso (business)
~


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/consulting/attachments/20110323/6050f257/attachment.html