[sf-perl] Bug management / time management

Tom Limoncelli tal at whatexit.org
Tue May 8 09:13:40 PDT 2007

I'm not on the mailing list, so this post may get rejected.  Therefore I'm
CCing Vicki and Andy directly.

What you need is a way to say "no" and "not now".

One way to do that is to set priorities.  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.  Sometimes this is done by a
committee with representatives from all areas.   They are called a MRRB (MR
review board, or Bug Review Board).  They meet once a week.  Requests are
left at the default or user-set priority until the meeting happens, at which
time the priorities might be reset.

Another thing you can do is make sure you have 3 policies in writing:
1.  what constitutes an emergency?  (definitions of what is a priority 1, 2,
3, 4, etc.)
2.  how do people report problems?  (submit a bug request.... don't bother
my damn employees)
3.  what is the scope of what the team works on?  (i.e. we do fix bugs in
these 3 areas... we don't fix bugs with other people's systems, etc.)

#3 is most likely not a problem.

When I say "in writing" I mean that they are documented and management above
you goes to bat to enforce those policies.  If a priority 1 bug is "only
emergencies... and an emergency is defined as something that will DIRECTLY
prevent tomorrows newspaper from getting out on time" (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. (www.everythingsysadmin.com).  It's also in a chapter called
"Crawl Out of the Hole" in the next edition of my other book, due out in

Good luck!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.pm.org/pipermail/sanfrancisco-pm/attachments/20070508/88a3337a/attachment-0001.html 

More information about the SanFrancisco-pm mailing list