Ive seen this problem many a time. Management, Engineering etc all get a brilliant idea for a new system. They spend vast resources or analysis, design, contracting out etc. Then they are totally shocked that the lower level managers and staff refuse to use the new system. In this less is more day and age of layoffs and staff reductions there is no place for new systems (no matter how pretty the reports are that senior management would get) that dont reduce workload. Even if the workload is the _same_ its too much as its a) different and thus people must be retrained b) different and thus people arent comfortable with the tools.

I think there are two strategies that can minimize the impact of this type of thing. The first is get the programmers to actually use their programs for the tasks they are meant for. This can be difficult because normally there are barriers put up between production and developement staff but if this problem can be overcome it will pay off in spades. An example for me are two biling systems we have in our firm, one is a large well known all-singing all-dancing integrated billing system, the second is a custom tool designed to bill data customers. Both systems are used for the same purpose, however the first takes about 10 screens and about 45 minutes to provision a new customer and service, and about 30 minutes to deactive a customer, and about 25 minutes to issue an adhoc credit note if the customer would like to be deactivated early. On the second system all of these tasks take no longer than about 3 minutes (and usually a lot less). The reason? The programmer was given the task of USING the tool to add customers HIMSELF early in the process. Anything he didnt like to do would not be liked by the user base. End result, he spent an extra bit of time reworking the flow of his screens to actually reflect the usage cases of his customers.

The second tactic is to actually design the app from the front end first. Forget about back end functionality, the front end screens should be designed in close partnership with intelligent and interested users who will be given the responsibility of running the software. IMO getting this to happen is alot harder than making the GUI design team eat their own dogfood.