Re: Desc. for "functionally incomplete" ?

[Walt Tucker <walt_tucker -at- MENTORG -dot- COM>]

Rowena,

   Just a caution -- be careful what you promise and when you say it will
be delivered!  Company priorities, schedules, and market requirements tend
to change over time and what you thought in January that you would deliver
in June doesn't always turn into reality.  But, once you make a future
delivery promise in print, customers can hold you to it... sometimes to the
point of a lawsuit.  Improperly worded, you may have just created a binding
contract on the part of your company.  If not an implied contract, you
might have created the basis for customer ill will if you don't deliver what
you say you will.

    Over the years, I've learned to be somewhat vague about promising
future functionality in a user's manual.  Describe the product as is,
and let the marketing and contract people make the sales and customer
promises.  The only time you can't avoid this is if you have part of the
user interface that doesn't do anything (not a good engineering practice
in my opinion; it only serves to point out inadequacies in your product,
and can cause unneeded user frustration).  Then, all you need to say is,
"this feature is not currently implemented", "currently,
there is no way to make the XYZ button active", or something similar.

    In your email, the term "feature" is somewhat vague.  I would hope you
would define what you mean by this term.  25 menu items?  25 dialog boxes?
25 action buttons?

    If you absolutely have to make a promise, don't attach a date to it:

    "The product currently contains 25 active menu items, and 15 menu items
    that currently do not work.  The working menu items are <bulleted list>.
    The non-working menu items are <bulleted list>.  In a future software
    release, all menu items will be functional."

    Notice the above didn't say what software release, when it was going to be
delivered, and how many menu items would actually work (just that all that
appeared on the menu would work).  Hard to sue over something like that. :-)
Again, if your company is promising certain functionality to a customer and
the customer is making a purchase based on that promise, let the sales
contract make the binding promise, not the user's guide.

    The fact that a "feature" is bug-free should be a given.  Of course
it is bug-free!  Why would I pay money for this product if I didn't expect
it to work?  Handle known bugs as exceptions, not the rule.

    Be careful of using the word "beta" as it has many different meanings
to different people.  When we release a beta product, there is usually a
beta agreement that the customer signs that spells out both our support
obligations and the customer obligations.  A common meaning of beta
is "incomplete, untested software that I am either receiving for free or
at a discount in order to provide feedback to the manufacturer."  If you
are charging full price for a V1.0 product, and you aren't providing a
feedback mechanism, it isn't beta.

    Lastly, even if you provide an improved product at V2.0, how will
customers receive it?  For free?  By paying an upgrade price?  By paying
full price?  By returning a proof-of-purchase label?  My periodically
checking a web site and keying in an authorization code to download
new software?  Stuff to think about.

    My two cents.

    -- Walt Tucker
       Mentor Graphics Corp.

P.S. -- I can't recall an instance where we have been sued over promising
        future functionality, but there have been cases where it has caused
        us much grief.  I remember a situation a few years ago at a user's
        conference where a customer stood up in front of about 600 other
        users and addressed the following question at our senior management:
        "Three years ago the product manual promised we would see XYZ in
        the software.  Three years later, I've yet to see that functionality.
        We need it and have been waiting for it for three years.  Where is it?"

 From ??? -at- ??? Sun Jan 00 00:00:00 0000=