Lead the Project Team

Introduction

This lesson covers Task 1.3 of the People domain of the July 2026 PMP Examination Content Outline (ECO), a domain that carries 33% of the scored questions. Leading a team is different from managing tasks. Management makes sure the plan is executed; leadership creates the conditions in which a group of people want to deliver it, can decide for themselves, and know what is expected of them. The exam describes teams that are predictive, agile or hybrid, co-located or distributed, and asks what the project manager should do to set expectations, empower people, solve problems and choose a style that fits the situation.

After this lesson you will be able to set expectations at team level, empower a team and delegate decisions, support problem solving without taking it over, represent the voice of the team to sponsors and stakeholders, use the varied experiences and skills of team members, choose a leadership style on purpose, and define roles with tools such as a RACI matrix and a team agreement.

Learning objectives

• Establish clear expectations for behaviour, quality, communication and decisions at team level.
• Empower the team by delegating decisions and removing obstacles instead of directing every step.
• Support team problem solving with structured approaches and the right level of involvement.
• Represent the voice of the team accurately to the sponsor, the PMO and other stakeholders.
• Use the different experiences, skills and perspectives of team members as an asset.
• Select a leadership style that fits the team's maturity, the task and the context.
• Document roles and responsibilities with a RACI matrix and a team agreement.

1. Establish expectations at team level

A team that does not know what is expected will invent its own rules, and the rules will differ from person to person. Expectations should be set early and revisited, and they should cover at least five areas:

Expectations are not just announced. In a predictive project the project manager typically leads a kick-off, presents the objectives and asks the team to react. In an agile team the team itself writes its working agreement during the first iteration or a team-formation workshop. In both cases the key is two-way agreement: people commit more readily to what they helped shape.

Example: expectations on a distributed team

A retailer builds a new loyalty app with 14 people in four time zones (Lisbon, Warsaw, Bangalore, Manila). Early on, developers in Bangalore complain that pull requests wait two days for review, while reviewers in Lisbon complain that requests arrive without a description. The project manager does not blame either group. She runs a one-hour session with representatives from each location and the team agrees:

• Each pull request has a template: purpose, test evidence, risk.
• A review is requested before the end of the author's day and answered within the next 24 hours, with a "follow-the-sun" reviewer pairing.
• Anything blocking is raised in the shared channel and tagged, not sent by private message.

Two weeks later, the median review wait drops from 38 hours to 14. The expectation was not a punishment; it was a shared definition of good practice, and it was written in the team agreement.

2. Empower the team

Empowerment means giving the team the authority, information and resources to make decisions within agreed boundaries. It does not mean abandoning the team. The project manager clarifies the boundaries (budget, scope, quality, compliance, deadlines), and inside them the team decides how to do the work.

Practical ways to empower:

1. Delegate decisions at the lowest competent level. If the testers know best how to test, they choose the approach within the quality criteria.
2. Remove impediments. The leader's work shifts from assigning tasks to clearing obstacles: waiting for access, unclear priorities, conflicting demands from managers.
3. Provide context, not instructions. Explain the why: the business goal, the customer, the constraints. People who understand the purpose make better choices.
4. Accept that people will sometimes decide differently. Use the result as learning rather than as a reason to take back control.
5. Protect the team from outside interruptions and unplanned work, particularly during an iteration.
6. Invest in skills. Training, pairing and mentoring increase the number of decisions the team can safely make.

Servant leadership, a core idea in agile approaches, applies the same principle: the leader serves the team by listening, removing obstacles, coaching and keeping the focus on the goal. It is not a style reserved for Scrum; the ECO expects the project manager to adapt it to predictive and hybrid projects as well.

Delegation levels

Delegation is not all or nothing. One practical scale, popular in agile coaching, defines seven levels:

A new team, or a high-risk decision, may start at levels 2 or 3. A mature team can move to 5 or 6 for most topics. Moving along this scale deliberately is a visible sign of empowerment.

3. Support team problem solving

When something goes wrong, the natural reaction of a project manager is to fix it. The leadership move is to help the team fix it. The sequence is usually:

