A Project Management Playbook for Operations Teams

An ops team that everyone else treats as a help desk

Picture a company of around eighty to a hundred and fifty people with a small operations team, maybe four or five people, responsible for everything that doesn't belong cleanly to engineering, sales, or finance. New-hire laptops and desk setup. Vendor renewals. Office moves. Access requests. A compliance filing due at the end of the quarter. None of it is dramatic on its own, but all of it lands on the same small team, from every department, at once.

The requests don't arrive through one door. A hiring manager pings someone directly about a laptop for a start date next week. Finance emails about a vendor contract that's about to auto-renew. A new employee's manager asks in a shared channel why the badge access still hasn't come through. Each request is reasonable on its own. Together, they're an operations team fielding messages in four different places with no shared view of what's actually outstanding.

This is the situation many ops teams are in before adopting a tool built for the shape of their work rather than a generic ticketing system built for IT support alone.

Before: everything is urgent because nothing has a queue

The core problem for a team like this is usually that the work has no shared queue. When a request lives in someone's inbox or DMs, only that person knows it exists, which means nothing gets picked up by whoever has capacity right now, and nothing gets covered when that person is out. A vendor renewal quietly missed its deadline because the request sat in an inbox nobody else could see. Nobody in ops dropped the ball on purpose.

The second problem compounds the first. Ops work spans several genuinely different domains, HR-adjacent onboarding, IT-adjacent provisioning, facilities, compliance, and most general project tools assume one kind of work with one vocabulary. Forcing a facilities request and an onboarding checklist into the same generic "task" template, with the same fields, tends to make both worse: too many irrelevant fields for one, not enough structure for the other. So teams end up managing onboarding in a spreadsheet, vendor renewals in a calendar with reminders, and everything else nowhere in particular.

By the time something escalates, whoever's asking usually has no idea it was even in progress. From their side, it just looks like nothing happened.

After: a queue that holds itself, mostly

Requests keep coming in for a team like this. The realistic shift is that they stop being invisible between the moment someone asks and the moment ops responds. A request that used to live in one person's head now lives on a board anyone on the team can pick up. A vendor renewal that used to depend on someone remembering a date now sits in a column with a WIP limit that makes the team notice it before it's overdue, not after.

It's honest to say this doesn't remove the underlying volume of work. An ops team of four still has four people's worth of capacity. What changes is that the team can see its own backlog clearly enough to say "we're at capacity" out loud, instead of finding out by missing a deadline. And because engineering, HR, marketing and operations all run on the same subscription with their own templates, ops isn't the one department stuck explaining its process to everyone else in a different tool.