Building a Project Team
A project team is a group of borrowed people, assembled for a while, asked to do something none of them has done in this exact form before. That is a genuinely harder starting position than a standing team, and most of the advice in this section exists because of it.
In short
- Pick for coverage, not headcount. An area only one person can do is a schedule risk wearing a name badge.
- Every deliverable needs exactly one accountable person. Two is zero.
- A new group is genuinely slower for the first few weeks. Plan for it rather than being surprised by it.
- People on loan have another boss. Their manager needs to have agreed, out loud, to the time you think you have.
What makes a project team different
A standing team has three advantages a project team has to manufacture: they already know each other’s strengths, they already have working habits, and they have a shared future that makes short-term generosity rational.
A project team starts with none of those and has a deadline. It also has a structural awkwardness: most members still report to somebody else. When their day job and your project collide, you find out quickly whose priorities are real. That’s not disloyalty; it’s an unresolved allocation, and it’s resolved with the person’s manager, not with the person.
Choose for coverage, not headcount
The usual staffing conversation is about how many people you need. The more useful one is which capabilities the work requires, and how many people can supply each of them.
The two orange rows are worth sitting with. Neither is a problem today — Priya is here, Dev is here, the work is moving. They become problems the moment one of them is ill, resigns, or is pulled onto something more urgent, and by then there is no cheap fix.
The cheap fix, available now, is any of:
- Pair for a week. Someone shadows the deployment work. Costs a few days, converts an orange row to a grey circle.
- Write it down. A runbook for the thing only one person knows. Less good than a second person, far better than nothing.
- Sequence around it. Move the single-point work earlier, so if it goes wrong you find out while there’s still slack.
- Accept it, explicitly. Put it on the risk register with a trigger. Sometimes the cost of cover genuinely isn’t worth it — but that should be a decision, not an oversight.
Ownership: one name per thing
The most common structural defect in a project team isn’t a missing skill. It’s a deliverable that two people are half-responsible for, which reliably produces work that neither of them drives and both of them assume the other is handling.
The rule is unglamorous: every deliverable has exactly one accountable person. Others contribute, review and advise. One name is answerable for whether it happens.
This is what a RACI chart is for, and it’s worth being honest about how to use one. Building a full matrix for a small project is usually make-work. What’s valuable is the specific check it forces:
- Any row with no A? Nobody is accountable. This work will drift.
- Any row with two As? Same thing, dressed better.
- Any row where everyone is C? That decision will take three weeks.
- Anyone who is A on eight rows? That’s your bottleneck, and it is probably you.
You can run that check on a napkin. The chart is optional; the four questions aren’t.
The first few weeks are slower, and that’s normal
A group that hasn’t worked together is not a team yet, and the gap between the two is measured in weeks. The classic description — forming, storming, norming, performing — is more useful as a warning than as a model: it tells you that the awkward, argumentative middle stage is a stage, not a sign you picked the wrong people.
| Stage | What it looks like | What helps |
|---|---|---|
| Forming | Polite, cautious, agreeing with everything. Very little disagreement, which is not the same as alignment. | Be concrete early: who owns what, what “done” looks like, when you meet |
| Storming | Friction over approach, standards, who decides. Uncomfortable and completely normal. | Decide the contested things visibly rather than letting them simmer |
| Norming | Working habits settle. People start to route around you rather than through you. | Step back. Resist adding process to a system that is starting to work |
| Performing | The team solves problems without escalating them. Your job becomes removing obstacles. | Protect it — changing membership resets the clock |
That last note has a practical consequence for planning: a team whose membership churns every few weeks never leaves the first two rows. If you have a choice between a slightly less ideal person who will stay and a perfect one who will be pulled away in a month, take the one who stays.
Motivating people you borrowed
You typically don’t control pay, promotion or their objectives. What you do control turns out to matter more over a project’s length:
Make the point of the work visible
People do markedly better work when they know who it’s for and what changes if it succeeds. This is free, and it is the reason the charter’s purpose statement is worth writing well.
Give real ownership
“You own the migration” produces different behaviour from “here are your tasks”. Ownership includes the right to decide how, not just the duty to finish.
Remove obstacles visibly
The fastest way to earn a borrowed team’s attention is to unblock something they’ve been stuck on. Do it once and the flow of early warnings improves permanently.
Tell their manager they did well
Costs one message, lands where their actual career is decided, and is the single most underused tool available to a project manager.
Partners, vendors and other departments
People from outside your team bring capacity and three predictable frictions: they need onboarding time you must plan for, they answer to different priorities, and their knowledge leaves when they do.
What works: name a single point of contact on each side rather than letting communication mesh; be more explicit about “done” than you would be internally, because shared context can’t be assumed; and put knowledge transfer in the plan as a dated task rather than an intention — see 7.3 Knowledge Transfer.
How this looks in AB
In AB Projects, the project members list is the team. Adding someone scopes their visibility to that project — they see its tasks, its Wiki and the linked Teams or Slack channel, and nothing from projects they don’t belong to. Combined with the per-task assignee, that gives a live answer to “who is on this team, and who is doing what” without anyone maintaining a separate list.
Roles and responsibilities sit naturally in the project Wiki — a pinned “Roles” page holds the human-readable version, while task assignments turn it into something the team executes against rather than a chart nobody revisits.
Two habits worth adding by hand:
- Keep the coverage map with the team page. Nothing in a tool tells you who could do a piece of work — only who is doing it. That distinction is the whole diagram above.
- Put single-point dependencies on the risk list. The orange rows deserve an owner and a trigger, not just an awareness.
Worth noting that AI assistants connected through the MCP server can read tasks, post comments and create subtasks like any other member, with the change-history tab keeping every action attributable. Useful for routine updates — and the same coverage question applies: if a step only works because one assistant is configured a particular way, that’s an orange row too.
Terms used on this page
- Project team
- The people doing the project’s work, usually borrowed from their normal roles for its duration and returned at the end. More →
- RACI
- A record of who is Responsible, Accountable, Consulted and Informed for each deliverable. Its value is in exposing rows with no accountable name, or two. More →
- Single point of dependency
- A piece of work only one person can do. Invisible while they’re present, and the most reliable predictor of where a schedule will break. More →
- Matrix organisation
- A structure where people report to a line manager while also working on projects led by someone else. Efficient, and the origin of most priority conflicts. More →
- Tuckman model
- The forming–storming–norming–performing description of how new groups settle. Most useful as reassurance that the awkward phase is a phase. More →
- Runbook
- Written instructions for performing a task someone else normally does. The cheapest partial insurance against a single point of dependency. More →
Related reading
3.3 Resource Allocation
How much of each of these people you actually have, once meetings and operational work are subtracted.
4.2 Stakeholder Management
The people around the team who can affect the outcome without doing any of the work.
3.4 Risk Management
Where single points of dependency belong once you’ve found them, complete with a trigger.