1. Define the problem in facts, not in blame: what happened, since when, what is the impact.
2. Find the cause with a tool suited to the problem: the five whys for a simple chain of causes, a cause-and-effect (fishbone) diagram for several possible categories, a Pareto chart to find the few causes behind most of the effects.
3. Generate options, ideally with a quiet brainstorm first (individual writing), then discussion, to prevent the loudest voice dominating.
4. Choose with explicit criteria (cost, time, risk, value) and agree how the decision will be made (consensus, consent, vote, leader's decision).
5. Act, check and learn. Assign an owner, set a date to verify the result, and capture the lesson.

The project manager's role is that of facilitator: framing the question, keeping the discussion on the subject, ensuring that quiet members are heard, and making sure the decision gets an owner. When the problem is outside the team's authority, such as a budget increase, the leader takes it to the right level, and brings the team's analysis and options with it.

Worked example: a recurring defect

Scenario. A hybrid project to build a patient-booking portal has had the same defect type three times in two months: appointment confirmations are sent twice. The team has patched the symptom each time. A developer suggests rewriting the notification module, which would cost three weeks. The project manager has a sprint review in four days.

Step 1 - Define. The project manager gathers the facts: three incidents, 120 patients affected in total, no data loss, patient complaints rising.

Step 2 - Find the cause. She facilitates a 45-minute session using the five whys. Why were two messages sent? Both the booking service and the reminder job triggered them. Why? The reminder job retries when it receives a timeout. Why a timeout? The messaging provider is slow at peak times. Why no check for an already sent message? Nobody owns the contract between the two components. Why? The architecture was agreed before the reminder feature was added and never revisited.

Step 3 - Options. The team lists: (a) rewrite the module (three weeks), (b) add an idempotency key to the message (two days), (c) disable retries (one day, but loses reminders).

Step 4 - Choose. Using risk and effort as criteria, the team picks (b) now and plans an architecture review of the notification flow for the next iteration; the product owner is informed and agrees to the ordering.

Step 5 - Follow up. The owner is named, a test is added, and the item is reviewed at the next retrospective.

Why not the other choices? A rewrite treats the symptom as a reason for a large, risky change before the cause is known. Disabling retries removes the symptom but creates a new problem (missing reminders). Patching again would repeat the same failure for a fourth time. The project manager led by structuring the thinking, not by dictating the solution.

4. Represent the voice of the team

A project team is rarely in the room when decisions about the project are taken. The project manager speaks for the team in steering committees, with the sponsor, with the PMO and with functional managers. Representing the team well means:

• Being accurate. Report what the team has said, including bad news such as unrealistic deadlines, technical debt or overload, without softening or exaggerating it.
• Bringing evidence. Use velocity, throughput, defect trends and capacity figures, not impressions.
• Protecting the team from unreasonable demands by negotiating scope, time or resources, while respecting the organisation's constraints.
• Closing the loop. Share decisions from the higher level with the team promptly and explain the reasoning behind them, so that people do not hear about changes through rumours.
• Making team achievements visible to the sponsor and the organisation. Recognition is a powerful motivator and also reinforces the behaviours you want.

A common exam trap is the answer in which the project manager "keeps the team away from stakeholders to protect them" or "tells the sponsor whatever they want to hear". Both break transparency. The correct approach is to bring the team's reality to stakeholders, and stakeholders' reality to the team.

5. Use varied experiences, skills and perspectives

Teams that mix ages, professions, cultures and levels of experience tend to find better solutions and spot more risks, as long as people feel safe to speak. Leaders can use that diversity by:

• Mapping skills (a skills matrix) so that work is assigned by capability and gaps are visible. A matrix showing that only one person can deploy to production reveals a key-person risk.
• Pairing experienced and less experienced members, or members from different specialities, to share knowledge.
• Rotating roles such as facilitator, note taker or demo presenter, so that more voices are heard.
• Adapting communication to cultural norms. In some cultures disagreement is expressed directly; in others it is expressed by silence. A leader who asks "what risks do you see?" individually, or through an anonymous poll, gets a fuller picture than one who asks for objections in a meeting.
• Building psychological safety. Team members must feel that they can ask questions, admit mistakes and challenge ideas without being punished. A leader builds it by thanking people for bad news, by admitting their own mistakes, and by responding to errors with curiosity.

Example: finding a hidden risk

A construction-software team is planning a mobile inspection app. A recently hired tester, who previously worked as a site engineer, points out that site workers often wear thick gloves and have no network connection in basements. The project manager records two new requirements: large touch targets and offline mode. These would have been found later, at higher cost, without the tester's experience. The leader's contribution was to create an environment where a junior person's remark was welcomed and acted on.

6. Choose a leadership style

No single style works in every situation. The ECO expects a project manager to choose a style according to the context. The main styles are:

Situational leadership is a useful way to reason about exam questions. It matches the style to the follower's competence and commitment: a beginner who is enthusiastic needs direction; someone who has some skill but is discouraged needs coaching and support; a capable but cautious person needs encouragement to decide; a capable and committed person can receive delegation. The same project manager may therefore be directive with a new contractor and delegating with a veteran engineer on the same afternoon.

Tuckman's stages (forming, storming, norming, performing, adjourning) also help: in forming the leader gives clarity and structure; in storming the leader facilitates and coaches; in norming and performing the leader steps back and serves.

7. Roles and responsibilities: RACI and the team agreement

Unclear responsibilities are among the most frequent causes of rework and conflict. A RACI matrix assigns, for each activity or deliverable, a single level of involvement for each role:

• R - Responsible: does the work.
• A - Accountable: owns the result and approves it; only one per activity.
• C - Consulted: gives input before the decision (two-way).
• I - Informed: is told after the decision (one-way).

Check a RACI for these typical errors: an activity with no A, an activity with two As, too many Rs without coordination, and so many Cs that decisions slow down. In agile teams a full RACI is unusual; roles are defined by the framework (product owner, scrum master, developers) and by the team agreement, but decision rights still need to be explicit.

A team agreement (team charter or working agreement) records the values, ground rules, communication methods, decision-making approach, meeting norms and conflict-handling principles. Unlike a RACI it covers how people work together. Reviewing it in a retrospective or after any significant change in the team (new member, new location) keeps it alive.

8. Common pitfalls and exam tips

Pitfalls

• Confusing empowerment with absence: delegating without clear boundaries or support.
• Micromanaging a competent team, which reduces motivation and slows delivery.
• Using the same style for everyone and in every situation.
• Fixing the problem yourself rather than helping the team to learn how to solve it.
• Reporting upward only good news.
• Treating diversity as a compliance topic and not as a source of ideas and risk detection.
• Creating a RACI once and never updating it.

Exam tips

• When the scenario shows a capable team that waits for permission, the best answer is usually to clarify the decision boundaries and delegate more.
• When the scenario shows a crisis or a safety risk, a directive style is acceptable for a short time.
• When two options both look reasonable, prefer the one that builds the team's capability and ownership over the one that makes the project manager the hero.
• If a question mentions a new team that is unsure of its roles, think of forming: structure, clarity, team agreement, RACI.
• "Servant leadership" does not mean the leader does the team's work or has no authority; it means the leader's priority is enabling the team.
• A team member's under-performance is first handled with a private conversation about expectations and obstacles, then coaching, and only then formal action.

9. Mini case study

Situation. You lead a hybrid project to move a bank's customer-onboarding process to a new digital platform. The team has twelve people: six developers from two vendors, two business analysts, two testers, a UX designer and a process owner from the bank. After eight weeks you observe the following: developers wait for the process owner to approve even minor wording changes; testers and analysts disagree on who writes acceptance criteria; one vendor's developers rarely speak in meetings; and a manager from the bank's operations department has twice asked individual team members to do extra work without telling you.

Question. What should you do?

Model solution.

1. Diagnose. The symptoms point to unclear decision rights (wording approval, acceptance criteria), low psychological safety among the vendor developers, and a boundary problem with the operations manager. The team is probably between forming and storming, and needs structure and coaching more than a hands-off style.
2. Set expectations and decision rights. Run a team-agreement workshop. Define which wording changes the team can approve inside agreed guidelines (delegation level 5), which need the process owner (level 3), and who writes and who reviews acceptance criteria. Record the results in a RACI and in the agreement.
3. Empower. Give the UX designer and analysts authority to approve minor wording within guidelines, and ask the process owner to review a sample each week instead of every change.
4. Increase participation. Use a round-robin in the planning session, written pre-reads, and a rotating facilitator. Hold a one-to-one with the vendor developers to ask what would help them to contribute.
5. Represent the team. Meet the operations manager and the sponsor. Explain the impact of unplanned work on the delivery date, show capacity data, and agree that requests go through the product owner or you. Report the conversation to the team.
6. Review. Check in the next retrospective whether waiting time has gone down and the team feels safer.

Why this is best. It addresses root causes, adapts the style to the team's maturity, builds the team's capability and protects it from outside interference. Taking all decisions yourself would create a bottleneck; blaming the vendor developers or ignoring the operations manager would leave the causes in place.

Key terms

• Empowerment: giving the team authority to decide within defined boundaries.
• Servant leadership: leadership that prioritises enabling and supporting the team.
• Situational leadership: adapting style to the readiness of each person or team.
• Psychological safety: the shared belief that a person can speak up without punishment.
• RACI matrix: responsibility assignment chart (Responsible, Accountable, Consulted, Informed).
• Team agreement (working agreement): the team's documented norms and values.
• Delegation levels: a scale from "tell" to "delegate" that describes who decides.
• Tuckman's stages: forming, storming, norming, performing, adjourning.
• Five whys: a root-cause technique that asks "why" repeatedly.

Summary checklist

• I can set and review expectations on outcomes, behaviour, communication, decisions and quality.
• I can empower a team by defining boundaries, delegating decisions and removing impediments.
• I help the team to solve problems with a structured approach instead of solving them for the team.
• I represent the voice of the team honestly, with evidence, and close the loop.
• I use diversity of experience and skills, and build psychological safety.
• I choose a leadership style based on context and team maturity.
• I can create and check a RACI matrix and maintain a team agreement.

Official sources

• PMI, PMP Examination Content Outline (July 2026): https://www.pmi.org/-/media/pmi/documents/public/pdf/certifications/new-pmp-examination-content-outline-2026.pdf (opens in a new tab)
• PMI, the new PMP exam: https://www.pmi.org/certifications/project-management-pmp/new-exam (opens in a new tab)
• PMI, PMP exam change: https://www.pmi.org/blog/pmp-exam-change (opens in a new tab)