PMI PMP: Team Leadership & Resource Management — Study Guide

Part of the PMP — Study Guide. Practice with verified answers in the PMI exam hub, or take timed practice tests on ExamRoll.io.

Team Formation, Charter, and Role Clarity

Every high-performing team begins with a deliberate formation ritual, not with the first status meeting. The team charter is the founding artifact — a co-created document that captures the team’s shared values, decision-making rules, working hours across time zones, communication cadence, and escalation paths. Unlike the project charter (which authorizes the project and names the sponsor), the team charter is authored by the team, for the team. Its power lies in that co-authorship: when a developer later interrupts a peer or misses a stand-up, the project manager doesn’t invoke personal authority — they point to a norm the team itself established.

Alongside the charter, ground rules operationalize daily discipline: cameras on for design reviews, no multitasking during retrospectives, a two-minute rule for verbal updates, decisions documented within 24 hours. Ground rules should be visible (posted in the team room or pinned in the collaboration channel) and revisited at the start of each iteration or phase gate. A charter that lives in a SharePoint folder no one opens is decorative; a charter referenced weekly is regulatory.

Role clarity closes the formation triangle. A RACI (or its variant RASCI) matrix mapping deliverables to responsible, accountable, consulted, and informed parties eliminates the “I thought you had it” failure mode. On a new team where a project manager inherits a group that has drifted for weeks without leadership, the correct first move is neither aggressive replanning nor immediate schedule renegotiation with the sponsor. It is convening the team, listening to what they perceive as blocked, and rebuilding the charter and role map. The team feels lost precisely because these anchors are missing.

Adapting Leadership Style to Maturity

Situational leadership treats leadership style as a variable, not a personality. The classic Hersey-Blanchard progression maps style to follower readiness:

A servant leadership posture — removing impediments, shielding the team from noise, prioritizing their growth — overlays this model but does not replace situational judgment. Servant leadership does not mean permissive leadership. When a team drifts, the servant leader still directs; they simply do so in service of the team’s success rather than their own visibility.

The trap of laissez-faire leadership on a directionless team is a common failure. Standing back “to let the team self-organize” when the team has no shared model of the work produces confusion, missed dependencies, and demoralization. Self-organization is an outcome of maturity, not a starting condition. Conversely, micromanaging senior engineers who have delivered similar work five times signals distrust, suppresses initiative, and drives attrition. The tell is when the project manager reviews commit-level detail on a domain expert’s work while ignoring risk conversations at the portfolio level.

When joining a mixed-seniority team, the entry move is a round of one-on-ones combined with a working-agreement workshop. This surfaces where each individual sits on the readiness spectrum, allowing style to be tuned per person rather than broadcast uniformly.

Coaching, One-on-Ones, and Performance Management

Recurring one-on-ones — typically 30 minutes biweekly — are the primary channel for coaching, early problem detection, and career development. They are not status meetings. Agendas should be owned by the team member, with the project manager listening 70% of the time. Topics rotate across current blockers, skill growth, feedback in both directions, and morale.

Performance issues must be raised at first observation, not stored up for a formal review cycle. Delaying difficult conversations is one of the most damaging patterns in project leadership: the underperformer learns nothing until it is too late to correct, high performers watch and disengage, and morale erodes silently. Feedback should reference measurable indicators — defect escape rate, story cycle time, code review turnaround, meeting attendance, commitment reliability — rather than subjective impressions (“you seem disengaged”). Measurable indicators anchor the conversation in observable behavior and give the team member a concrete target.

Escalation to functional managers, or ultimately requesting resource replacement, is warranted only after coaching, clear expectation-setting, and a documented performance improvement discussion have failed. Skipping those steps damages trust and often violates HR policy.

Conflict Resolution and Team-Building

Interpersonal conflict, if unaddressed, metastasizes. When a team member is being isolated by peers on a short-duration project, the project manager’s response is neither to wait it out (the project ends before the dynamic resolves) nor to publicly confront the group (which humiliates and hardens positions). The correct pattern combines three moves: hold a private conversation with the affected individual to understand their experience, speak individually with the peers exhibiting exclusionary behavior to name the observed pattern and its impact, and reinforce inclusion norms through the team charter and a facilitated team-building activity. Documentation of the intervention is essential in case escalation to HR becomes necessary.

Thomas-Kilmann’s five conflict modes — collaborating, compromising, smoothing, forcing, withdrawing — guide selection. Collaborating (problem-solving to find a win-win) is generally preferred for interpersonal and technical disputes on a persistent team, while forcing may be justified only for safety, ethical, or hard-deadline decisions.

Resource Allocation, Leveling, and Capacity Planning

Resource management is negotiation as much as arithmetic. Resource leveling flattens over-allocation by extending the schedule; resource smoothing keeps the end date fixed and works within float. Choose leveling when a critical specialist is over-committed and quality would suffer; choose smoothing when the end date is contractual.

