[AccessD] The Polyp Problem

Joseph O'Connell joconnell at indy.rr.com
Thu Jan 20 12:53:09 CST 2005


Jim,

In the USA, if the contract does not contain specific language conferring
ownership on the customer, then the contractor retains ownership.  There was
a land mark case a few years ago where a shoe manufacturer in Mass. paid
mega bucks for custom software to run its business.  Six months later they
sued the contractor when they discovered that their competitors were using
the same software.  The judge ruled that since the development contract did
not specifically grant ownership to the customer, that all the customer
received was a license to use the software.

Karen's case is different.  She wants to disable the customer's right to use
the software.  If she does not have a legal right to do so, then she has a
potential liability for loss of business/profits by the customer.  Of
course, she should not have any further responsibility to continue to
provide services for which she will not be paid.  This is definitely a legal
question and a lawyer should be consulted before taking such a drastic step.

The discussion of when a client is worth retaining is very relevent to a job
that I just finished for a service company (not IT).  They wanted very
detailed analysis of services provided and revenue derived from their
customers.  After looking at the results they "fired" 1/3 of their
customers.  They found out that it cost more to provide the service than
they were receiving in revenue.  Unusualy, but they felt it was justified.

Joe O'Connell

-----Original Message-----
From: Hale, Jim <Jim.Hale at fleetpride.com>
To: 'Access Developers discussion and problem solving'
<accessd at databaseadvisors.com>
Date: Thursday, January 20, 2005 1:21 PM
Subject: RE: [AccessD] The Polyp Problem


<while you do own a program>
I presume you mean if the contract is silent on this point the programmer is
presumed to own the code. Are you sure? My recollection is last time we had
this discussion we concluded that, while this is generally true, it is not
universally so.
Jim Hale

-----Original Message-----
From: Jim Dettman [mailto:jimdettman at earthlink.net]
Sent: Thursday, January 20, 2005 10:55 AM
To: Access Developers discussion and problem solving
Subject: RE: [AccessD] The Polyp Problem


Andy:

  Great advice.  Part of the problem is that while you do own a program, you
don't own the data.  You can get yourself (so I've been told - I'm not a
lawyer) if you put a time-bomb in the program and don't allow a client to
access to their data.

  I've never stopped a program working for this reason.  If I had to though,
I would put in logic so they can't add new data. I've been very fortunate
over the years and only once have had to resort to the "you want work done?
then pay me what you owe me".  As you say, they fork over pretty quick if
they really need it.

  The other thing I've done that helps is that I bill everything by the
hour.  No flat fees and I invoice every two weeks. That way a lot of time
doesn't go by between payments and if their is a disagreement about
something that gets billed, it gets spotted quick as well.

  Karen: Really think if this is a client you want to keep or not.
Sometimes it's just not worth the hassle.

Jim Dettman


-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Andy Lacey
Sent: Thursday, January 20, 2005 10:36 AM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] The Polyp Problem


Hi Karen
The 'bomb' in the system sounds more of a legal question rather than a
technical one. You ought to get advice on how you'd stand if the system
stops and their company comes to a stand-still. I know they'd deserve it but
does the law agree?

In any case they sound like all-too familiar sort of customer. At some point
you have to decide on what YOU want to do next. Are they a customer worth
having for the future? I doubt it but if yes, you'll probably have to grit
your teeth and keep asking nicely for your money. If not then you are going
to have to stop them doing what they're doing, i.e. taking advantage. At
some point you just have to say that you are doing no more work and no more
support until you have been paid. And having said it you have to stick to
it. The first time they really need you, and you won't go, they will
suddenly find it perfectly easy to raise a cheque. It's not hard. The only
time it's actually hard is if they have no money - and if that's the case
bail out. But assuming you do get the August money are there more payments
due? If so you then have to decide if you're ever likely to get them. If
not, ask them for the rest of the money up-front, explaining that because of
past performance you've lost confidence in their willingness/ability to pay.
If they say no then consider pulling out.

I know it's easy to say, and hard to do, but you have to start saying 'no'.
We all bend over backwards for a new customer, assuming that if we treat
them right they'll do the same. When they prove otherwise it's time to stop
your side of that deal. If you do stay with the contract then at least stop
doing the extras. When they ask for a change quote them. If they won't pay
they don't get.

This is the downside of being an independent, and it's bloody horrible. FWIW
we can all empathise. But you just have to get tough with these b******s.

--
Andy Lacey
http://www.minstersystems.co.uk



--------- Original Message --------
From: Access Developers discussion and problem solving
<accessd at databaseadvisors.com>
To: accessd at databaseadvisors.com <accessd at databaseadvisors.com>
Subject: [AccessD] The Polyp Problem
Date: 20/01/05 13:14

>
> I know this has been discussed before, but I sort of removed a polyp
> from my client abuser list last night, as a woman has the right to flip
> out on deadbeats.  That is the law.  Here is the story.  Client
> contracts for a job; agrees to pay whatever way - some do in stage I,
> more in stage II and the rest in stage III.  It is clearly stated that
> changes to the requirements of the system will be discussed and
> additional invoicing will be required.  Polyp continuously *forgets* to
> pay invoices as that is not is department, makes wild changes to the
> system - "Oh, didn't I tell you?  Truck A, B or C can not go on
streets
> with a 2 Ton Limit?  You can just program that in, right?"  Or
emergency
> call - finger nail bimbo's system won't work and it is the hub.  Your
> system broke it, we can't function, come over here right now.  Drop
> everything, run over, and low and behold the cable is unplugged.  Three
> hours out of your day, gee thanks.  Oh, we can't pay you, it has been a
> bad year.  And that $2000 we still owe you from August?  That is coming
> soon.  Hello, it is snowing!
>
> In my warped world, I would like to put code in the program that when a
> payment is not received, the system stops working.  When the bill is
> paid, the user can have the encrypted password to keep working.
>
> Doesn't that sound easy?  One final password when the system is paid in
> full.  I know a geek could break into it and get around the password,
> but these people are cheap to begin with if they won't pay and not work
> continuing working for anyway.  Ideas?
>
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>
>
>
>
>

________________________________________________
Message sent using UebiMiau 2.7.2

--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com


--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com

***********************************************************************
The information transmitted is intended solely for the individual or
entity to which it is addressed and may contain confidential and/or
privileged material. Any review, retransmission, dissemination or
other use of or taking action in reliance upon this information by
persons or entities other than the intended recipient is prohibited.
If you have received this email in error please contact the sender and
delete the material from any computer. As a recipient of this email,
you are responsible for screening its contents and the contents of any
attachments for the presence of viruses. No liability is accepted for
any damages caused by any virus transmitted by this email.





More information about the AccessD mailing list