Project Management for Operations Projects

"Keep it running well" isn't a project with an end date

Most project management tooling assumes a project: a defined scope, a start, an end. Operations work often doesn't fit that shape. Facilities, IT support, vendor logistics, internal tooling: these are ongoing responsibilities, not initiatives that finish. There's no "done" for keeping the office running or the internal ticketing process healthy. There's just this week's version of it, and next week's.

Layered on top of the recurring baseline is a second kind of work: improvement projects that do have an end, like migrating a vendor, fixing a broken handoff between two teams, or rolling out a new access process. These have to compete for the same people's attention as the daily keep-the-lights-on work, and they usually lose, because the daily work has a way of feeling more urgent even when it isn't more important.

The other defining feature of operations work is where it comes from: everyone. Every team generates requests for operations: a new laptop, a broken door lock, a question about a vendor contract, a request to fix a process that's clearly wasting time. Without a single front door, those requests arrive as messages, hallway asks and forwarded emails, and the ones from people who ask loudest get handled first regardless of actual priority.

The triage inbox as the actual front door

This is the pattern ShipSprint fits most naturally: every request, from any team, lands in one triage inbox instead of a specific person's inbox. Nothing gets worked until someone actively pulls it out of triage and onto a board, which means the volume and shape of incoming requests is visible before any of it becomes a commitment, and a loud requester in Slack doesn't automatically jump the queue.

WIP limits on the working columns do the rest. If "in progress" is capped and full, a new request can't quietly join it. It waits in triage until something finishes, which is a far more honest signal to the rest of the company than a queue that looks open but is actually already overloaded.

The recurring baseline work (the standing processes) gets its own board with its own cadence, separate from the one-off improvement projects, so a facilities ticket and a six-week vendor migration aren't competing for the same column and confusing everyone's sense of what's actually behind.

There's a quieter benefit too: because triage is the only front door, the ops lead sees the true volume of incoming work in one place, rather than piecing it together from memory of who asked what in the hallway this week. That total is often higher than anyone assumed, and seeing it plainly is usually the first step toward getting the function properly staffed. It's a small mechanical thing, one inbox instead of five channels, but it's often the single change that makes an overloaded ops function visible as overloaded rather than just perpetually behind.

What this looks like on a normal Tuesday

• A new-laptop request from HR lands in triage, gets pulled onto the fulfilment board same day, and doesn't need a Slack message to anyone to make it happen.
• The "in progress" column on the facilities board is capped at six; a seventh request waits in triage rather than getting started by someone already overloaded.
• The vendor-outage runbook gets updated on its wiki page the week after an actual outage, so the next person handling one isn't starting from scratch.
• A six-week access-process rollout runs as its own project with its own forecast, instead of getting lost inside the daily ticket board.
• The Monday digest shows the ops lead how many requests came in last week and how many are still open, without anyone compiling a report.

Two boards, not one, and why that matters

The temptation is to run everything operations does on a single board, because it's simpler to set up. It doesn't stay simple. A recurring maintenance checklist and a one-off vendor migration have different rhythms (one repeats weekly forever, the other has a start and an end), and mixing them means the board's "done" column fills with completed weekly tasks that make the six-week project look further along than it is, or the project's slow, steady progress gets buried under the volume of routine tickets closing daily.

Splitting them costs almost nothing to set up and pays back the first time someone asks "how's the migration going" and gets an answer that isn't drowned in unrelated ticket noise. The recurring board optimises for throughput and backlog age; the project board optimises for a forecasted finish date. Different questions, different boards.

The exception is triage. That stays singular. Whether a request turns into a recurring-board ticket or spins up as its own project gets decided at triage, by a person, based on scope. A one-line fix and a six-week migration shouldn't be sorted by the requester guessing which board to submit to.

The rest of the company, one subscription

Operations sits underneath every other department, which is exactly why it benefits most from everyone being on the same system. A request from engineering and a request from finance show up in the same triage inbox, in the same format, instead of arriving through whatever channel each team happens to prefer. Engineering, HR, marketing and operations each keep their own templates and vocabulary, but the plumbing underneath (triage, WIP limits, the wiki) is the same everywhere.

ShipSprint also connects to Claude and ChatGPT, so a question like "what's been sitting in triage longest?" can be answered without opening the board at all.

That matters for a function that's constantly interrupted by exactly the kind of question a dashboard should answer instead of a person. Every minute spent explaining current status verbally to whoever asked is a minute not spent clearing the actual backlog, and operations, more than most functions, tends to be measured by how quickly that backlog moves.