Larry,

>While not "necessarily bad" it can become a huge PITA. End-users are just that, end-users. They dont pay for anything and as such have a wealth of opinions about how the system should work (without regard to how much the system will cost to build).

Seems we have a difference in approach here. When I calculate the project cost, I normally include users interviews. If they're not giving me the possibility to do so, this is in my favour.

It's my goal to deliver a quality product, and personally I think that I only can do this by talking with end-users also.

>I don't think it's my job to get the system right for the end-user. It's my job to get the system right for my client. Now if the client doesn't consult the people he is going to force this new system on, then I can not be held responsible for his failing.

Hmmm. I think it's my job to reach the clients goal. The contact persons often have not much knowledge of information systems and software development in general, and therefore I like to help straighten things out.

Of course when an end-user wishes something, I've got to talk this trough with my contact person.

>It has always been my policy to get one or possibly two contacts at the client site. All requests come through them and anything else, unless otherwise instructed, is filed or sent back to them without me dealing directly with the sender.

In the past this construction has lead through serious software developement failures. Big projects at the covernment failed because the end-users who work in the problem domain in great detail were not interviewed. You can imagine that this was not of any benefit to either the softwarecompany or the clients contact persons.

I don't say your policy is wrong (it depends on your intuition and experience) but there is a potential danger that you'll deliver a system that does not meet the users reqiurement.

Walter,