A group project working agreement records how members will coordinate: how they communicate, make decisions, prepare work, handle missed commitments, and revise their approach. It complements the task plan. A task list says what needs doing; the agreement says how people will work together when the plan meets reality.
This is useful for student projects, temporary workplace groups, and volunteer teams. It is an operating agreement, not a substitute for course requirements, employment policy, accessibility arrangements, or a formal contract.
The University of Waterloo's guidance on group contracts recommends making expectations, roles, and a process for addressing problems explicit. The template below is our practical adaptation for a group that wants a short, revisable agreement.
Start with constraints before writing rules
Ask each member to describe their real availability and relevant constraints. Do not assume everyone can meet in the evening, respond immediately, use the same paid tool, or disclose personal circumstances to the whole group.
For a student project, read the assignment and assessment rules first. Who is allowed to collaborate? Which sources and tools are permitted? Is individual contribution assessed separately? The group cannot authorize behavior that the course prohibits.
For a workplace project, clarify decision rights and dependencies. A temporary group may be able to decide its meeting format without having authority to change a delivery commitment or share confidential material in a new tool.
Then identify the few situations most likely to cause friction. An agreement built around actual risks is more useful than a page of agreeable values such as “communicate well” and “respect everyone.”
A working agreement you can adapt
The wording below is illustrative. Replace the timing and roles with arrangements the actual group can meet.
| Area | Example agreement | Repair or review rule |
|---|---|---|
| Communication | Use the agreed group channel for decisions and blockers; acknowledge action requests within one working day | If urgent, use the agreed escalation route rather than assuming silence means agreement |
| Availability | Record working windows and planned absences before assigning shared deadlines | Reallocate work with the affected member when availability changes |
| Work readiness | Share drafts in the common workspace with sources and open questions identified | A reviewer states missing requirements before rewriting another person's work |
| Decisions | Discuss consequential choices, record the reason, and name the decision owner | Escalate unresolved choices before they block the next task |
| Commitments | Each task has an owner and an internal handoff date | Warn the group early if the date is at risk; agree a revised plan explicitly |
| Feedback | Describe an observed behavior and its effect, then ask for the other person's view | Use a short private conversation where appropriate; seek facilitator help if unresolved |
| Review | Check the agreement after the first shared deliverable | Keep, change, or remove rules based on actual experience |
Do not add a response-time rule that quietly demands constant availability. Define what “working day” means for this group and which messages actually require a response.
Build it in a 30-minute conversation
Minutes 0–5: each person writes one helpful practice and one difficulty from previous group work. Share the behaviors, not personal accusations about former teammates.
Minutes 5–15: select the situations that matter for this project. Turn preferences into observable agreements. “Be reliable” becomes “raise a threatened handoff before the internal deadline, with the remaining work visible.”
Minutes 15–25: test two scenarios. Someone misses a draft handoff. Two members disagree about the quality of evidence. Ask what the agreement would help them do next and whether the response is fair.
Minutes 25–30: confirm consent, record unresolved issues, and set the first review date. Avoid treating silence as agreement. Invite concerns without making people explain private constraints in front of the group.
These timings are a suggested facilitation format, not a university requirement. A newly formed group may need more time, especially when members have different expectations about language, hierarchy, or decision making.
Worked example: uneven participation without an accusation
A hypothetical four-person student team is preparing a research presentation. Two members usually work late in the evening. A third has daytime availability, and the fourth is waiting for a source review before writing their section.
The group initially interprets the different update patterns as unequal effort. Its agreement workshop reveals that draft handoffs have no defined location or time. Work exists in private documents, and nobody knows which source decisions are final.
The group agrees to keep drafts in the course-approved shared workspace, mark unresolved claims, and set an internal handoff two days before the presentation rehearsal. Each section has an owner and a reviewer. The two-day interval is an invented example, not a universal recommendation.
When one section is at risk, its owner identifies the missing source decision before the handoff. The group can now resolve the dependency or redistribute a specific task. It does not need to settle whether the person “cares enough.”
If a contribution concern remains, the group follows the course's process for reporting and resolving it. The agreement does not invent penalties or override assessment rules.
Handle missed agreements with a repair process
Begin with the observation: “The draft was not in the workspace at the agreed handoff.” Explain the effect: “The reviewer could not prepare before the rehearsal.” Then ask what happened and what change is feasible.
Distinguish a one-off event from a recurring mismatch. A rule may be unrealistic, an external dependency may be unresolved, or someone may need support. Understanding the cause does not erase the impact, but it helps the group choose a useful response.
Agree the next commitment explicitly. Who will do what, when, and what happens if the revised plan also fails? Where appropriate, use the instructor, manager, or facilitator's established support route rather than escalating through public criticism.
Do not turn the agreement into a disciplinary document maintained by the loudest person. Everyone should be able to question a rule and identify when it creates an unfair burden.
Review the agreement while change is still useful
After the first shared deliverable, spend fifteen minutes on three questions: which agreement helped, which was difficult to follow, and which missing agreement caused avoidable friction? Preserve what works instead of rewriting the whole document.
A Start Stop Continue retrospective can structure that conversation. For groups outside software, the team retrospective guide explains how to focus on the way work happens.
Record only the changes the group accepts and make them visible. A short agreement that people can recall and revise is easier to use than a perfect-looking document nobody consults after the first meeting.
Frequently asked questions
Is a working agreement the same as a task allocation?
No. Task allocation identifies the work and its owners. A working agreement defines coordination behaviors such as handoffs, communication, decision making, and responses when expectations are missed. The two should support each other.
Should every member sign the agreement?
Use the confirmation method appropriate to the setting. A course may require signatures; a workplace group may record explicit agreement in its shared document. The essential point is that members understand and accept the behaviors rather than being assigned unexplained rules.
What if someone repeatedly ignores the agreement?
Describe specific observations, discuss the impact and possible causes, and use the group's agreed repair process. If the problem remains, follow the instructor's or organization's established escalation route. Do not invent sanctions that conflict with those rules.
