Advice on structuring IT work tracking and performance metrics in a small org

Posted by kshot@reddit | sysadmin | View on Reddit | 13 comments

Hi all, I work as the sole internal IT employee in a relatively small organization (under 100 employees). My title is *IT Advisor*. Our day-to-day IT support is handled by an external provider, while I focus on: * Managing IT projects (mostly delivered by external vendors) * Administering our systems (Azure, M365, network: FW, switches, APs) * Handling IT onboarding/offboarding for new hires * Occasionally providing direct IT support, especially when it overlaps with ongoing projects My manager technically holds the IT director role, but they have no IT background (though they’re a solid manager). This makes me somewhat of a hybrid generalist: project manager, sysadmin, and occasional support. Because of this, I want to make sure there’s visibility into what I actually do. I see value in leaving a clear record of my activities and building a performance indicator (KPI). Right now, I use GLPI and create a ticket for every request/incident. But I’m wondering: * Is this the best way to track my work in such a hybrid role? * Should I be logging *all* tasks in a ticketing system (projects, admin tasks, quick fixes), or is there a better method? * How do you structure performance indicators in a context like this, where the work is a mix of projects, admin, and ad hoc support? I’d love to hear how others in small orgs with similar setups handle visibility, work tracking, and reporting. Thanks!

Reply to Post

13 Comments

[-]

Quietly_Combusting@reddit

The best way to show visibility in a small IT setup is to document everything in one system instead of splitting projects, admin and support across different tools. It not only makes performance reporting easier but also helps management see exactly where time is being spent. Whether that's GLPI or something more streamlined like Siit.io, which is a service desk platform that combines ticketing and knowledge management in one place, the important part is making the ticketing system the central source everyone relies on.

[-]

Key-Boat-7519@reddit

Centralize everything in one system (GLPI is fine) and tag work so you can report by category. Set clear types: Project, Admin, Support, plus tags like BAU, Change, Incident. Use templates for recurring admin (backups, patching), and open change tickets for risky actions. Track time on every ticket; aim for weekly snapshots: time split by category, MTTR for incidents, aging tickets, % planned vs unplanned, and top risks next week. Link KB articles to tickets and require a brief postmortem for P1s. Automate intake: email-to-ticket, simple form, and Teams/Slack to ticket. Pull asset/user context from Snipe-IT and Entra/Intune into tickets. I’ve done similar with Jira Service Management feeding Power BI, and DreamFactory exposing SQL/Snowflake data as REST so the dashboards update without manual exports. Keep it all in one place and report by category; that’s what makes your work visible.

[-]

Warm_Share_4347@reddit

Split the build in a project management and the run in a ticketing or ITSM as you are suggesting processes like onboarding. Have a look at Siit for the itsm

[-]

Maximum-Animal-5110@reddit

We created exact platform for that. Easy, all data that is needed + AI. 8 people worked for a year on it. If you want a pilot at no cost let me know

[-]

Big-Chemical-5148@reddit

What helped a ton was splitting my work into categories (projects, support, ops) and tracking them separately instead of logging everything the same way. For example, I’d keep quick fixes in the ticketing tool but manage project work and ongoing improvements in a lightweight board (I use Teamhood for that now). It gives a clearer picture of where time actually goes and makes reporting way easier when you need to show impact.

[-]

sysadminresearch26@reddit

Maybe you should consider a Scrum/Agile esque board to track progress and create Stories tied to Epics and Features. I'm familiar with Azure Boards and on the teams I was a part of in a major organization, this was used, to mixed effect. It could add administrative overhead, but what it does do is allow you to categorize and break down work effort into hierarchies. Since you're speaking about projects, that type of methodology may work well with that, because you can give points to each story based on their work effort rather than in a change system alone. Lets say you create a ticket for a change you're doing for something that takes a minute, and then you're doing the same thing for one that takes a week of planning and prep. If you're tracking that, it looks the same, but you know the difference. I think that's the advantage of using something like a board, and maybe you don't have to make traditionally development-esque Sprints and thing, but it would allow you to take high level project initiatives and break them down into subcomponents. I don't have much experience with products outside the Azure space for this, but I assume there are things like Jira and maybe some open source tools that could help with this. Just a thought on how to organize things by a methodology that may help and be a bit more than your traditional change management system.

[-]

Whyd0Iboth3r@reddit

Yes, document everything you do in GLPI. Tickets are what KPIs are made from. A company that small, most likely, isn't going to track KPI's. And if you want to track your own... That's weird, to me.

[-]

kshot@reddit (OP)

I get what you mean. The main reason I’m leaning that way is because my manager isn’t technical and I’m the only internal IT person. Having a simple way to translate “what I do” into something visible and outcome-oriented helps her see the value of IT without getting lost in the details.

[-]

1a2b3c4d_1a2b3c4d@reddit

I get that, but you are making more busy work for yourself than your manager didn't ask you for. Sure, send a one-page status report with some stats and KPIs, but don't expect your management to care too much. You should focus on your career. You should focus on acquiring skills and gaining experience, then moving up or out. This company is nothing more than a stepping stone to your next company. As soon as you get enough new skills, you move on.

[-]

1a2b3c4d_1a2b3c4d@reddit

[-]

ethn_cl@reddit

Use two tracks - GLPI for every request/incident, and a simple Kanban board for projects and routine admin so work isn’t buried in tickets. Send a monthly one-pager to your manager with three buckets - projects shipped, risk reduced, operations - and a few KPIs like onboarding SLA, patch compliance, MTTD/MTTR, change success rate, and % tickets handled by vendor vs you. That gives you visibility without drowning in process and keeps a non-IT manager focused on outcomes, not busywork.

[-]

kshot@reddit (OP)

That’s super helpful, thanks! Quick question... have you built that kind of one-pager KPI report yourself in the past? If so, would you be open to sharing a model or example? It’d really help me get a visual idea of how to structure mine.

[-]

ThatBarnacle7439@reddit

The most important thing is to know your audience. You're selling what you've done to non-technical people. \#1 - show face and check in and make sure everything is good. The best thing you can do is let everyone know that you have things under control and they just assume that everything in IT will work every day that you're there. For everyday break/fixes, do tickets. People love numbers. For projects, document the impact that it has on the company. No one cares what you clicked on any given day or what fancy technical trick you pulled off, document the end-user impact and business impact (saved XYZ manhours by implementing a new process, saved $XYZ by moving to a new solution). I break everything down for my own sake in Planner.