D.R. is right, and what you need to do is to first identify where the "slow" connection really is. Users consider eveything past the keyboard as network.
Hang a sniffer on the LAN segment and filter on the user IP and the server he is attaching to. Use a local workstation using Terminal server connectivity. Have a use step through a task and look at the traffic and delays from hitting enter until ready to begin the next step. From this you will have several key pieces of data.
1) Actual traffic transmitted (volume and content)
2) Server time
3) Client time
4) LAN transmission time
If the bulk of the time is on the server, this is where you apply your efforts. The volume and content of the packets are useful here as well. Often the transmission is more overhead than data and this can often be cleaned up with a little thought.
If the bulk of the time is on the client, then look at your CPU and memory. You may very well have resource issues resolved with hardware upgrades.
If the bulk of the time is transmission on the LAN, you have network issues. On the LAN, congestion and volume of this particular task are the likely problems. Congestion is resolved through reducing collission domains. Volume is back to the application.
A T1 should easily support upwards of 60 plus users of network centric designed applications. You pay for circuits forever, so your best value is in good application design, not more bandwidth.
If the application smokes on the LAN, you may need to look at latency issues between sites. Divide your volume by bandwidth to see how long your wire time should be. Subtract that, server time, and client time from total time remote users experience and you will have a good approximation of how much time latency is adding.
