> What techniques/tools/etc. have people found that > are useful to do that? Any other general time management suggestions for > that sort of a small environment?
In an interrupt-driven environment (crisis now!) and also in an environment where there are a lot of actual interruptions, I've built my framework around these four main areas: - tracking of issues - documentation (what I did and how to do stuff) - daily/weekly focus - weekly summary At my current job, I implemented Trac (http://trac.edgewall.org/) for wiki/ticket tracking. Trac doesn't have the functionality you'll find in RT, but it's faster to set up, easier to understand, and can be integrated with subversion. The ticketing system is purely for my own use and reference. I create a ticket (almost) every time someone asks me to do something, for every project I have planned, for every error message a system throws, for every order I have to place, etc. If I think of something when I'm not in the office, I'll send myself a reminder email that says MAKE TICKET FOR XYZ in the subject line. Since I'm not using Trac for software development purposes, I repurposed the Milestone field to be a category field for the type of request and Component field to be the sub-type of the request. To simplify things, I eliminated the Severity field and only use the Priority field. I also set the system up to email me copies of ticket entries so that I have a second way to access that data. What I mean by "documentation" is both the technical documentation and the documentation of my activities. The tickets themselves become part of my documentation structure. They provide a place for me to record solutions and by looking at the Trac timeline I can see when each issue landed on my plate. Some of my ticket notes eventually migrate into wiki entries, but if I have a ticket that says "document installation of xyz" my documentation originates in the wiki and the ticket gets closed out with a link to the wiki page. I try to achieve HBAB (hit by a bus) documentation so that someone unfamiliar with the infrastructure has a fighting chance at handling it with little notice. In parallel with the ticketing system, I maintain a paper To Do list on a pad of paper. Each page may contain a day's worth of activities or a week's worth. My first task on Monday mornings is to copy over unfinished tasks from the previous day/week to a new page and to make decisions about which projects and tasks should receive my focus this day/week. The pad goes to meetings so whenever I have an action item from a meeting, I add it to the current list. I also use that list to keep track of what day I plan to do something or what day something is due. This methodology allows me to avoid possible ticket "overload" due to the sheer number of open issues recorded in the ticketing system. Every week or two, I perform ticket "maintenance" -- making sure that all issues that have been handled are actually closed out properly and reassigning priority as necessary. My second task on Mondays is to copy my summary report from the previous week into a new mail message. My summary report is a bulleted listing of what I did and what I plan to do. I update that message periodically throughout the week and at the end of the week I go back and look at my paper to do list and the timeline in the ticketing system to see if I have listed all the key accomplishments that I want to list. Between the summaries and the ticketing system, I now have the data available to answer the questions "how did you do xyz?", "when did xyz happen?", and "what did you accomplish this quarter/year/whenever?" when they are invariably asked. As an added bonus, I don't have to try to remember every little thing I did. I'll second/third/whatever the recommendation for Tom's book. M _______________________________________________ Discuss mailing list Discuss@lopsa.org http://lopsa.org/cgi-bin/mailman/listinfo/discuss This list provided by the League of Professional System Administrators http://lopsa.org/
