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 -- http://mail.python.org/mailman/listinfo/python-list
