[Zope] Zope Credits

Andrew Kenneth Milton akm@theinternet.com.au
Thu, 18 Oct 2001 23:42:55 +1000


+-------[ di goodman ]----------------------

I apologise in advance for the wordy reply, but, I hope it serves as
an example of how to do these things in the future, in case anyone here
is thinking of starting a project, without knowing what they're getting
into. Some of this will help you even if you're building a house or getting
a new car, so let's go...

| I would like to be a Zope success story, but here is the situation
| (about which I appeal to you for help/zope hope)I am the owner of a 
| small trucking brokerage in Annapolis, MD.  We hired a local evening 
| programmer to build an internet brokerage weblication for us(his word).  
| After a full year and a half we are all on line today and it is failing 
| miserably.  We called in a reputable company from the area and they tell us 
| the problem is the platform.  Our programmer insists that Zope can support 
| our business and these are the kinks of a new use.  Who can I speak with that 

The problem is more than likely not with Zope. Zope itself is a very good platform,
and for something like you've (briefly) described should be more than adequate.

I have a driver's licence, but, that doesn't necessarily mean I can drive one of 
your trucks. This doesn't make the truck defective, it just means I don't have
the skills necessary for that particular tool.

| will vehemently defend Zope for our use since we have already spent all of 
| our money and too much of our time.  We think maybe there is a key that we 
| are missing.  

I will defend Zope as a web platform. I will defend Zope as the web platform
for you under the right circumstances. I don't think that the technology is to 
blame here. Zope is an outstanding development platform and deployment technology,
but, you still need to be able to drive it. Being a programmer doesn't mean
you can use every programming tool out there. It also normally precludes being
any good at project management d8)

| But, none of us are programmers, you see, which is why we relied 
| on the suggestions of someone who is.  We are trucking people, we use keys to 
| start things.  Thank you for forwarding this to someone who might help.  
| We are stuck in the driveway on this one.

You have a difficult decision to make. Do you go forward with what you have now,
do you invest more time and money in something else, or do you cash in your chips
and give the internet a miss altogether? You have already spent a great deal
of time and money on something that has not lived up to expectations. To be
brutally honest some of the blame probably has to lie with your company as well.

I am speculating now, but, let's see how we go;

o You left all the decisions up to the programmer, who wasn't managed.

o When pressured for results, he would either confuse you with jargon, or
  patronised you by telling you don't understand because you're not programmers.

o He could demonstrate something to you, but, only if he did 'driving' so to
  speak, and he could only show you small portions at a time.

o The programmer had no understanding of your business, and he accused you of
  not communicating your requirements clearly, or changing the requirements
  on him.

o You did not get a plan from the programmer and make him stick to it, nor
  did you allocate a fixed budget, or agree to pay on milestones.

Ask yourself these questions. Would you let one of your part time truck drivers
run your business? If you had a truck driver you didn't know, would you hook
up your bank account to his odometer and pay him by the mile, rather than
on completion?

The same principals you apply to your business, you should also apply to any
other business. Because you don't understand how it works, doesn't mean the
basic rules of commerce are any different. 

The best way I can help you, is to tell you how to go about doing this again
in the future, so that you don't get burnt (as badly). Given we're not talking
about some project that's going to be knocked over in a week. This has been
running 18 months, which is a fairly major undertaking.

Here are some basic rules for you (which are pretty standard for any enterprise,
but, are pretty crucial for programming projects). They are also fairly general,
circumstance may warrant slight differences, but, if it's going to take 18
months you owe it to yourself to follow most of this.

o Every project should have a budget.
   This means you know how much you are willing to spend, and how long you're
   willing for it to take.

o Every project should be managed.
   If you don't manage it, how is it supposed to go where you want it to go?

o Every project should have milestones.
   How do you know that what you're getting is what you asked for?

o Every project should have a clearly defined goal.
   How does anyone know what it is you want?

o Every project should have status reporting.
   Then you know how far along the road you are.

o Every project should be aborted when it becomes clear (from status reporting)
  that the milestones are not being achieved, and the goal cannot be attained.

Milestones for software projects should include;

o Some form of requirement specification, that you agree is what comprises the
  system. Once all parties agree, then you don't change your mind, and they
  don't shirk from giving you these. You need to understand what you want,
  and you need to be able to express this to someone who has no understanding
  of what you do, or what you want. Remember this, be as specific as you can.

o At least a design overview of how the projects works
  If it's larger, you should insist on a detailed design document with specifics,
  even if you don't understand it, you can take it to someone who can, who can
  verify that it will do what it says it will. It should also address which
  requirements are met by which components.
  This should at a minimum include the components that will be built, and
  a rough estimate of time for each component.

o An implementation plan.
  This should detail what order the components are going to be built, so you
  have some way of gauging what should be done by when. And you can then ask
  why progress isn't where it should be (there may be reasons, but, if there
  are you should be informed of these, without having to ask).

o Documentation on how to install, configure, and use the system.

o A test plan. You should insist on withholding final payment until it passes
  some type of acceptance procedure.

You should be willing to pay time and materials to get the design documents done.
This should involve the "programmer" meeting with you and drawing up the
requirements specification. You should expect some back and forth on this,
you may be asking for too much, or they may not understand what you want.
Once you have the Requirements Specification, you should ask them how long
it will take to draw up the Design Documents. Agree to a timeframe and
a payment for these.

Once they have completed the design documents they should be in a position
to give you a fixed cost quote. If they won't, you can take the requirements
and the design document to another software house who will. If there is some
major element of risk involved (using some leading edge, untested, technology,
and it absolutely has to be that way e.g.), then you may find that you 
will have to pay time and materials for the project. This is very very unlikely
for a web application. If all else fails you can put it out for tender, since
you already should have some specific documents d8)

If you're not willing to commit to a fixed set of requirements, you shouldn't
expect a fixed price. Even if you can't get a fixed cost quote, you should
be able to get an estimation on time. They can't claim it's totally unknown,
if they've broken the project down into components, they *must* know the time
it takes to build most of them, otherwise you might as well get your butcher
to do it.

Make sure you have a contract drawn up, and that it specifies that you own
all of the intellectual property rights, even to the documentation. Any lawyer
should have a standard form that covers this. DO NOT LET THE DEVELOPERS DRAW
UP THE CONTRACT. Make sure that your payment options are in there, be it
payment on delivery, by milestone, or time and materials.

If you can't handle doing this, then hire someone who can. Get them to find
the right people. Pay them a bonus based on how much it comes under budget d8)
Managers are motivated by money (and shiny things, but, we won't go into
that d8)

So the magic phrase is "Everything needs a plan."

-- 
Totally Holistic Enterprises Internet|                      | Andrew Milton
The Internet (Aust) Pty Ltd          |                      |
ACN: 082 081 472 ABN: 83 082 081 472 |  M:+61 416 022 411   | Carpe Daemon
PO Box 837 Indooroopilly QLD 4068    |akm@theinternet.com.au|