Tempering Client Expectations (OT)

[Victor Subervi]

On Sat, Apr 10, 2010 at 3:14 PM, Tim Chase <python.list at tim.thechases.com>wrote:

> 1) Preeminently, address second-order ignorance.


Tim, throughout this post, you're way out of line. The s/w I have already
built for this client works just fine. It's not a matter or not having the
tools or not knowing how to use them. Pay attention to my question, don't
make up your own based on your own inaccurate assumptions and answer those,
please. Stick to the topic.

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.

<sigh>
Bringing that up again, are you? I was all but done with the shopping cart
when you suggested I re-invent the wheel based on another technology. Yeah,
sure, throw out 10,000 lines of the 12,000 line program so I can rebuild on
a new technology. Brilliant, that. Thanks for the suggestion. Now, can we
get back to my question?
</sigh>

>
> 5) Regarding scope-creep,


Yeah, that's where we should have been all along, Tim.



> 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.
>

Obviously.

>
> 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...
>

Now you're talking.

>
> 6) As for "Tempering Client Expectations" (the subject line of this OT
> post),


Ah, so you *did* recognize what *my* question was! Good!


> 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"
>

True. I ended up taking a bath on it, and I believe that was merited since
it was my first client project. Now, I'm dealing with scope-creep and trying
to work my way out of it, and looking ahead at how to avoid complications
like this in the future.
Thanks,
beno

>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20100412/bd2e0a51/attachment-0001.html>