How to Manage a Project When Half the Team Is Part-Time

We ran a project last year where four of six people worked fewer than twenty hours a week. Two were finishing degrees. One had a second job she didn't tell clients about, which was her business. The schedule looked like a patchwork quilt: Maria online Tuesday and Thursday mornings, Devon online whenever his shift at the restaurant let up, Priya only after 8pm her time. On paper it was fine. In practice, the project stalled every single week at the same point — handoff — because our process assumed someone would always be around to answer a quick question.

Nobody was around. That was the whole point of hiring part-time. And the process we'd built, which worked great when five of us sat in the same office, kept breaking on the same seam: it assumed continuity. It assumed if Maria left a task half-done, she'd be back in an hour to finish the thought. She wouldn't be. She'd be back in two days.

The failure mode isn't laziness, it's synchronous assumptions

When a team is full-time and co-located, most process gaps get papered over by proximity. Someone asks a question out loud, gets an answer in ninety seconds, moves on. Nobody writes anything down because nobody has to. The moment half your team works fifteen to twenty hours a week, spread across different days, that informal repair mechanism disappears. And most PM habits — daily standups, "just ping me," open-ended tasks with no clear single owner — are built entirely on that repair mechanism existing.

Part-time teams don't fail because the people in them care less. They fail because a process tuned for constant availability gets run by people who are, correctly, not constantly available.

Ownership has to be explicit, not implied

In a full-time room, ambiguous ownership resolves itself — whoever notices the ball dropping picks it up, because they're standing right there. Part-time teams don't get that. If a task doesn't clearly say who's doing it, it sits. Nobody's watching closely enough, often enough, to notice it sitting.

We stopped assigning tasks to "the design team" or leaving them unassigned with a due date and a vague hope. Every task gets one name. If two people genuinely need to collaborate, one owns it and the other is a contributor, and that's written down too — not implied by who spoke last in a thread.

Narrower work-in-progress, on purpose

A full-time person can hold four things in flight and context-switch between them because they're present enough to keep track. Someone working three four-hour shifts a week cannot. If Devon has three tasks open, he's not further along — he's just got three half-finished things waiting for the next four-hour window, and when that window opens he spends the first twenty minutes remembering what he was doing instead of doing it.

The fix we landed on: part-time contributors get one task in progress at a time, sometimes two if they're genuinely independent. It feels slower on a spreadsheet. It's faster in the actual calendar, because nothing sits half-remembered for three days waiting for a head that's elsewhere.

Handoff notes are the actual job, not overhead around the job

This is the one that took us longest to learn. When a full-time team member stops for the day, the work is still "live" in their head, and if someone needs the next piece, they can just ask. When Priya logs off at 9pm and won't be back until Thursday, whatever's in her head might as well not exist. If she didn't write it down, it's gone for two days, and whoever picks up the task next either waits for her or redoes the thinking from scratch.

So we made the handoff note a required last step, not a courtesy. Not a paragraph of prose — three lines: what's done, what's not, what the next person needs to know that isn't obvious from looking at the file. It takes ninety seconds. It has saved us, conservatively, hours a week, because the alternative was someone spending twenty minutes reverse-engineering a half-finished spreadsheet formula that made sense to exactly one person at 11pm on a Tuesday.

Design dependencies around availability windows, not around org charts

A dependency chain that works for a full-time team — A finishes, hands to B, B finishes same afternoon, hands to C — falls apart if A works Mondays, B works Wednesdays, and C works whenever she can grab an hour. You've built a three-person relay where each leg takes a week, not because the work takes a week, but because the handoff waits on the next person's availability window.

We started mapping dependencies against actual hours before we mapped them against skill. If Devon's the only one who can do the next step and he's only online Thursday evenings, that step is Thursday's step, full stop — we don't queue three more things behind it hoping he squeezes them in. Sometimes this means restructuring who does what, not because someone's less qualified, but because their four open hours a week don't line up with the chain.

Availability assumptions, stated plainly, once

We keep a short, boring, unglamorous list: who's around which days, roughly which hours, and how fast they typically respond when not actively working. It's not a schedule anyone has to maintain hour by hour. It's a rough map so nobody assigns a same-day due date to someone who's structurally not available same-day, and nobody waits three days for an answer from someone who checks messages every morning.

This sounds obvious written down. It is constantly ignored in practice, because writing the availability list feels like overhead and the cost of skipping it doesn't show up until week three, as a due date nobody could have hit.

Where a spreadsheet is honestly enough

If your part-time team is two people and one project, a shared doc with a task list and a weekly check-in might genuinely be enough. You don't need a system for managing dependencies you can hold in your head. The line gets crossed when you have more than a couple of dependency chains running at once, or more than a couple of people whose hours don't overlap with anyone else's — that's when an informal list stops being able to carry the information a handoff actually needs, and someone starts quietly becoming the person who remembers everything, which is exactly the job nobody part-time signed up for.

That's the actual test, not headcount. Can the whole team's current commitments and open handoffs live in one person's head without that person burning out keeping it there? If yes, keep the spreadsheet. If no, you need something that survives the gaps between shifts — because the gaps are the whole shape of the team, not an inconvenience around the edges of it.

We use Team and Tricks for this now, mostly because a task that's still a Draft doesn't notify anyone — so Maria can rough out Thursday's plan on Tuesday night without waking Devon's phone up, and it only goes live to the team once it has a real due date attached. The handoff note lives on the task itself, not in a chat thread that scrolls away by the time the next person logs on.