hi everyone,

As some of you know, I retired a couple of years ago from the Defense  
Department and have been volunteering my time the last year and a  
half developing a pretty good size web site in Plone for a non-profit  
here in town.  Well, now it seems some other organizations have seen  
the site and may want to actually hire me to do similar work for  
them.  This is great, but I don't really have a clue about this  
consulting/contracting stuff.  I know there was a ZPUG meeting about  
this a while ago, but I wasn't able to attend and can't find any  
notes about the discussion.  Anyway, any and all help/advice are  
greatly appreciated.  Questions I immediately thought of -

* How do I estimate the time it will take for the work?
* How do I do a cost estimate?  What are the parameters?
* What's a reasonable rate to charge for Plone/zope development?
* What techniques do people use to better understand customer  
requirements?
* What are the different types of contracts?   Are there some  
boilerplates available?
* What legal actions should I take?  e.g. incorporate?
* What's a good way to plan for the transition of the site to the  
customer?

Thanks so much for any help you can provide.

Best regards,

David
==============================
David Diskin, david.diskin(at)verizon.net

I've been consulting doing DoD system engineering work since 2000.  I've 
also hired consultants to do development work, although not Zope/Plone.  
Some comments below...

...... Original Message .......
On Wed, 02 Nov 2005 18:47:54 -0500 David Diskin
<david.diskin(at)verizon.net> 
wrote:[...]

Unless the requirements are very well developed, you really do the worth a 
darn.  Software cost estimating is at best a black art.  I've yet to see a 
formal method that reliably works better than experience.
[...]

Depends on what you are delivering.  Hardware is easy.  Non-labor costs 
aren't to hard.  For what you are doing it's going to be almost all labor.
[...]

I've got no idea.  In other markets I've seen more consultants fail for 
setting their rates to low than to high.
[...]
[...]

Pretty much the same as in DoD, but cost plus is very rare.  Mostly it will 
be either fixed price or time and materials.  

Unless requirements are very well understood, fixed price is risky for both 
you and your customers.  T&M often throws people, but generally I think 
it's lowest risk for everybody.

I've worked based on everything from a handshake to pages and pages of 
heavily lawyered paper.  It'll probably depend on each customer.
[...]

For an individual there are some tax advantages to incorporation, but the 
main reason would be to protect your personal assets if you were sued.

You should also evaluate the licensing strategy you use for your code.  
Unless you make specific provisions it'll probavly be considered a work 
made for hire and your customer will own the copyright on the code.  This 
would make reuse in future projects problematic.
[...]
internal experise or contract that out too.

Scott K

On Wednesday 02 November 2005 3:47 pm, David Diskin wrote:[...]

David and all--

One thing that I brought up at the meeting in question was that we _not_ use 
ZPUG's resources (lists, meetings) to discuss our prices or "good" prices or 
anything like that; many user groups feel that this is a legally-risky 
consideration (for a good discussion, see 
http://www.sfwow.org/pages/join/pricingdisc.html)

So, please -> feel free to give David pointers, but, please, don't open us
up 
to the risk that we, in any way, reduced the competitiveness of DC's pricing 
for Plone developers.

- j.

On Wednesday 02 November 2005 3:47 pm, David Diskin wrote:

(With my earlier, "no prices"! message out of the way, David, I can now answer 
your real questions ;) )
[...]

For biulding a "Plone site", I usually try to break things down into:

- how many different types of content do they need? (estimate a few hours, at 
least, to build each archetype and make a skin for it)

- how different are there look-and-feel needs from the standard Plone install?

- Do they have any unusual requirements for workflow, additional software, 
etc.
[...]

I break contracts into phases, depending on the job, like (for a simple job):

Phase I: Planning
Phase II: Custom content type creation
Phase III: Skinning
Phase IV: Installation on their server

I then give hourly ranges (expected to maximum) for each phase. I promise them 
I won't go over the max amt for any phase w/o their agreement, in advance, in 
writing.

[...]

In my experience, people pay no attention to "data diagrams", UML, etc. You 
can show them those, they'll nod, but they'll pay no attention.

Much better are simpler things that people can understand--an HTML form that 
is just plain HTML (no functionality or skin) but that shows the fields you 
expect to collect for a custom content type is 1000x better than showing them 
a data dictionary; your users can viscerally experience it and will notice 
missing things ("Can we add a middle name field?") which they'd never get 
from a data dictionary. It should only take ~1 to make these forms for most 
sites.

Failing that, I've been known to give people paper-and-pencil sketches of 
forms; even that, I think is better than a geek-oriented medium.
[...]

I'd suggest you work on time and materials. Fixed price contracts immediately 
pit your interests against your clients; I find them to almost always be 
unpleasant. Happily, I haven't taken one in years.

Generally speaking (just my opinion here), you shouldn't worry too much about 
contracts--clients that you want to write a complex, legal contact for, you 
probably shouldn't take as clients. I've been a solo for ~5y now, never 
written a contract more than 3 pages long, never had to call a lawyer once, 
never had to demand payment. Pick your clients carefully, trust your 
intuition, and spend less time worrying. ;)
[...]