When a functional manager reassigns a shared architect mid-sprint, the project manager negotiates using data: current commitments, impact on the critical path, and downstream cost of delay. Escalation to the sponsor or steering committee is appropriate only after direct negotiation has been attempted and documented. Bringing raw complaints upward without first attempting resolution burns political capital.

Knowledge Transfer and Cross-Training

Single-point dependencies are among the most predictable project risks and the most frequently ignored. When one person is the sole owner of a subsystem and is hospitalized for two months, the failure is not the accident — it is the absence of prior mitigation. Preventive practices include pair programming or pair mentoring, rotating on-call responsibilities, mandatory documentation of tribal knowledge into runbooks, recorded knowledge-transfer sessions, and cross-training rotations where a secondary owner shadows and then performs the specialist’s tasks. Onboarding plans for new hires should explicitly assign a buddy and a 30-60-90-day competency map.

Succession planning at the team level identifies who could step into each critical role and what gap closure they need. This is captured in a skills matrix reviewed quarterly.

Meeting Facilitation and Recognition

Meetings consume the most visible slice of team capacity. Discipline requires a stated purpose, a timeboxed agenda distributed in advance, the right (not maximal) attendees, explicit decisions and action items captured with owners and dates, and a working parking lot for off-topic threads. Standing meetings without decisions should be canceled.

Finally, recognition — timely, specific, and public for team wins; private for individual coaching — is not a soft nicety. Rewards aligned to charter values reinforce the behaviors that produced them. A quick shout-out in a review, a spot bonus coordinated with the functional manager, or a written note to someone’s line manager costs little and compounds significantly in morale and retention.

Practical Problem: Use-Case Scenario

Scenario: Priya Kapoor has just been assigned to lead the “Meridian” payments modernization project at a mid-size regional bank, with a $4.2M budget and a 14-month timeline. The team of 11 spans three time zones: five developers in Bangalore, three business analysts in London, and a QA lead, architect, and Priya herself in Toronto. Two weeks into the project, the Bangalore developers built a prototype that the London BAs rejected as misaligned with the compliance requirements they had “assumed everyone had read,” and the architect in Toronto claims he was never consulted on the technology stack decision.

Challenge: Priya must reset the team’s operating norms and role clarity before the project slips further, without appearing to blame any single group for the miscommunication.

Recommended Approach:

  1. Pause active development for a two-day virtual team formation workshop, scheduling overlapping hours (7:00–10:00 AM Toronto / 12:00–3:00 PM London / 4:30–7:30 PM Bangalore) so all 11 members can co-author the artifacts live.
  2. Facilitate co-creation of a team charter covering shared working-hour overlap, decision rights, definition of “consulted” vs. “informed,” a 24-hour turnaround rule for asynchronous decisions, and an escalation ladder ending with the sponsor.
  3. Build a RASCI matrix against the 18 major deliverables in the WBS, walking through each row with the team so that “Accountable” is always a single named person and “Consulted” explicitly names the architect for any technical stack decisions.
  4. Establish ground rules — cameras on for design reviews, decisions logged in Confluence within one business day, a weekly 30-minute cross-zone sync at the overlap window — and pin them in the team’s Slack channel.
  5. Rework the prototype scope with the BAs and developers together, using the newly clarified RASCI to identify who signs off before code is written.
  6. Add a standing 10-minute “charter check” to the first retrospective of each iteration to revise norms as the team matures.

Why This Works: Co-authorship converts the charter from a mandate into a peer commitment, which is what gives the PM standing to enforce norms without invoking positional authority. The RASCI eliminates the “I thought you had it” gap that produced the compliance miss, and revisiting norms per iteration prevents the charter from becoming a decorative artifact rather than a living agreement.


Stakeholder Engagement · All domains · Agile

Practice these questions → · Timed practice on ExamRoll.io →

Pass the whole exam — not just this question

You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.

Pass your exam →

Related guides

All-in-one access

One subscription. Every exam.

Every plan unlocks unlimited answer search, practice tests, AI explanations, and the full resource library — in 20+ languages.

Monthly
24.87
Just €0.83/day
Everything included:
  • Unlimited answer search
  • Unlimited practice tests
  • AI-powered explanations
  • Full resource library
  • 20+ languages
  • Weekly content updates
  • Rewards & referrals
  • Priority support
Start free trial

No credit card required*

Best value
12 months
179.87
Just €0.49/daySave 40%
Everything included:
  • Unlimited answer search
  • Unlimited practice tests
  • AI-powered explanations
  • Full resource library
  • 20+ languages
  • Weekly content updates
  • Rewards & referrals
  • Priority support
Start free trial

No credit card required*

✓ Free plan included · ✓ Cancel anytime · ✓ All plans unlock the full product