Task 6: Build a Team

Building a team is arguably the most consequential thing a project manager does. Strategy, methodology, and tools matter — but none of them matter more than the people executing the work. ECO Task 6, Build a Team, covers the entire lifecycle of team composition: from initial skill appraisal through ongoing development to knowledge transfer when people leave. It is the capstone of the People domain, pulling together threads from leadership, conflict management, empowerment, and training into one integrated competency.

This study guide walks through all four enablers of Task 6: appraising stakeholder skills, deducing resource requirements, continuously assessing and refreshing skills, and maintaining team and knowledge transfer. By the end, you will understand how PMI expects project managers to think about team building as a strategic, continuous process — not a one-time staffing exercise.

ECO Enablers for Task 6

The PMP Exam Content Outline defines four enablers that span the full team lifecycle:

1. Appraise stakeholder skills. Before you can build a team, you must understand what skills exist among available stakeholders — internal employees, contractors, partners, and even sponsors who bring domain expertise. This enabler is about assessment, not assignment.
2. Deduce project resource requirements. From the project scope, schedule, and quality requirements, the PM must derive the specific number, type, and timing of human resources needed. This is quantitative resource planning — moving from "we need a developer" to "we need two senior full-stack developers with React and AWS experience for months 3 through 8."
3. Continuously assess and refresh skills. Team building does not end when the last position is filled. Skills atrophy, technology evolves, and project needs shift. The PM must monitor team capability against project demand throughout the lifecycle and intervene when gaps emerge.
4. Maintain team and knowledge transfer. People leave projects — through reassignment, resignation, or planned phase-out. When they do, their knowledge must stay. This enabler addresses team continuity: managing turnover, onboarding replacements, and ensuring that critical project knowledge is documented and transferred.

These enablers align with the Team performance domain in PMBOK 7, as well as the Planning performance domain (for resource deduction) and the Delivery performance domain (for ongoing skill refreshment). The cross-domain nature of Task 6 underscores how central team building is to the entire project management discipline.

Appraise Stakeholder Skills

The first enabler — appraising stakeholder skills — requires the project manager to think broadly about who can contribute to the project and what they bring. "Stakeholder" here is deliberately broad: it includes not just assigned team members but anyone who might provide skills, knowledge, or effort to the project.

The Skill Appraisal Process

A systematic skill appraisal follows these steps:

1. Identify the stakeholder universe. Using the stakeholder register and engagement plan, list every person or group with a connection to the project. Include functional managers who control resources, subject matter experts in other departments, external partners, and even the sponsor if they bring specific domain knowledge.
2. Catalog skills and competencies. For each stakeholder, document their technical skills, domain expertise, soft skills (communication, leadership, negotiation), certifications, and relevant project experience. Use multiple sources — résumés, past performance reviews, interviews, and direct observation — not just self-reporting.
3. Assess availability and interest. A stakeholder may have the perfect skills but zero availability. Or they may be available but unenthusiastic. The PM must gauge both dimensions: can this person contribute, and will they?
4. Rate proficiency objectively. Use a consistent scale (novice, intermediate, advanced, expert) applied across all skills. Avoid grade inflation — labeling everyone as "expert" hides the real gaps that will surface later.

Skills Matrix Template

A skills matrix is the PM's primary tool for appraising and visualizing stakeholder skills. The matrix maps people against required competencies, creating an at-a-glance view of coverage and gaps:

Team Member / Stakeholder	React	AWS	CI/CD	Security	UX Design	Stakeholder Comm.
Alice (Sr. Developer)	Expert	Advanced	Advanced	—	—	Intermediate
Bob (Developer)	Intermediate	Novice	—	—	—	Novice
Carol (Designer)	—	—	—	—	Expert	Intermediate
Dave (QA)	—	Novice	Intermediate	Advanced	—	—
Sponsor (Eve)	—	—	—	Expert	—	Expert

A quick scan of this matrix reveals immediate concerns: AWS expertise is concentrated in one person (Alice), creating a single point of failure. React skills below Advanced exist only in Bob. Security expertise sits with Dave (QA) and the sponsor — but the sponsor is not a full-time resource. These gaps drive the next enabler: deducing what resources you actually need.

