I'm willing to jump in here as a long time vendor to add to the
customer responsibility list some items that would make developers/
vendors a lot happier..
1. Select software using a fair and reasonable process for both the
vendor and the organization (one could say a lot more here!)
2. Make sure you know the needs of all users of the product
(especially the END-users - get them involved! I promise, in most
cases, their needs are NOT understood).
3. Acknowledge, accept and honor the deadlines that YOU bear in the
development timeline. (The phrase "teflon-customers" comes to mind
here...)
4. Understand that more functionality means more complexity in the
code. This means:
a. You've got to accept responsibility for helping to test
software. There can be 1000's of pathways through code. We know you
want bug-free code, but the developer/vendor can't test them all by
themselves or you'd never actually get the code!
b. If you're paying a commercial vendor to support/maintain,
understand that costs should go up to compensate them for supporting
that increasing complexity.
5. Try to standardize practices, **where possible**, between like
institutions. Use development resources for great ideas, not just
to support local idiosyncrasies...
6. Understand if you're trying to please everyone, it means lowest
common denominator. If you're trying to lead and develop new ideas,
somebody is going to be upset. It's not the
developer/vendors responsibilities to decide which of these apply to
your institution or what to do about it when it happens. Decide up
front, are you following, or are you leading?
Carl
Carl Grant
President
CARE Affiliates, Inc.
E: [log in to unmask]
M: 540-529-7885
O: 540-552-2912
866-340-9580 x 801 (Toll-Free)
Website: www.care-affiliates.com
Adium: carl_r_grant
Skype: carl_grant
On Nov 6, 2007, at 1:33 PM, Roy Tennant wrote:
> On 11/6/07 10:27 AM, "Jonathan Gorman" <[log in to unmask]> wrote:
>
>> How about an equivalent list from the vendor/software developer's
>> perspective?
>> I think that would help balance the picture, but perhaps that's
>> already in
>> your plans ;).
>
> Funny you should ask...I had originally intended to do this, but
> then I was
> wondering if it start to be redundant -- that is, would a number of
> points
> simply be restated from the vendor's viewpoint? But if there are
> unique
> points to make from that perspective it would be worthwhile to
> include them.
> This is an area where I consider myself even more ignorant than
> usual, so if
> those of you who work on that side of the fence would like to chime
> in with
> relevant manifesto points from the perspective of developers and
> vendors,
> I'm all ears. Thanks,
> Roy
