Project Management for Compliance Projects

The deadline isn't negotiable, so the plan can't be vague

Most project work has some flexibility in its deadline, a launch can slip a week, a feature can ship next sprint. Compliance work is different: a certification date, a regulatory deadline, an audit window is set externally and generally can't be moved by wanting it to move. That changes what a team needs from a planning tool. It's less about optimism and more about an honest, continuously updated read on whether the work will actually be ready by a date nobody controls.

The other thing compliance work needs that ordinary project work often doesn't: proof. An auditor doesn't just want to know a control was implemented, they want to see when, by whom, and what the reasoning was. A decision made in a meeting with no record is, for audit purposes, a decision that might as well not have happened.

ShipSprint handles both halves: a forecast that takes a fixed date seriously, and a wiki built to hold the evidence trail an audit actually needs.

Two different deadlines, easy to confuse

Compliance work usually has two dates running at once, and treating them as one causes most of the scramble teams recognize from experience. There's the external date, the audit window, the certification deadline, and there's the internal date by which the actual control work needs to be done in order to have evidence ready before the auditor shows up. The second date is earlier, sometimes by a lot, and it's the one that rarely gets its own line on a plan. A forecast built from real velocity gives that internal date something to be measured against, instead of everyone working backward from the external date and hoping it works out.

The wiki as evidence trail

The built-in wiki keeps decisions next to the work they affect, and, this is the part that matters for compliance specifically, every page carries history. When a control was implemented, who signed off on an exception, why a particular approach was chosen over another: that's not just documented, it's dated and attributable. Six months later, when an auditor asks "when was this decided and by whom," the answer isn't a memory, it's a page history.

Any sentence on a page can become a task, which matters for compliance in a specific way: a remediation item noted in passing during a review, "this control needs updating before the next cycle", doesn't have to depend on someone remembering to raise it separately. It becomes trackable the moment it's written down.

Who actually owns a control

A recurring failure in compliance projects has nothing to do with tooling and everything to do with ownership: a control is documented, but the person accountable for keeping it true has changed roles, left, or never actually agreed they owned it in the first place. Nobody notices until an auditor asks a question the current team can't answer, because the person who could have answered it isn't there anymore and left no trail. Assigning a control as a task with a named owner, visible on a board, not just written in a policy document, makes that ownership something the tool can flag as unassigned or stale, rather than something that silently rots until someone asks.

What this replaces

• A compliance tracker spreadsheet where "last updated" and "actually current" have quietly diverged
• Meeting notes as the only record of why a control decision was made
• A remediation list with no visible signal when items are piling up unaddressed
• Scrambling for evidence the week before an audit instead of having it dated and attributable already
• Confusing the audit date with the internal deadline for finishing the work, which is usually the earlier and more important one

The re-certification problem

First-time certification gets planned carefully because everyone knows it's new and unfamiliar. Re-certification, a year or two later, tends to get planned casually, "we did this before, we know what to do", and that's exactly when things slip, because the person who did it before has moved teams, the control has quietly drifted from what was originally documented, and nobody re-reads the old evidence until the new audit is uncomfortably close. A wiki with page history is specifically useful here: the record from the first cycle is still there, dated and attributed, so the second cycle starts from what actually happened rather than from memory of what someone thinks happened.