Deduce Project Resource Requirements

With skills appraised, the PM now translates project demands into specific resource requirements. This is where the abstract becomes concrete: headcount, skill levels, timing, and duration.

From WBS to Resource Requirements

The Work Breakdown Structure (WBS) is the bridge between scope and resources. Each work package implies a set of activities, and each activity implies the type and quantity of labor needed to complete it:

1. Decompose scope into activities. Use the WBS and activity list to identify every task the project must complete.
2. Estimate effort per activity. Apply estimation techniques — analogous, parametric, three-point, or bottom-up — to determine the person-hours or person-days required per activity.
3. Map activities to required skills. For each activity, specify the competencies needed. A "Develop API Endpoint" activity might require: Node.js (Advanced), REST design (Intermediate), Unit Testing (Basic).
4. Aggregate into resource requirements. Roll up the activity-level skill demands into a project-level resource plan that specifies: how many people, with which skills, at what proficiency level, during which time periods.
5. Account for non-project time. People do not work 100% on project tasks. Apply realistic utilization rates (typically 75–85% for dedicated team members, lower for shared resources) to avoid under-resourcing.

Resource Requirement vs. Staffing Reality

The gap between deduced requirements and current staffing is the PM's negotiation platform. This gap should be documented and communicated to the sponsor and functional managers with clear consequences: "Based on our resource analysis, we need two senior developers starting Month 2. We currently have one. Without the second developer, the critical path extends by six weeks."

Continuously Assess and Refresh Skills

Building a team is not a milestone to be checked off during planning. It is a continuous activity that persists through execution and monitoring. Skills decay, technology changes, and project challenges reveal capability gaps that were not visible during initial planning.

Triggers for Skill Reassessment

The PM should reassess team skills when any of the following triggers occur:

• Scope changes. A new feature, a regulatory requirement, or a stakeholder request introduces a skill demand the current team cannot meet.
• Performance signals. Defect rates rise, velocity declines, or rework increases — all potential indicators that the team's skills are not keeping pace with the work.
• Technology shifts. A dependency upgrade, a new platform version, or an architectural decision introduces unfamiliar technology.
• Personnel changes. When a key person leaves or a new person joins, the team's collective skill profile changes — and gaps may appear or disappear.
• Retrospective feedback. In agile environments, retrospectives often surface skill-related impediments: "We spent three days debugging the deployment pipeline because nobody on the team understands Terraform."

Refreshment Strategies

When skill gaps are identified mid-project, the PM has several intervention options. The right choice depends on urgency, budget, and the strategic importance of the skill:

Strategy	When to Use	Time to Impact	Cost	Sustainability
Just-in-Time Training	Gap is narrow and well-defined; team member is motivated and has adjacent skills	Days to weeks	Low	High — skill stays on team
Pair Programming / Shadowing	Skill exists elsewhere on the team; knowledge transfer through collaboration is feasible	Immediate start, proficiency in 1–3 sprints	Very low	High — spreads knowledge organically
Bring in a Specialist (Temporary)	Skill is needed immediately for a discrete deliverable; not a long-term team need	Days (procurement permitting)	Moderate-High	Low — skill leaves with the specialist
Hire / Reassign Permanently	Skill is a long-term project need; current team composition is structurally insufficient	Weeks to months	High	High — permanent capability addition
Adjust Scope or Approach	Skill acquisition is not feasible within project constraints; technical approach can be changed	Varies (change control dependent)	Variable	N/A — avoids the skill need entirely

The PMP exam expects you to evaluate these options against the specific scenario presented. The "best" answer is the one that balances urgency, cost, and long-term team health — not the one that is fastest or cheapest in isolation.

Maintain Team and Knowledge Transfer

The final enabler addresses a reality every project manager faces: people leave. Whether through planned phase-out (a contractor whose engagement ends), reassignment (a team member pulled to a higher-priority initiative), or unexpected departure (resignation, illness), the PM must ensure the project does not collapse when individuals exit.

Knowledge Transfer Planning

Knowledge transfer should never be a scramble that begins when someone gives notice. It should be a planned, ongoing practice that starts during team formation:

