Project Management for HR Projects

The HR work that doesn't have a category yet

Recruitment, onboarding and training each have a fairly obvious shape and a name people already use. A lot of HR work doesn't: rewriting the leave policy, switching benefits providers, running the annual comp review, updating the employee handbook after a legal change, rolling out a new performance review cycle. These initiatives are genuinely different from each other, but they share the same failure pattern. They get tracked in email threads and a shared drive folder, with the actual status living in one person's head.

Ask what stage the benefits vendor switch is at, and the honest answer often depends entirely on who's asked, because there's no single record that isn't someone's memory of the last call with the vendor.

That works fine until the HR lead is out for a week and someone else needs to know whether legal has signed off on the new policy draft, or whether the benefits vendor comparison is done. Then it's a scavenger hunt through old emails.

ShipSprint gives each of these initiatives its own board, a project with a start, an owner, tasks and a status, the same structure engineering uses for a release, applied to HR-department-wide work instead of a hiring pipeline or a single hire's checklist.

One board per initiative, not one board for everything

The mistake most HR teams make when they first try to systematize this is building one giant "HR tasks" board that mixes a comp review with a printer request. That collapses into noise within a month. The fix is treating each initiative as its own project: "Q3 benefits provider switch" is a board with its own timeline and stakeholders, separate from "2027 leave policy rewrite," separate from the recruitment pipeline and the onboarding templates running elsewhere in the same workspace.

Multiple initiatives running at once, which is normal for HR, stay legible because each has its own board rather than sharing one undifferentiated list where a stalled comp review task looks identical to an overdue policy edit.

Separate boards also make it possible to give an initiative the right audience without over-sharing the others. Finance needs visibility into the comp review; it doesn't need visibility into an ongoing disciplinary process, and a shared "HR tasks" list makes that kind of selective access far harder to manage than a set of individually-scoped boards does.

Where the line sits with the more specific HR pages

• A specific hire's setup checklist is employee onboarding, a template cloned per person
• Filling an open role is recruitment, a candidate pipeline with its own board
• Building and running a course or program is training, content and rollout on a timeline
• Everything else HR runs company-wide, policy, benefits, comp, handbook updates, review cycles, is what this page covers

None of these are separate products. They're the same board-and-task mechanism, applied to different shapes of HR work, on the same subscription.

What it isn't

ShipSprint doesn't run payroll, doesn't administer benefits enrolment, and doesn't hold formal personnel records, it's not a replacement for an HRIS. What it replaces is the informal layer sitting on top of the HRIS: the project plan for the initiative that changes what the HRIS will eventually reflect. The comp review itself is a project with tasks and a deadline; entering the final numbers into the payroll system afterward is a separate step in a separate tool.

Why a paper trail matters more for HR initiatives than most

A policy rewrite or a comp review tends to get questioned later, sometimes much later. An employee asks why a decision was made the way it was, or a new HR lead inherits a policy and needs to understand the reasoning behind a clause that seems odd out of context. A board with page history in its wiki keeps that reasoning attached to the decision itself: who proposed the change, what legal flagged, what the final version said and when it changed. An email thread from eighteen months ago is rarely findable when someone actually needs it; a wiki page with history is.

That matters for governance as much as convenience. Admin actions are logged and every workspace is an isolated tenant, so a comp review or a disciplinary-process update can be run with a genuine audit trail rather than an assurance that "someone probably kept the emails."

It also means initiatives survive a handover better. HR has ordinary staff turnover like any department, and an initiative that lives in one departing person's inbox is at real risk of losing months of context in the transition. One that lives on a board with its own wiki hands over cleanly: the next owner reads the board, not a stack of forwarded emails.

HR runs several of these at once, which is exactly the problem

A mid-sized HR team rarely runs one initiative at a time. It's more typically a comp review in progress, a benefits vendor switch under evaluation, a handbook update waiting on legal, and a new performance cycle being designed, all overlapping because the calendar doesn't wait for one to finish before the next starts. Tracked in email and shared drives, that overlap is exactly what causes things to drop. The person managing all four has no single view of what's actually due this week across all of them.

With each initiative as its own board and the owner command center rolling all of them up, that view exists without anyone building it by hand. That's the difference in practice: what used to be a mental juggling act becomes something you can actually look at. It's also what makes it obvious when one person is genuinely overloaded across initiatives rather than just busy on any one of them, four boards each showing a handful of tasks assigned to the same HR lead this week is a capacity problem worth raising before a deadline is missed, not after.

Smaller HR teams, sometimes a single generalist running everything, get a different but related benefit: a written plan per initiative means priorities are visible and arguable. If a policy rewrite and a benefits switch are both due the same month, having both on boards makes the conflict something that can be discussed with a manager, rather than something the HR lead just has to silently absorb.