>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).
>
End-users may well have valid input, even at the data entry clerk level if the subject of the spec is the interactive UI. OTOH, if the subject is business logic, the data entry clerks have no useful input.
The guy paying the bills decided to include these people in the loop at this stage. I'd make certain that he was aware of the added costs associated with the added fact-finding and filtering, and as long as they agree (in writing) to pay for the added effort and time you have to invest here, take it in stride. Just make sure they're willing to shell out the extra money; they might not have been aware of the side-effects of a poorly-considered, demi-pointy-haired-manager concept of involving as many people as they could who might want to provide some insight.
And I charge extra if I can't shoot the really lame ones who were brought in to make a visit from Murphy more likely.
>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.
We differ here. Our responsibility certainly includes the user interface, and the people working it day-to-day know what doesn't work well. It may be little things, like using keyboard shortcuts that they understand better, or wanting to be able to do heads-down data entry, deferring validation until it's just before transaction time. Let the user enter the data and then go back to fix the data if it's wrong may work better than interrupting the workflow of data entry field-by-field. Things like changing the order that fields are traversed might make all the difference in the world.
OTOH, things on the order of wanting a spinning flaming logo to drop from the sky when there's fresh coffee in the kitchen probably is not a good user wish to implement if the budget for gawdy doodads that "look kewl" is questionable.
Again, the client solicited these people's input - there's an outside (admittedly, vanishingly small) chance that they know what they're doing.
>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.
Obviously, you need to have a solid, ongoing point of contact, but the manager you usually talk to is not the guy who sees the real problems in the day-to-day use of thje product.
The odds are that you're going to need to talk or correspond with people besides your primary contact(s); the biggest issue is to make sure the primary contact is aware of the extra burden and will assume responsibility for adding these people to the specification process. There's a huge difference between policy makers and the main user population.
