5.3 Project Teams, Leading Effective Teams and Communication

5.3 Project Teams, Leading Effective Teams and Communication

Quick summary: Delivery teams are cross-functional and self-managing within agreed boundaries. Servant leadership means putting team members' needs above your own. Decision rights are made explicit with a delegation matrix or delegation poker; capability is mapped with a team skill matrix. The kickoff workshop establishes introductions, values and norms, decision-making and the team dashboard. Rich communication is preferred because it transfers the most understanding per unit of time.

What makes a project team effective

Cross-functional

The team contains all the skills needed to take an item from idea to done: analysis, design, build, test, and whatever specialisms the domain requires. The purpose is to eliminate hand-offs, which are where delay, queueing and misunderstanding live. A team that must wait for a separate testing department cannot finish work within an iteration, and its Definition of Done becomes aspirational.

Self-managing within boundaries

The team decides how it will do the work — sequencing, technical approach, who takes what, how much to pull into an iteration. What it does not decide unilaterally is what the priorities are (the product owner's accountability) or what lies outside its tolerances (the project manager's and the project board's).

The boundaries matter as much as the autonomy. "Self-organizing" without stated limits produces either paralysis or an unpleasant surprise at the stage boundary. Manage by exception is the PRINCE2 principle that draws the line explicitly.

Right-sized and stable

Small enough to communicate without formal machinery, large enough to hold the necessary skills. Stability matters because a team's throughput depends on relationships and shared context that are destroyed and slowly rebuilt every time membership changes — which is why adding people to a late project generally makes it later.

Techniques for building the team

• Team skill matrix. A grid of people against skills, showing who can do what and at what level. It exposes single points of failure — the one person who can deploy to production — and drives deliberate cross-skilling.
• Delegation matrix. A statement of decision rights: which decisions the team takes alone, which it takes after consulting, and which are escalated.
• Delegation poker. A collaborative technique for defining decision-making within teams. The team and its manager independently pick a level of delegation for a given decision type, reveal simultaneously, and discuss the differences. Like planning poker, the value is the conversation the disagreement provokes — it surfaces the gap between the autonomy a manager thinks they have granted and the autonomy the team believes it has.
• Working agreements and team norms. Explicit agreements about how the team will work: core hours, definition of a blocker, how disagreement is handled, what the Definition of Done contains.
• Swarming. The whole team converging on a single item to finish it, rather than everyone working separately on their own item. It reduces work in progress and gets value delivered sooner.

The kickoff workshop

The kickoff workshop is where a delivery team is formed deliberately rather than by accident. The syllabus's examinable content is what the workshop establishes:

• Team introduction — the element that aims to foster familiarity and establish connections between team members. In a newly formed cross-functional team drawn from different departments, this is not a social nicety; it is the foundation of the psychological safety the team will need.
• Team values and norms — how the team agrees to work together.
• Decision-making arrangements — often captured in a team decision matrix, and often arrived at through delegation poker.
• The team dashboard — how the team will make its own work visible.

Servant leadership

Servant leadership means putting the needs of team members above your own. The leader's job is to enable the team to be effective rather than to direct its work.

In practice a servant leader:

• Removes impediments. Chases the missing access, resolves the dependency, deals with the stakeholder generating noise.
• Provides context, not instructions. Explains why the work matters and what success looks like, then leaves the how to the team.
• Shields the team from interruption and from unreasonable demands.
• Develops people, treating capability growth as part of the job rather than a distraction from it.
• Takes responsibility for failure and gives credit for success, which is one of the strongest builders of psychological safety.

Servant leadership is the natural style for a team coach or agile coach, and it is the style a project manager adopts towards delivery teams in a PRINCE2 Agile project. Note that it does not mean the absence of leadership or of accountability. The project manager remains accountable for the stage within its tolerances; servant leadership describes how they exercise that accountability, not whether they hold it.

Distinguish it from the distractors that commonly appear: believing that any person can learn is a growth mindset; understanding the application of proposed changes is change management; communicating using body gestures is non-verbal communication.

Communication

Communication is treated as a core project management activity because most project failures are, at some level, communication failures: a misunderstood requirement, an unreported risk, a stakeholder who was never engaged.

Rich communication

PRINCE2 Agile prefers rich communication — forms that carry the most information per unit of time and allow immediate clarification. Ranked roughly by richness:

Richer channels are better for ambiguous, contentious or novel matters — working out a requirement, resolving a disagreement, planning together. Leaner channels are better for precise, referenceable, durable information — a decision record, an approved product description, an audit trail.

The examinable point is that the choice is contextual. Nobody argues for abolishing documents; the argument is against using a document to do a conversation's job, which is how a two-minute misunderstanding becomes a three-week email thread.

Other communication ideas

• Information radiators — dashboards and boards that broadcast status continuously, so status has to be noticed rather than requested.
• Workshops — the highest-value communication format, because participants produce a shared artifact rather than merely exchanging information.
• Tailoring to the audience. The project board needs tolerance consumption, benefit forecasts and top risks. The delivery team needs priorities and impediments. The same underlying facts, presented differently.
• Remote and hybrid working. Distributed teams lose the incidental communication that co-located teams get free, so they must deliberately engineer replacements — video by default, generous written context, and explicit norms about responsiveness.