When working on established systems, I've often found ways to improve a user interface to maximize user efficiency (example: legacy app maintenance screen doesn't allow multi-line operations where doing so could save the user hours per week over the "edit one line at a time" existing method).
The challenge I encounter is that a GUI improvement is something that I can't apply universally to a system without a more sizable programming effort (an effort that management is unlikely to approve).
I then struggle with the decision to either try and add the improvement in one screen, or give up on it until the mythical project is someday approved.
Not doing it means the system is not enabling users to be most efficient, and this bothers me, as if I have purposely allowed a speed throttle on them that they don't deserve.
But doing it means that now there is some inconsistency in the system GUI. Not all the screens will work the same way, which can create potential confusion.
Given your knowledge and experience, what is the best practice here? Consistency or efficiency?
Thank you everyone for your answers. I have upvoted all your thoughtful responses. I am familiar with the Spolsky article Robert Harvey links to. The change I refer to is less risky than the whole rewrite of the Netscape example it refers to, but the article is pertinent and always a good read.
This question was spurred by a time when I found a way to make it possible for users to process items for invoicing faster, so it could be argued that it improved revenue efficiency, however, as many of you ascertained, it was not critical. The stakeholders succumbed to the decision-consequence gap, and as they were not the ones having to do the data entry were more than happy to let the users languish with the inefficient GUI. However, the craftsman in me wants continuous improvement, and as Justin Cave says, if you do nothing, your system is not evolving, it is stagnating.
In some other cases I've done what is suggested in the responses and tried a grassroots approach, having users push for change through their stakeholder representatives. I found that approval for incremental changes that broke consistency have depended on accessibility to end-users, a willing stakeholder in the change request meetings and strangely enough, IT leaders that either cared very much or not at all about the application in question. Those that cared empathized with the end-user's pain and those that didn't were comfortable leaving the decision to subordinates that did. The moderately concerned would glom onto the consistency principle which is arguably laudable but to which rigid adherence without a plan for change means stagnation.