Tempering Client Expectations (OT)

[Tim Chase]

On 04/10/2010 11:10 AM, Victor Subervi wrote:
> Hi; I'm working with my first client where I've developed a
> custom script. I way underbid the project and I ate that as
> part of my learning experience. We outlined as precisely as I
> knew how what functionality was needed. Then he went to input
> data and lo and behold he needed more functionality. I told
> him that would require more investment. This went on a few
> times and now he's hopping mad about being nickeled and dimed
> to death.

hahahaha...shocked, I say, shocked!
</schadenfreude>

okay...with that out of the way...

> Any good articles out there (or other advice) on how to deal
> with a situation like this?

Given your track record, I'm not sure that even if folks here 
offer advice, you'll heed it.  But here goes:

1) Preeminently, address second-order ignorance.  Learn about the 
involved technologies before you consider proposing a solution. 
Had you taken the time up-front to ask any competent web 
developer "I'd like to make a web-application from scratch, what 
do I need to know?" they'd tell you to learn HTTP, HTML, CSS, 
Javascript, a server-side scripting language such as 
Python/PHP/Perl/Ruby, database/SQL technologies, and security 
best-practices (or they might question why you don't reuse an 
existing framework that already does what you want).  There are 
plenty of books & websites to facilitate learning *all* of these 
topics.  GIYF.  That list alone might have given you pause enough 
to say "woah, that's a lot, and all I know is a little HTML. 
Maybe the task of being a web programmer isn't as easy as I 
thought."  But, in the face of the daunting mountain of requisite 
skills, you opt to proceed...

2) Next, address first-order ignorance:  learn the requisite 
technologies involved in such a project.  Learn HTML, CSS, 
Javascript, how an HTTP transaction works, how to program well in 
your chosen scripting language, how to write SQL, and how to 
identify common security issues (OWASP puts out a good list).

This doesn't preclude you from doing paid projects for friends as 
you learn, but keep the funding down in the "buy me lunch and 
I'll tinker with your idea" range, not in the "pay me real money 
for a real application" range.  Make sure that the friend knows 
your level of experience (or lack thereof) doing what they want. 
  And don't fudge it with "I wrote this other web application" 
eliding the fact that said-web-app blew up in your face.  Be 
honest.  All artists need to master their tools, whether words, 
pigments, clay, or technologies.

3) When multiple professional-programmers on comp.lang.python 
face-palm and suggest you're doing something wrong or you lack an 
understanding, try listening and spending time to wrap your head 
around what they're saying.  Instead of dismissing with "I'm an 
artist, I can't understand that", STOP.  Let you client know you 
just stepped off the deep end, and suspend the project.  Hire 
somebody who does understand or take a class (this may cost real 
money).  But don't try and proceed in the face as your own 
non-understanding without first coming to terms with the issue.

4) Don't be afraid to reuse existing technologies:  could 
installing osCommerce on a $3/month web-server and tweaking the 
PHP code have sufficed for what you need?  Could you have used 
Django+Satchmo to get yourself up and running with proven code, 
tweaking what you need?  I remember you dismissing the suggestion 
to use existing web-frameworks.

5) Regarding scope-creep, it's a problem most developers & 
analysts face, but there are several mitigating methods you can 
use.  Experience from past projects helps gauge time for future 
projects and only your own experience will suffice.  If you don't 
have any past projects (personal deployments or school projects) 
you're not yet remotely ready to give estimates.  Even after 
you've done multiple projects, estimation is still as much an art 
as a science.

Also, get the client to sign off on basic features in very small 
bite-sized increments, addressing highest-priority needs first. 
If at any time the client sees a failure to progress at the rate 
they expect, they can pull the plug losing far less of their 
investment keeping the most important features developed 
thus-far.  Part of a developer/analyst's job is to get a good 
idea of a project's scope.  Examining all edge cases, looking for 
infrequently-used processes, probing exceptions, building a 
mental-model that corresponds to the client's mental-model...

6) As for "Tempering Client Expectations" (the subject line of 
this OT post), it seems the biggest gap involved not 
communicating to your client/friend "I'm using your project as a 
learning experience for multiple complicated technologies and I 
have minimal idea what is involved so there's no possible way I 
could give you an accurate estimate of scope or cost"

-tkc