You can form an LLC. Myself, I find this a bit of a tax dodge--I operate as a 
consultant, not as a company.
[...]

Whenever possible, build the site on your machine (so much more fun to develop 
on your laptop/desktop than across a network!) and give it to them in 
intervals, then at the end.  My Best Practices tutorial in New Orleans 
covered some of the technical details on that.

HTH, and best,

- j.

I'd be happy to get private emails off the ZPUGDC list if they  
discuss prices.  Thanks for the head-ups on that.

David

On Nov 2, 2005, at 7:25 PM, Joel Burton wrote:
[...][...][...]

==============================
David Diskin, david.diskin(at)verizon.net

There are a few books on software estimating.  The best technique is to use
function point analysis, but more tied to use-cases than to function points
per se.

The only ACCURATE way to do this though is to take your estimates, look at
the proposed functionality via use-cases, then capture the actual
functionality, gather lessons learned and put it against your proposed hours
and actual hours.  You do this over time - many projects and eventually you
get a feel of what an estimate should be.  This is practically a necessity
for developing fixed price contracts.

I saw Joel's phase split:  I use a more traditional viewpoint to some degree
- gathering requirements, design, develop, system testing (which itself can
have several phases), and installation.  Parallel processes are project
management, training/documentation development.

If you are using an agile methodology, you will have an overlap with design
and development.  I show testing as a separate phase - this is essentially
testing after everything is together and you conduct the tests you think
necessary - load testing, functionality testing, acceptance testing,
security testing, etc.  This is entirely different from unit testing that
your developers should follow and I HIGHLY recommend you have test plan
based on the design.

I would suggest though that you have a project plan and at least have a
clause that you will refine the project plan after gathering the
requirements and that will finalize the pricing.  If you are doing Govt
contracting, you are not going to get this luxury...

There, I spilled my guts on some of my techniques.  I actually am constantly
updating my webPrise methodology templates - it is something I have
developed after working for a portal and CMS company and now my current
employer.

I also sort of disagree with the UML/design docs to some degree.  I think
having those are essential if the client has large aspirations as more than
likely there will be a technical review.  If you are talking to smaller
(particularly non-Govt) organizations though, mock-ups are the way to go.

Best of luck to you in your start-up...  

Paul


-----Original Message-----
From: zpugdc-owner(at)lists.zpugdc.org
[mailto:zpugdc-owner(at)lists.zpugdc.org]On Behalf Of Scott Kitterman
Sent: Wednesday, November 02, 2005 7:21 PM
To: zpugdc(at)lists.zpugdc.org
Subject: Re: [ZPUGDC] Need advice/help on starting up consulting


I've been consulting doing DoD system engineering work since 2000.  I've 
also hired consultants to do development work, although not Zope/Plone.  
Some comments below...

...... Original Message .......
On Wed, 02 Nov 2005 18:47:54 -0500 David Diskin
<david.diskin(at)verizon.net> 
wrote:[...]

Unless the requirements are very well developed, you really do the worth a 
darn.  Software cost estimating is at best a black art.  I've yet to see a 
formal method that reliably works better than experience.
[...]

Depends on what you are delivering.  Hardware is easy.  Non-labor costs 
aren't to hard.  For what you are doing it's going to be almost all labor.
[...]

I've got no idea.  In other markets I've seen more consultants fail for 
setting their rates to low than to high.
[...]
[...]

Pretty much the same as in DoD, but cost plus is very rare.  Mostly it will 
be either fixed price or time and materials.  

Unless requirements are very well understood, fixed price is risky for both 
you and your customers.  T&M often throws people, but generally I think 
it's lowest risk for everybody.

I've worked based on everything from a handshake to pages and pages of 
heavily lawyered paper.  It'll probably depend on each customer.
[...]

For an individual there are some tax advantages to incorporation, but the 
main reason would be to protect your personal assets if you were sued.

You should also evaluate the licensing strategy you use for your code.  
Unless you make specific provisions it'll probavly be considered a work 
made for hire and your customer will own the copyright on the code.  This 
would make reuse in future projects problematic.
[...]
internal experise or contract that out too.

Scott K
[...]

Joel,

Hope you don't mind a couple of follow up questions.

1. When you give the hourly ranges for each of your 4 phases at the  
beginning of the project, I'm wondering how accurate this can be,  
especially if scope/requirements are refined or created as the work  
progresses - the usual story for software.  So, do you a review  
periodically of your estimates and provide new ones to reflect the  
better understanding of client needs?

2. If you could share a sample short contract with me (sanitized is  
fine  :-)   )  - that would be great.

3. My question about transition to the customer had more to do with  
long term maintenance of the site.  How does this usually work?  I.e.  
do you end up continuing the maintenance phase, do you try to train a  
client staffer(s) to do most of this, or do you bow out entirely  
after delivery?

Thanks again,

David

On Nov 2, 2005, at 7:37 PM, Joel Burton wrote:
[...][...][...][...][...][...][...]

==============================
David Diskin, david.diskin(at)verizon.net