Team Management
Plans don’t deliver projects; people do, and they mostly do it through each other. This chapter is about the part of project management that no schedule can carry: who is on the team, who cares about the result, and how information moves between them.
In short
- Most project failures are coordination failures, not capability failures. The team could have done it.
- Three things need managing: the team, the stakeholders around it, and the flow of information between them.
- They fail together. A strong team with weak alignment builds the wrong thing very well.
- This is the chapter that pays off most for people who aren’t the project manager.
Why this is the part that decides outcomes
Look at any post-mortem and the technical difficulty is rarely the headline. The headline is that two teams built to different assumptions, or that the person who could have said “that won’t work” wasn’t asked, or that a decision made in one room took five weeks to reach the room where it mattered.
This isn’t sentimentality about teamwork. It’s arithmetic. A project with six people has fifteen possible pairs who might need to agree on something; twelve people have sixty-six. Capability scales linearly with headcount and coordination cost scales roughly with its square, which is why adding people to a struggling project so often makes it slower.
Everything in this chapter is a way of holding that cost down: fewer people who need to talk to each other, clearer about what each of them owns, with an agreed rhythm for the conversations that genuinely have to happen.
What thin people-management looks like from inside
Nobody announces that stakeholder management is weak. These are the observable versions:
- Decisions get re-opened. Something was agreed in one meeting and is questioned again two weeks later by someone who wasn’t there. Not obstruction — they genuinely didn’t know.
- One person is in every conversation. If a specific individual has to be present for anything to move, you have a coordination bottleneck wearing the costume of a valuable expert.
- Meetings that only report. Everyone takes turns describing what a tool already shows. This is a symptom of a communication plan that doesn’t exist, so the meeting is doing its job by hand.
- Late requirements from senior people. Almost always a stakeholder who was identified too late, and whose need was legitimate all along.
- Silence from part of the team. A person who has stopped raising problems is not a person without problems. This one is expensive and easy to miss because it looks like everything is fine.
- “Who owns this?” has no fast answer. Ownership ambiguity converts every small issue into a negotiation before it can become work.
Each of these has a home in this chapter: the first, third and last in 4.3; the second and fifth in 4.1; the fourth in 4.2.
How much of this does a project need?
The opposite failure is real and common: a project so wrapped in rituals, RACI charts and status forums that the ceremony consumes the capacity it was supposed to protect. The right amount scales with two things — how many people have to coordinate, and how many of them sit outside your team.
3–5 people, one team
Roles agreed in a conversation. Stakeholders are two names. Communication is a shared board and a short weekly check-in. Anything more is theatre.
6–15 people, two or three teams
Write down who owns what. Map the stakeholders properly. Agree a communication rhythm with named owners, because assuming stops working at this size.
Many teams, or external parties
Explicit interfaces between groups, a real engagement plan, and someone whose actual job is the seams. At this scale coordination is the work, not overhead on it.
A useful check: how long does it take a decision to reach everyone it affects? If the honest answer is more than a few days, add structure. If it’s hours and people are complaining about meetings, remove some.
How the three fit together
They’re usually approached in order — form the team, map the stakeholders, agree how you’ll communicate — but the loops backwards are the interesting part, and they’re normal rather than a sign of poor planning:
- Stakeholder mapping changes the team. Discovering that a compliance group must approve the design means you need someone who can talk to them, which is a staffing decision.
- Communication load changes the structure. If the plan needs five different weekly updates, the problem isn’t the plan — it’s that the project has too many independent interfaces. Restructure rather than schedule.
- The team changes the stakeholder map. Adding a vendor adds their account manager, their security reviewer and their legal team to the list of people whose availability you now depend on.
If you’re not the project manager
This chapter is the one where non-managers have the most leverage, because the failures above are mostly visible from inside the work before they’re visible from above it. Three things worth doing regardless of your title:
- Say when you’re blocked, early and specifically. “I’m waiting on the security review, and if it lands after Thursday my task slips” is a fact someone can act on. “It’s going okay” is not.
- Name the stakeholder nobody has mentioned. If you’ve worked in the area before, you probably know who is going to appear in month four with an objection. Say so in month one.
- Ask who else needs to know. Thirty seconds of asking prevents the class of failure where a decision was made and simply never travelled.
How this looks in AB
Across all three sub-sections, one design choice in AB Projects does most of the work: the project member list is the team, and stakeholders are members too rather than a separate audience you ship reports to. That means everyone sees the same tasks, the same status and the same dates — the real thing, not a curated summary assembled the night before.
The rest follows from it: assignees make ownership visible per task, the project Wiki holds roles and the stakeholder map next to the work they describe, and Adaptive Cards in the linked Teams or Slack channel push changes to where people already are instead of waiting for them to come looking. The chapters ahead cover each of those in detail.
What this chapter covers
Building a Project Team
Choosing who is on it, making ownership unambiguous, and what to expect from a group that hasn’t worked together before.
Stakeholder Management
Finding everyone who can affect the project — ideally before they find you — and deciding how much attention each one gets.
Communication Planning
Deciding who hears what and when, so that information moves without anyone having to remember to move it.
Terms used on this page
- Project team
- The people doing the project’s work, usually borrowed from their normal roles for its duration. Distinct from the wider set of people affected by it. More →
- Stakeholder
- Anyone affected by the project or able to affect it — sponsors, users, regulators, neighbouring teams. Unmanaged stakeholders become late-arriving requirements. More →
- RACI
- A way of recording who is Responsible, Accountable, Consulted and Informed for each decision or deliverable. Useful mainly for finding the rows where nobody is accountable. More →
- Communication plan
- An agreement about who receives what information, how often and through which channel. Small enough to fit on one page, or it won’t be followed. More →
- Sponsor
- The person who funds the project and decides the trade-offs the team cannot. The single most important stakeholder to have named. More →
- Escalation
- Passing a decision or a problem to someone with the authority to resolve it. A healthy project escalates fast and without drama. More →
Related reading
3.3 Resource Allocation
The capacity side of the same question: not just who is on the team, but how much of them you actually have.
6.3 Reporting Progress
What the communication plan actually carries once the project is running.
2.3 The Execution Phase
Where coordination is tested daily, and where removing blockers beats collecting status.