Thanks jcrawf02, that is very good advice. I will be sure to do that. I try my best to work with the 'little people'. If i can fix the issues they have on a day-to-day basis i'm sure i can make the system better as a whole. Most users encounter the same bugs daily but don't say anything, so i have reached out to some of the users in my organisation, and they know they can email me directly if they have problems. Once i fix it for one person, it fixes it for 100s of users. Documenting these ideas I think is the way forward, you're absolutely right! Your post has inspired me a fair amount! Thanks!
jcrawf02 (2/12/2009)
Daniel, my suggestion here would be to 1) document the time savings and therefore the monetary impact of the efficiency (it's always about the money) and 2) get the end users involved, and let them fight for the change on their end too.
Every day users sit at their PC and say "If only . . . who designed this thing anyway?", and if IT can work with the end user, and both sides can show how it will improve their efficiency, resulting in more business/better business, resulting in more impact to the bottom line, then change can be made.
Sometimes it's a long haul, and there's always the need to pick your battles, but even the futile exercise of arguing for a change that never happens can bring benefits in terms of networking within your organization, and allow end users to reach out to you in the future, as well as representing yourself to your management as someone who is concerned with process improvement.
My $0.02, anyway.