I'm trying to help better organize the activities of our group. We're largely a service organization (working with faculty and students at an academic institution), but we're a tech group and we do software development and integration as well.
We had previously tried a "tools-first" approach to project and task tracking, and that wasn't terribly successful — the tools became a burden rather than an aid. So I'm trying to think things out from first principles. I don't really have a background or training here, so I'm struggling a bit with the naming of things, and hope you can help.
Here's my conceptualization of the different types of activities we do in a generic sense. There's a lot of ways to divide up activities, but this one is prompted by thinking about the differences in needs for organizing and tracking. Event response needs a ticketing system; that same ticketing system might not be the best for project tracking, or for the "blue" category as explained below.
Event response is activity prompted by something external: an e-mail for help or walk-in request, or, a system disk failure or security breech. Either way, these are hard to plan for except as estimates; they tend to be short lived, and require immediate response of some kind. (Making sure time and people are budgeted for these things is important, though, since they really do serve our group mission and mustn't feel like distractions or interruptions.)
Unavailable is something the higher-ups thought looked badly on the chart, but basically is an acknowledgment that people have sick days and vacation and other interruptions. It helps me to keep that in mind, even if it ultimately doesn't go into presentations of what our group does.
Exploration/Learning is training and individual exploration of new technologies and ideas. We need to be up on these things as a group so this is important.
Project development is where we work to enable new services or improve existing ones. We also do some consulting-style work which seems best managed as small projects. We have work to do in areas around process here, but I've got a lot of good ideas on how to move forward.
So, Daily operations are where I keep running into a language problem. I mean "the stuff one does as part of keeping our services running", but not just in a technical sense. Some of this is reading logs, checking server status, and so on, but I also mean for it to encompass teaching a seminar, meetings with our users. And I don't mean it to include many of the things that are generally included under "operations" in the IT sense. Racking a server, for example, is probably part of a project to deploy some new or upgraded service; changing a failed disk is event response. A general characteristic of things in this category is that they are continuously ongoing, but are not externally prompted. We can usually ignore or avoid working on these things for a time, at a cost of accrued technical or social debt — we can avoid reading logs, but may need to suddenly pay when there's an incident later which we weren't aware of. We can avoid scheduling meetings with faculty with no immediate consequences (but probably serious longer-term ones).
So, what's a good thing to call this last category of activity? I really want to avoid "operations", but can't think of anything better.