Team Agreements: Small Document, Large Effect
Most friction inside a project team comes from expectations that nobody has said out loud. One person assumes a message sent at four o'clock will be answered that day; another assumes tomorrow morning is fine. One person believes decisions are made in the Tuesday meeting; another believes they are made by whoever is closest to the work. Neither is wrong, both are reasonable, and the difference will produce an irritated exchange somewhere around week five.
A team agreement is a page that makes those expectations explicit, written by the people who will follow it. Section 3.8 of The Standard for Project Management describes building an empowered culture, and this is one of the few concrete artefacts that does it: a team that has written its own operating rules is a team that can enforce them without anybody having to pull rank.
What belongs in one
How decisions get made. Which decisions the team takes together, which belong to individuals, and what happens when a decision needs somebody who is not available. This single item removes more delay than the rest of the page combined.
How disagreement is handled. Where a technical disagreement goes when two people cannot settle it, how long it is allowed to run, and who arbitrates. Agreed in advance this is procedural; agreed during a disagreement it is political.
Availability and response expectations. Core hours, what counts as urgent, how quickly a message should be answered, how to reach somebody when it genuinely cannot wait. On a team spread across organisations or time zones, this is the item that prevents the largest number of small resentments.
How the team's meetings work. Who attends what, what happens when somebody cannot be there, whether cameras are on, whether it is acceptable to decline. Meetings absorb more of a team's week than any other activity and are usually governed entirely by assumption.
Why the small ones work
They describe behaviours, not values. We respect each other is unenforceable, because nobody can tell when it has been broken. A message sent before three o'clock gets an answer the same day is a behaviour: it can be observed, it can be raised without accusation, and it can be changed when it stops fitting.
They belong to the team. An agreement written by a project manager and circulated is a set of rules, and rules get followed at the level compliance requires. The same content, produced by the team in forty minutes, gets defended by them, including against the project manager, which is the point.
Two organisations and one working day
A hospital trust was implementing a new clinical results system with a supplier's implementation team. Eleven people in total, six from the trust and five from the supplier, working together for about nine months.
The friction started early and looked like attitude. The supplier's team found the trust's people slow to respond; the trust's people found the supplier's constant chasing disrespectful. Both descriptions were sincere and neither was about the other's character.
The supplier's team worked in a delivery culture where a message during the working day expected an answer within two or three hours, because that was how their other implementations ran. The trust's clinical systems staff spent most of every day on wards and in clinics, answered messages in a block at the end of the day, and regarded a same-day answer as good service. Nobody had ever stated either expectation.
The agreement took forty minutes in a clinical office and ran to eleven lines on a single sheet taped beside the door. Two of them settled the problem: anything sent before three o'clock is answered the same working day, anything genuinely urgent goes by phone and not by message, and the definition of urgent was written out in a sentence. Two more lines were added by hand in the following fortnight, in different pens, as the team found things it had missed.
The chasing stopped within a week. Nobody had changed how they worked; they had simply stopped interpreting each other's normal behaviour as a judgement. The sheet stayed up for the whole implementation, beside a shelf of ring-bound policy folders that ran to several hundred pages and settled none of this.
Writing and keeping one
Keep it to a page. Anything longer stops being a shared understanding and becomes a document, which is to say something nobody reads after the day it was written. Ten or twelve lines is a healthy length.
Write it early and revisit it at a trigger. The best moment is the first fortnight, before anybody has been annoyed. After that, revisit it whenever the team changes shape, a new organisation joins, or the same friction appears twice, which is the signal that something is missing from it.
Let the team hold the pen. A project manager's role is to convene the conversation, ask the questions the team has not thought of, and accept the answers, including the ones that constrain them. An agreement that the project manager has edited afterwards is no longer the team's.
For a PMP® candidate, the thing to carry is that explicit working agreements are how an empowered team governs itself, so a scenario about recurring friction between groups is asking what was never made explicit. A response that arbitrates the latest incident leaves the mechanism producing them in place. Situations where two reasonable expectations are colliding unspoken are worth rehearsing in a structured PMP exam preparation course.
Where no agreement exists, forty minutes at the next team meeting will produce one. Ask three questions: how do we make decisions, what do we expect of each other on response times, and what happens when two of us disagree. Write the answers as sentences somebody could be held to, and put the page somewhere people walk past.
Interested in going further?
Most team friction is two reasonable expectations meeting without either being stated, and a page fixes more of it than a process ever will. Omega's PMP® Exam Preparation works through team situations where the fix is agreement rather than authority.
Building an empowered culture is one of the principles in The Standard, published with the PMBOK® Guide Eighth Edition.
Ad · Amazon affiliate link.
References
A042: Why Telling the Team What to Do Is Often the Wrong PMP Answer
A041: Empowered Teams Still Need Leadership
A198: When Collaboration Is Better Than Authority in PMP Scenarios
A030: The Project Team Is Not the Project Manager’s Staff
A007: The Standard for Project Management vs the PMBOK Guide
PMP and PMBOK are registered marks of the Project Management Institute, Inc.
