If your 3rd party vendor has such a slack development process that they don't automatically incorporate fixes into their own upgrades, I'd be looking for another (better) one asap.

Todd.

Jeremy Coulter wrote:
 Yes this is right, its the big picture thing.
The thing is, we pay $8k a year (waisted in my opionion) on upgrades, so you think they might be less inclined to charge :-) Jeremy
    -----Original Message-----
    From: "Paul Heinz" <[EMAIL PROTECTED]>
    To: <[EMAIL PROTECTED]>, "NZ Borland Developers Group - Offtopic List"
    <offtopic@delphi.org.nz>
    Date: Tue, 6 Nov 2007 13:42:03 +1300
    Subject: RE: [DUG-Offtopic] what are your thoughts about this?

    Jeremy asked:

     > Anyway, we have recently upgraded to the latest version of
     > their product, and now the custom search code does not work,
     > and they waht to charge us for fixing the problem.
     >
     > Now, to my mind, when I do say a custom report and I change
     > something in the exe and release a new version, and it breaks
     > their custom report, its up to ME to fix it, and not for the
     > customer to be charged for it.
     >
     > So in the ace with our CMS vendor, what doe people think? Am
     > I right in thinking that it should not cost us anything
     > because "they" essentually broke it and never tested our
     > custom search etc. ?
     > OR should we pay?

    Well, this question has both an economic and a moral dimension.

    If you don't pay, then your vendor is essentially doing unpaid work.
    Vendors who unconditionally accept doing an unbounded amount of unpaid
    work don't tend to stay in business in the long term. Be careful what
    you wish for, you just might get it :-)

    As an aside, this is essentially a 'prisoner's dilemma' situation. A
    theoretical selfish customer (and I'm talking abstractly here - not
    about you Jeremy!) would like to never pay for what they get - rather
    I'd like the vendor to charge all the other unselfish customers instead.
    But if all customers attempt to operate this way, the vendor goes under
    and all parties lose.

    A wiser customer who sees the bigger picture (i.e. we're all in the same
    boat economically in the long term) wants each customer to fairly pay
    for the value they receive.

    So does having the tweaked search working in concert with the added
    features of the upgraded CMS have value to you? Is the answer is yes,
    paying _something_ for it is arguably fair. Now, maybe it wasn't written
    well the first time with a view to later upgrades, so what's fair is
    negoticable but paying _nothing_ is rather untenable IMO.

    How do we resolve this bind at Accredo? For the core product itself, in
    a pretty industry standard fashion. We use an update subscription so we
    have an economic basis upon which to deal with platform upgrade events
    in the future. It's a fixed 15% per annum of initial cost so if we don't
    design/engineer well for maintenance, we wear the difference.

    For customisations we do in MaxBasic, we either charge a similar 15%
    subscription (generally only if it's a big $ value customisation) or
    make sure the customer is knows that in future there may be _small_
    amounts of chargeable work involved in upgrading the customisation to
    work with later versions. We do a lot of backwards compatibility work in
    the business objects and MaxBasic interfaces to catch most issues but
    for structural change this is hard to make 'just work'.

    Ultimately, it's all about managing the customer's expectations. Once
    you explain the problem (unpaid work), most customers understand -
    they're in business too! If they are unreasonable about this at the
    initial stage - that's a large warning sign that your relationship could
    be rocky. Maybe they had a bad prior experience with a vendor. Maybe
    they consider avoiding paying a kind of sport.

    This is already a pretty long answer to a simple question, so I'll stop
    now. I've written plenty to disagree with here already :-)
TTFN,
      Paul.


------------------------------------------------------------------------

_______________________________________________
NZ Borland Developers Group Offtopic mailing list
Post: Offtopic@delphi.org.nz
Admin: http://delphi.org.nz/mailman/listinfo/offtopic
Unsubscribe: send an email to [EMAIL PROTECTED] with Subject: unsubscribe


------------------------------------------------------------------------

No virus found in this incoming message.
Checked by AVG Free Edition. Version: 7.5.503 / Virus Database: 269.15.22/1112 - Release Date: 5/11/2007 7:11 p.m.

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
NZ Borland Developers Group Offtopic mailing list
Post: Offtopic@delphi.org.nz
Admin: http://delphi.org.nz/mailman/listinfo/offtopic
Unsubscribe: send an email to [EMAIL PROTECTED] with Subject: unsubscribe

Reply via email to