Project Management for Procurement Projects

Vendor work is relationship work with a gate in the middle

Procurement is two different jobs wearing one title. There's the ongoing relationship management: tracking vendor performance, renewal dates, contract terms, the running list of who's reliable and who isn't. And there's the purchasing workflow itself, where a request has to pass some kind of check before money moves: is this the right vendor, is this in budget, has anyone with the authority to say yes actually looked at it.

Both halves tend to be badly served by general project tools. Vendor relationships get tracked in a spreadsheet that's accurate the day it's built and stale within a month. And purchasing requests without a real checkpoint have a way of sliding through on momentum: a request gets forwarded, someone assumes someone else approved it, and the first real scrutiny happens after the money is already spent.

ShipSprint doesn't have a configurable approval chain. No step builder, no routing by threshold, no "auto-approve under a set amount." If your procurement process genuinely needs named approval roles with conditional routing by amount, say that plainly before trying to force it onto a board; that's a real gap, not a detail to work around. What ShipSprint has instead is a different mechanism that does a similar job for teams whose actual need is simpler than a chain.

A capped column stops things a status field doesn't

The mechanism is a WIP limit on a review-stage column. Set "Awaiting sign-off" to hold four cards, and once it's full, a fifth request cannot enter. Someone has to actually resolve one of the four first, by approving, rejecting or bumping it. That's a hard stop, not a status anyone can quietly change; a full column stays full until something moves, regardless of who wants to skip the line.

The intake side works the same way, earlier. Before a purchase request becomes a task at all, it sits in a shared triage inbox. That's the moment someone with the authority to say yes has to actually open it and decide it's worth starting, which is closer to the approval decision most teams actually need than a sign-off buried after the work is half-done.

This is a blunter instrument than a real approval chain, and it's worth being honest about the difference. A capped column doesn't distinguish an approved item from an unapproved one; if the column is full, both wait. There's no per-step audit field or conditional routing by vendor risk tier. What you get in exchange is zero configuration, nothing to maintain when the process changes, and a stop that's genuinely hard to route around by pinging the approver directly, because the block is a count against a number, not a status a message can override.

A purchase request, start to finish

A department lead submits a request for a new software subscription. It lands in the procurement triage inbox rather than an inbox belonging to whichever procurement person happens to have a relationship with that department, visible to the whole team from the moment it arrives, not just the one person who might be on leave that week.

Someone pulls it from triage, checks it against the vendor's existing card (is there already a relationship here, is there a cheaper alternative already in use elsewhere in the company), and moves it to "awaiting sign-off." That column is capped at five. It's currently at five, so the request waits, visibly, until the person clearing approvals gets through the backlog rather than rubber-stamping a sixth item just to keep the queue from looking bad.

Once approved, the decision and the reasoning get a line on the vendor's wiki page, not because a form requires it, but because the next person evaluating that vendor in eight months will want to know why this one was approved and a competitor wasn't. That's the record a scattered approval-by-email process almost never leaves behind.

Where this genuinely falls short

• No conditional routing by amount, vendor risk or department: a ₹500 request and a ₹5,00,000 request hit the same capped column with no built-in distinction.
• No named approval roles enforced by the system: who's allowed to clear a card is a team convention, typically written on a wiki page, not a permission the software checks.
• No dedicated procurement audit report: admin actions are logged and wiki history is kept, but there's no purpose-built compliance export for purchasing sign-offs specifically.

Teams that adopt this approach generally size the review column to fit real volume: tight enough to catch the case it's meant to catch, loose enough that approved requests aren't stuck waiting behind slower ones. It's a five-minute adjustment when it's wrong, not a workflow redesign.

The rest of the business, one subscription

Procurement sits between whichever team wants something and whoever has to say yes to buying it: engineering wanting a new tool, marketing wanting an agency, operations wanting a vendor switched. Because every department runs on the same subscription, those requests arrive in procurement's triage inbox in the same shape regardless of which team they came from, instead of as an email from one team and a Slack message from another.

ShipSprint also connects to Claude and ChatGPT, so a question like "which vendor renewals are coming up this quarter" can be answered without opening the board.

That cross-department visibility also cuts down on a quieter cost: duplicate purchasing. When engineering and marketing both submit requests for a similar tool six weeks apart, having both pass through the same triage inbox, rather than two separate inboxes nobody compares, means someone is positioned to notice the overlap before two contracts get signed for roughly the same thing. That's the concrete payoff of a shared inbox instead of a departmental one: it catches waste that would otherwise only surface when someone happened to compare invoices.