|
Patrick, Very humbly, may I suggest that the model you use would break down if the customer insists that every thing that they don't like is a bug. Anybody who's ever replaced a competitor's package has heard "But we always did it THIS way when we used ZZZSoft." Sadly, "bug" or "software problem" is rarely spelt out in the contract, and the vendor has an unpleasant handful of choices: Make the mods and eat the cost, make the mods and charge for them, don't make the mods and explain that "this is the way it works". When the customer thinks "their" package shouldn't need mods in the first place, which of these options will please the customer the most? What a bug is should be reasonably clear in the contract language: any deviation from proper operation. How many packages have good enough specs to be able to make out what that means? In reality, "bugs" exist on a fuzzy dim spectrum, ranging from white messages (divide by zero, record lock, etc. - clearly a bug) to report spacing/level breaks (less clear, especially if the totals are correct) to missing reports/displays ("ZZZSoft had a report to do that" - incorrect expectations?) to user interface questions ("why do we need to go through 3 menus to reach this?") to corrupted data ("but WHY can't we run the month close in the middle of the month? We want to see how we're doing!"- user error) to ease of use ("I can't find the purge menu - where is it?" - the documentation tells you that each sub-system has it's own purge option, unlike ZZZSoft). A user may legitimately argue that all of these examples are bugs, whereas a vendor might legitimately argue that only white messages are bugs. If this were Utopia, the vendor and customer would negotiate the "what's a bug" question before the sale. The customer would also make every effort to let the line people understand that the new package is replacing ZZZSoft because it's better, not because some executive had a whim. The customer would view the vendor as a partner, not an opponent and vice versa. Ahhh, if only we were in Utopia... Humbly, quietly and very respectfully, Buck Calabro Aptis; Albany, NY > -----Original Message----- > From: Patrick Townsend > Sent: Monday, November 29, 1999 2:04 PM > To: MIDRANGE-L@midrange.com > Subject: Re: Software Vendors > -snip- > And I can't imagine a software vendor charging you for > consulting time to fix a software problem. I'd be inclined > to send the software back! +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to MIDRANGE-L@midrange.com. | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.