1. Identify critical knowledge holders. Use the skills matrix to identify single points of knowledge failure — people who are the only ones who understand a system, a process, or a stakeholder relationship. These are your highest-priority transfer targets.
2. Document while doing. Knowledge should be captured as a natural byproduct of work — design documents, code comments, runbooks, decision logs — not as a separate "documentation phase" that nobody has time for.
3. Practice paired work. Pair programming, co-facilitation of meetings, and joint presentations ensure that at least two people understand every critical project function. This is both a quality practice and a risk mitigation strategy.
4. Conduct structured handoffs. When a departure is planned, implement a formal handoff process: the departing team member shadows their replacement (or a colleague absorbing their responsibilities), walks through all active work and pending decisions, and produces a transition document covering what is done, in progress, and known-but-not-started.
5. Maintain a knowledge repository. A centralized, accessible repository — wiki, shared drive, or project management information system — should house key project knowledge. But remember: documentation complements, never replaces, human-to-human transfer.

Team Continuity During Turnover

When a team member leaves unexpectedly, the PM's response follows a clear priority sequence:

1. Assess the impact. What work stops? What knowledge is at risk? Which dependencies are affected? Quantify the gap before reacting.
2. Stabilize the work. Reassign critical-path tasks to remaining team members or pause non-critical work to free capacity. Communicate the impact to affected stakeholders immediately.
3. Source a replacement. Work with functional managers or procurement to bring in a replacement. If the replacement will take weeks, determine whether a temporary contractor can bridge the gap.
4. Recover lost knowledge. Review documentation, conduct exit interviews if possible, and talk to colleagues who worked closely with the departed person. Some knowledge will be lost — the goal is to minimize the gap.
5. Onboard and integrate. When the replacement arrives, invest in structured onboarding. A rushed, sink-or-swim start produces errors, delays, and early turnover — creating the very problem you are trying to solve.

Team Building and Tuckman's Model

Task 6 is broader than just staffing — it encompasses the entire team development journey. Bruce Tuckman's model of team development (Forming, Storming, Norming, Performing, Adjourning) is essential context for understanding how built teams evolve:

• Forming: The team comes together. Skill appraisal and resource deduction happen here. The PM's role is to provide structure, clarify objectives, and facilitate introductions.
• Storming: Conflicts emerge as people assert their working styles. This is where Task 1 (Manage Conflict) skills become critical. The PM must navigate disagreements without letting them derail the team.
• Norming: The team establishes its working rhythm and norms. Task 4 (Empower Team Members) comes into full effect — accountability frameworks and decision authority are cemented.
• Performing: The team operates at high efficiency. The PM's focus shifts to continuous skill refreshing and removing impediments — the third enabler of Task 6.
• Adjourning: The project ends or team members roll off. Knowledge transfer and team maintenance — the fourth enabler — ensure that project knowledge is preserved and team members transition smoothly.

On the PMP exam, situational questions about team building often require you to identify which Tuckman stage the team is in and select the leadership approach appropriate to that stage. A directive approach that fits Forming would be counterproductive in Performing, and vice versa.

Study Checklist for Task 6

• ✅ Can you describe the four-step skill appraisal process and explain why "stakeholder" includes more than just assigned team members?
• ✅ Do you understand how to derive resource requirements from the WBS and activity list?
• ✅ Can you list the five triggers for mid-project skill reassessment?
• ✅ Do you know the five skill refreshment strategies and when each is appropriate?
• ✅ Can you outline a proactive knowledge transfer plan and the five-step response to unexpected team member departure?
• ✅ Are you able to connect Tuckman's five stages to the specific ECO tasks that dominate each stage?
• ✅ Do you know why "accept the team as-is" is rarely the correct PMP exam answer when the team is clearly under-resourced?

Task 6 is the culmination of the People domain: it takes the leadership skills from Task 2, the conflict management skills from Task 1, the empowerment skills from Task 4, and the training skills from Task 5, and weaves them into a comprehensive team-building practice that spans the entire project lifecycle. A project manager who masters Task 6 never blames the team — because they built it, developed it, and maintained it themselves.

← Back to ECO Study Guide Index  |  Practice People Domain Questions →