Building the team: acquisition, onboarding and skills

A project team does not appear fully formed on the day the charter is signed. Someone has to work out what skills the work needs, find people who have them, negotiate for their time, bring them up to speed and fill the gaps that remain. Get this wrong and the best plan in the world will stall for want of the right people at the right time. This lesson covers how project managers plan resources, acquire team members, analyze skills, build diverse and inclusive teams, and onboard people so they can contribute quickly.

Planning the team you need

Team planning starts from the work. In a predictive project, the work breakdown structure and activity list show what must be done, and the schedule shows when. In an adaptive project, the product backlog and roadmap show the kinds of work coming, and the team is usually a stable, cross-functional group sized to deliver a steady flow of value. In both cases, the project manager asks four questions: what roles and skills are needed, how many people of each kind, when, and where they will come from.

The results are usually recorded in a resource management plan (or the team section of a lighter project plan). Typical contents include roles and responsibilities, the project organization chart, how team members will be acquired and released, training needs, recognition plans, compliance requirements such as safety training or security clearances, and the approach to managing physical resources. A RACI or other responsibility assignment matrix links roles to deliverables (PMP-110, lesson 10 introduced RACI; lesson 4 of this course uses it to clarify decision rights).

Resource histograms and leveling

A resource histogram is a bar chart showing how much of a resource the schedule requires in each period. It quickly reveals peaks, where demand exceeds availability, and valleys, where people are under-used. Leveling and smoothing are the two techniques for dealing with the peaks.

The difference between the two techniques is a favorite exam point. Resource leveling adjusts start and finish dates to balance demand with supply, and it can change the critical path and extend the project. Resource smoothing adjusts activities only within their free and total float, so the critical path and end date do not change, but it may not remove every peak. Scheduling details belong to PMP-130; here the point is that the people side of a project depends on these choices. Repeatedly overloading the same people is one of the fastest ways to burn out a team.

Acquiring team members

In most organizations, project managers do not simply choose their teams. They negotiate. The PMBOK tradition calls this "acquire resources", and it can involve several routes.

Negotiation is where many project managers win or lose their projects. A functional manager has their own goals and limited people; you are asking them to give up some of their best staff. Good practice includes preparing a clear business case for each request, knowing exactly when and how much of each person you need, offering something in return (development opportunities for their staff, flexibility on timing, visibility to senior management), and documenting agreements so that availability is not quietly withdrawn later. If negotiation fails on a genuinely critical resource, the sponsor may need to help resolve the conflict; that is the purpose of governance, not a sign of failure.

Skills matrices and gap analysis

A skills matrix (also called a competency matrix) lists the skills a project needs down one side and team members across the top, with a rating for each person in each skill. It answers three questions: do we collectively have the skills we need, where are we dependent on a single person, and who could be developed to fill gaps? The ratings can be simple, such as 0 (none), 1 (aware), 2 (can do with help), 3 (can do independently), 4 (can teach others).

Skills matrices also support T-shaped development, a common goal on agile teams. A T-shaped person has deep expertise in one area (the vertical bar of the T) and working knowledge in several others (the horizontal bar). Teams of T-shaped people can swarm on bottlenecks, cover for absences and avoid hand-off delays. The matrix shows where broadening would help most.

Diversity, equity and inclusion on project teams

Diverse teams bring different experiences, perspectives and ways of solving problems. Research on decision making suggests that diverse groups, when well led, consider more information and make fewer errors caused by shared blind spots, although diversity without inclusion can increase conflict and reduce cohesion. The ECO asks project managers to "support the team's varied experiences, skills, and perspectives", which is a concise description of inclusion.

Diversity is about who is on the team: differences in background, culture, gender, age, disability, education, discipline and thinking style. Inclusion is about how the team works: whether everyone can contribute, is heard and is treated fairly. A project manager has more control over inclusion than over diversity, but can influence both:

• In acquisition: use clear, job-related selection criteria; avoid relying only on people you already know; ask for diverse candidate pools from functional managers and vendors.
• In meetings: use techniques that give everyone a voice, such as round-robins, silent brainstorming, anonymous input and rotating facilitation.
• In logistics: schedule meetings fairly across time zones, provide accessible documents and tools, and accommodate religious observances and caregiving responsibilities.
• In assignments: rotate high-visibility work so development opportunities are shared.
• In behavior: address disrespectful comments promptly and privately, and model curiosity about different perspectives.

Legal obligations reinforce these practices. Title VII of the Civil Rights Act, the Age Discrimination in Employment Act and the Americans with Disabilities Act prohibit employment discrimination, and the ADA requires reasonable accommodation for qualified people with disabilities unless it causes undue hardship. Many states add protections. Federal policy on diversity programs has changed in 2025 and 2026, so organizations should follow current guidance from counsel and human resources; anti-discrimination and accommodation duties remain in force.

A practical caution: inclusion is not about treating everyone identically. Fairness sometimes means adjusting how people participate, for example giving a colleague who works in a second language the agenda in advance, or captioning video calls for a colleague who is hard of hearing. The aim is equal opportunity to contribute.

Onboarding new team members

Onboarding is the process of helping a new team member become productive and connected. On projects, poor onboarding is expensive: a new developer who spends two weeks waiting for access and searching for documents is two weeks of lost capacity, and someone who never feels part of the team may leave. Good onboarding covers four areas, sometimes called the four C's: compliance (policies, safety, security, confidentiality), clarification (role, expectations, how work is done), culture (team norms and values) and connection (relationships with colleagues).

Onboarding also matters when people join part-way through. A new member changes the team's dynamics and can send it back to an earlier stage of development (lesson 5). Brief the existing team, revisit the team charter together and give the newcomer a meaningful early task so they can contribute and be seen to contribute.

Releasing people is the other end of acquisition. Plan releases as carefully as arrivals: transfer knowledge before people leave, recognize their contribution, give feedback to their functional managers and update the resource plan. A project that hoards people after their work is done damages its relationships with the functional managers it will need next time.