Team charters, ground rules and empowerment

Most conflicts on project teams are not really about people disliking each other. They come from unspoken assumptions: one person thinks a reply within a day is fine, another expects an hour; one thinks decisions are made in meetings, another thinks the lead decides; one thinks cameras on is respectful, another thinks it is intrusive. A team charter makes these assumptions visible and agreed before they cause friction. This lesson explains how to create a team charter, how to set and enforce ground rules, and how to empower a team by making decision rights and delegation explicit.

What a team charter is

A team charter (also called a team agreement or working agreement) is a document created by the team that sets out its shared values, agreements and practices. It is different from the project charter. The project charter is issued by the sponsor, authorizes the project and gives the project manager authority to use resources. The team charter is written by the team, for the team, and describes how the members will work together.

PMI material lists typical contents of a team charter: team values, communication guidelines, decision-making criteria and process, a conflict resolution process, meeting guidelines and other team agreements, such as core working hours and how to handle absences. Agile teams often add a definition of ready and a definition of done, and working agreements about how work flows on their board.

Creating a team charter

The single most important rule is that the team writes it. A project manager who drafts a team charter alone and asks for signatures produces a document nobody owns. The project manager's job is to facilitate: create the space, ask the right questions, capture the agreements and help the team reach consensus.

A good charter is specific enough to settle real disagreements. "We communicate respectfully" is a value; "We reply to direct chat messages within four working hours, and anything urgent is a phone call" is an agreement. Both have their place, but only the agreement tells someone what to do on a busy Tuesday.

Ground rules and how to enforce them

Ground rules are the specific behavioral expectations in a team charter. The ECO's "Manage conflicts" task includes two enablers about them: establishing an environment that fosters adherence to common ground rules, and managing and rectifying ground rule violations. Writing ground rules is easy; living by them is harder.

Several practices help ground rules stick. First, the team owns them: because the team wrote the rules, team members can remind each other, and enforcement does not depend on the project manager alone. Second, they are visible: displayed on the team board, at the top of the team channel or on the first slide of regular meetings. Third, they are reviewed: retrospectives and periodic checks ask whether the rules still serve the team. Fourth, violations are addressed early and proportionately.

There is an important distinction between ground rules and organizational policy. Ground rules are team agreements. Behavior that breaks law or policy, such as harassment, discrimination, safety violations or fraud, is not a ground rule violation to be handled informally; it must be dealt with according to organizational policy and usually involves human resources or other functions. A project manager who treats harassment as a "team norms" issue fails both the person harmed and the organization.

Empowerment and decision rights

Empowerment means giving people the authority, information, resources and support to make decisions and take action within their area of responsibility. The ECO lists "empower the team" as an enabler of leading the team, and PMBOK guidance stresses empowered, self-organizing teams. Empowerment improves speed, because decisions are made close to the work, and motivation, because autonomy is a powerful driver (lesson 6). But empowerment without clarity produces confusion: people do not know which decisions are theirs, decisions get made twice or not at all, and the leader ends up reversing choices, which destroys trust.

The solution is to make decision rights explicit. A decision right specifies who decides, who must be consulted and who must be informed for a particular class of decision. Several tools help.

• RACI and RAPID: A RACI matrix (responsible, accountable, consulted, informed) can be applied to decisions as well as tasks; the accountable person is the decision owner. Bain's RAPID framework names roles specifically for decisions: recommend, agree, perform, input and decide.
• Decision-making methods: unanimity, consensus (everyone can support it even if it is not their first choice), majority, plurality, and autocratic (one person decides). The charter should say which method applies to which kinds of decisions.
• Delegation levels: frameworks such as Jurgen Appelo's seven levels of delegation make explicit how much authority is being handed over.

In delegation poker, the leader and team each privately choose a level for a decision area, such as choosing development tools, approving annual leave or selecting a vendor, and then reveal their cards. Differences prompt discussion, and the agreed levels are recorded in a delegation board. The exercise turns vague notions of empowerment into explicit agreements and usually reveals that people have very different assumptions.

Boundaries make empowerment work

Empowerment always operates within boundaries: the project's objectives and constraints, organizational policies, the law, budget limits and quality standards. Clear boundaries do not limit empowerment; they make it safe. A team told "do whatever you think best" may hesitate, fearing that its choices will be overturned. A team told "choose any tools that meet the security standard and cost less than five hundred dollars a month per environment" can decide confidently.

Agile teams express boundaries through constructs such as the definition of done, architectural guidelines, the product goal and sprint goal, and escalation thresholds. Predictive projects use tolerances: for example, the team lead may approve schedule changes up to three days within a work package, the project manager up to two weeks, and anything larger goes to the change control board. Either way, the principle is the same: decide as close to the work as is safe, and escalate only what exceeds the agreed limits.

In US public-sector projects, delegation is also constrained by formal authorities. Federal contracting officers hold warrants that set the limits of what they can commit, and only authorized officials can obligate funds under appropriations law. State and local governments have similar delegation rules.

Revisiting the charter

A team charter is a living document. Revisit it when new members join, when the team moves into a new phase, after significant conflict, or simply on a regular schedule such as every third retrospective. Ask three questions: which agreements are working, which are being ignored and why, and what new situations need an agreement? A charter that has not been touched in six months has probably stopped guiding behavior.