I&#39;m not on the mailing list, so this post may get rejected.&nbsp; Therefore I&#39;m CCing Vicki and Andy directly. What you need is a way to say &quot;no&quot; and &quot;not now&quot;. One way to do that is to set priorities.&nbsp; Let users set the priority of their requests but once a day a manager should review all new items and change any priorities they disagree with.&nbsp; Sometimes this is done by a committee with representatives from all areas.&nbsp;&nbsp; They are called a MRRB (MR review board, or Bug Review Board).&nbsp; They meet once a week.&nbsp; Requests are left at the default or user-set priority until the meeting happens, at which time the priorities might be reset.

<br><br>Another thing you can do is make sure you have 3 policies in writing:<br>1.&nbsp; what constitutes an emergency?&nbsp; (definitions of what is a priority 1, 2, 3, 4, etc.)<br>2.&nbsp; how do people report problems?&nbsp; (submit a bug request.... don&#39;t bother my damn employees)

3.&nbsp; what is the scope of what the team works on?&nbsp; (i.e. we do fix bugs in these 3 areas... we don&#39;t fix bugs with other people&#39;s systems, etc.) #3 is most likely not a problem. When I say &quot;in writing&quot; I mean that they are documented and management above you goes to bat to enforce those policies.&nbsp; If a priority 1 bug is &quot;only emergencies... and an emergency is defined as something that will DIRECTLY prevent tomorrows newspaper from getting out on time&quot; (if you work at a newspaper) then management has to be willing to support you when you change a pri-1 to a pri-2.

As Andy alluded to, I make these points in Time Management for System Administrators. (<a href="http://www.everythingsysadmin.com">www.everythingsysadmin.com</a>).&nbsp; It&#39;s also in a chapter called &quot;Crawl Out of the Hole&quot; in the next edition of my other book, due out in June.

<br><br>Good luck!<br><br>Tom<br>