Project Management for Client Projects

The part that breaks isn't usually one project

When a team runs several client engagements at once, the failure rarely traces back to one project being planned badly. It's that three different clients each got a "yes" in the same week from three different people, and nobody added up what those three yeses meant for the two people all three requests actually depend on. Every account looked fine on its own. The team, underneath all of them, was not.

The usual fix is a spreadsheet trying to hold every client's timeline next to everyone's name, updated whenever someone remembers to open it. It's stale within a week, because the thing that actually determines what can be promised, who is genuinely free on Thursday, changes faster than a shared sheet gets touched.

ShipSprint's approach is to give each client engagement its own board, while treating capacity as a property of the person rather than of any single board. A designer staffed across four client accounts has one real number for how much more they can take on, and that number doesn't get invented four separate times by four people who can't see each other's requests.

None of that requires a bigger process. It requires the four boards to agree on one thing underneath them, which is what the rest of this page is about.

It's also worth naming what this page isn't: it isn't about the one-time work of bringing a new client on, which is its own narrower workflow with its own checklist. This is about the ongoing state of running several accounts at once, month after month, where the main risk isn't any single kickoff going wrong but the slow accumulation of five separate "just this once" exceptions that together add up to nobody actually knowing who's free.

One person, several boards, one capacity figure

Per-column WIP limits apply to the board a piece of work sits on, but a person's real load is visible across every board they're part of, so adding a fifth task to a designer already stretched across two other client accounts isn't a decision anyone can make without noticing. The limit isn't a per-client fiction; it reflects what the person can actually do.

New requests, whichever client they arrive from, land in a shared triage inbox rather than as a message to whoever seems reachable. That's a small mechanical difference with a large effect downstream: taking on new client work becomes a decision made on purpose, with the current load in view, instead of a reflex reply typed in the moment a request lands.

It also means the awkward conversation, telling a client their request has to wait two weeks, happens because of a number the team can point to, not a guess someone has to defend after the fact.

Delivery forecasts work the same way. Because each project's forecast comes from that project's own measured velocity, a client who's used to hearing optimistic dates gets something different: a date the team's actual recent throughput supports. When scope on one account grows mid-stream, that account's forecast moves. It doesn't get quietly absorbed by borrowing time that was actually committed to a different client.

What a bad week looks like without this

The failure has a familiar shape. Client A asks for something small on Monday and gets a yes, because it sounds small. Client B asks for something on Tuesday and gets a yes for the same reason. By Wednesday, the one developer both requests actually need is double-booked, and nobody realizes it until Thursday, when both clients are told, separately, awkwardly, that their thing is delayed.

Nothing about that week involved bad judgment in the moment. Each "yes" was reasonable on its own. What was missing was a single place where both requests were visible before either one was promised, which is what a shared triage inbox and a real capacity figure are actually for. They don't make the team faster. They make the second "yes" honest before it's given, not after.

What "sharing progress with a client" actually means here

There's no client login. ShipSprint has no portal a client signs into, no guest role, no external-user access of any kind, the workspace stays internal to your team. What it does have is a roadmap and board that stay accurate day to day, so when someone relays status to a client on a call or over email, they're reading from the system the work actually runs on, not rebuilding a summary the night before.

For a team that assumed "client projects" meant client-facing screens, that's worth knowing before signing up rather than after. What's on offer is narrower and, for most client work, closer to what actually gets used: an internal picture reliable enough that relaying it takes minutes, not an hour of reconstruction.

The same applies to decisions made mid-account. When a client asks for a change and the team agrees to it, the reasoning can go straight onto that client's wiki page, not because the client will ever read it, but because six months later, when someone new joins the account and asks why the scope shifted in March, there's a written answer instead of whoever remembers being asked to explain it from memory.

What each client engagement gets, and what it costs

• Free covers up to 5 users and 2 projects, forever, enough to run one or two small accounts before deciding whether more is needed.
• Team is ₹299 per user per month (₹2,899 a year) for up to 40 users, which is where most teams running several client boards at once land.
• Business is ₹599 per user per month (₹6,499 a year) and adds forecasts, leave-adjusted scorecards, and the owner command center that rolls every account into one view. See pricing for the full breakdown.
• Every paid plan starts with a 14-day trial on the full Business tier, no card needed, with a sample project already sitting on the board.
• Billing is per seat in rupees with GST-compliant invoices, and annual billing is available if that suits how the accounts are budgeted.