Perspectives · Knowledge & Practice

What Has to Be Present on a Project Team. Accountabilities Before Roles.

Most discussions of project team composition start with roles or skills. Both are the wrong starting point. Roles are titles, and titles vary by organization. Skills are capacities, and capacities are only meaningful once you know what the team is accountable for delivering. The durable question is accountabilities: which decisions must be made, who answers for them, and what happens when the answer is wrong. Roles and skills follow from that. Reversed, they tend to produce teams that look complete on an org chart and fail under pressure.

The confusion is common enough to be structural. A team is assembled by pulling named roles from a template: sponsor, project manager, business analyst, technical lead, team members. The template is populated, the kickoff runs, and the governance gap only surfaces when a decision has to be escalated and no one is clear who owns it. At that point the project has a role chart but not a decision structure.

The PMI Process Groups Practice Guide and the GPM P5 Standard both treat this the same way, though neither states it as plainly as it deserves. They describe accountabilities that must exist somewhere on or around the project. They do not require that each accountability sit with a distinct person. A small project may collapse several accountabilities into one individual without harm, provided the individual understands which hat they are wearing when. A large project usually cannot.

The accountabilities that consistently appear across standards are these. Someone must own the business case and the authority to continue or stop the project. Someone must own day-to-day delivery decisions within the approved scope. Someone must own the technical integrity of what is produced. Someone must own the relationship with the people affected by the outcome. Someone must own the measurement of whether the project is doing what it said it would do. On AI-involved projects, someone must own data quality, model evaluation, and ethical assessment, per frameworks like CPMAI.

The team does not decide whether to consider environmental, social, and economic impacts; the organization has already decided, and the project is accountable for acting on that decision. This cuts in two directions. The organization must state the commitment in terms a project can act on, which means policies, standards, and decision rights that survive contact with delivery pressure. The team must assign the accountability to a named person who owns the assessment of impacts across the lifecycle, including the authority to raise issues that affect scope, schedule, or cost. An accountability without that authority is decorative.

In practice this is where most projects fail the test. Sustainability is named in the charter, referenced in the kickoff, and then quietly deprioritized when a delivery decision conflicts with it. The failure is not a failure of intent. It is a failure of accountability assignment. No one was given the authority to stop or reshape a decision on sustainability grounds, so the decision gets made on other grounds and sustainability becomes reporting language rather than governance.

These are accountabilities, not roles. The sponsor role typically holds the first. The project manager role typically holds the second. The rest vary. What matters is that each one is held by a named person who knows they hold it, and that the decision rights and escalation paths are explicit. When a team cannot answer "who decides X" within two sentences, the accountability is not assigned; it is assumed. Assumed accountabilities fail quietly until they fail loudly.

Katzenbach and Smith argued that every team needs three skill categories present in some combination: technical or functional expertise, problem-solving and decision-making capacity, and interpersonal skill.¹ Their position on skills is weaker than it is sometimes reported. They treat skill completeness as less determinative than mutual accountability and common purpose, and note that teams often acquire missing skills in the course of the work. PMI's Talent Triangle adds business acumen as a fourth category, reflecting the concern that teams without it tend to deliver outputs disconnected from the decisions the sponsor needs to make.

The reason skills come after accountabilities is that the required skill mix is a function of what the team is accountable for. A team accountable for regulatory compliance needs deep domain expertise and weaker creative problem-solving. A team accountable for exploring a new market needs the inverse. A team accountable for sustainability outcomes needs the competence areas described in the GPM Sustainability Competence Standard, which overlap with but do not duplicate standard project management skill sets. Listing skills without first defining accountabilities produces generic lists that look complete and do not guide hiring or assignment.

Edmondson's work on psychological safety adds a constraint that matters here. Skill inventories on paper frequently overstate what a team can access in practice. A team member with expertise who does not feel able to surface disagreement functions, from the project's perspective, as if the expertise were not present. This is not a soft concern. It is a measurement problem. A team's accessible skill is lower than its listed skill, and the gap is determined by conditions the project manager controls more than by the skills themselves.

Structuring a team around accountabilities has costs. It takes longer to set up. It requires conversations that many organizations avoid, particularly about who has authority to stop work and who answers when a decision goes wrong. It exposes gaps in sponsorship that a role-chart approach hides. It often reveals that the nominal sponsor does not actually hold the authority the project assumes they hold. On the sustainability accountability specifically, it tends to reveal that the organization's public commitment is not backed by decision rights anyone can exercise.

The alternative has its own costs. Role-based team design is faster and matches how most organizations staff projects. It works adequately for routine work where the accountabilities are understood by convention. It degrades as projects become less routine, as stakeholder complexity increases, and as the consequences of unclear decision rights grow. Most practitioners have seen the failure mode: a project that ran for months before anyone noticed that a core decision had no owner.

There is also a measurement tradeoff. Accountability-based team structures are harder to audit from the outside. A role chart can be reviewed at a glance. A map of accountabilities, decision rights, and escalation paths requires reading. Organizations that value visible governance over functioning governance tend to default to role charts for this reason.

The integrity risk in team composition is not usually visible at setup. It shows up later, as decisions made by people who did not have the authority to make them, or as decisions deferred because no one was sure who owned them. By the time this surfaces, the cost of re-assigning accountabilities mid-project is higher than the cost of assigning them clearly at the start. The team adapts by routing decisions informally, which works until it does not, and which leaves no audit trail when it fails.

Sustainability is the accountability where this risk compounds fastest. An organization that states a sustainability commitment and then assembles project teams without assigning the accountability to anyone with authority produces a predictable outcome: the commitment appears in reporting and does not appear in decisions. The gap between the stated position and the delivered work becomes auditable from the outside. This is a governance failure before it is a sustainability failure.

For practitioners, the implication is narrower than it first appears. When assembling a team, resist the instinct to start with the role template. Start with the list of decisions the project will require and the accountabilities those decisions imply, including the sustainability accountabilities the organization has already committed to. Assign each accountability to a named person with the authority to act on it. Then identify the skill categories required to discharge those accountabilities, and check whether the assigned people carry them. Roles, in this sequence, become a secondary question: what title to give each person for purposes of the organization's conventions. Most of the time, the conventional titles still fit. Occasionally they do not, and the mismatch is information worth acting on.

This does not resolve the composition problem. It relocates it to where it can be worked on.

¹ Katzenbach, J. R. and Smith, D. K. (1993). The Wisdom of Teams: Creating the High-Performance Organization. Harvard Business School Press. Reissued 2015 by Harvard Business Review Press. Condensed in "The Discipline of Teams," Harvard Business Review, March–April 1993. https://hbr.org/1993/03/the-discipline-of-teams