Collaboration Setup
Define who is responsible for what in the project
Roles do not need to be complicated. What matters is that key tasks, decisions and handovers have a responsible person or function.
These things should not be treated as equivalent in collaborative projects
A specialist or organisational role should not be defined only by one person holding a technical login.
Being able to open a file does not automatically make someone responsible for its quality, approval, backup or long-term retention.
Collaboration also needs rules for naming, versions, approvals, communication and responsibility.
If critical resources depend on personal logins, handover, continuity and institutional responsibility can become difficult.
External partners need only the access and information required for their tasks.
Accounts, folders, permissions, equipment, agreements and open tasks need to be transferred, closed or documented deliberately.
Define where and how the team works together
Choose shared systems
Define which institutional systems are used for files, communication, planning, documentation and collaboration.
Prefer institutional accounts
Where possible, use institutionally managed accounts and project-appropriate access routes instead of private individual accounts.
Define access groups
Assign permissions by role and task rather than giving everyone full access by default.
Define shared storage
Set one authoritative project storage location and avoid unclear parallel main copies on personal devices.
Define communication routes
Decide where binding information, decisions and operational coordination are documented.
Define approvals
Specify which content or decisions require formal or documented approval.
Limit external access
Give partners only the access they need and document when and how it will be removed.
Ensure substitution
Avoid technical or organisational single points of failure by keeping critical responsibilities transferable.
A short shared standard prevents many later misunderstandings
The agreement can be concise, but it should live in one central place and be understandable to new team members.
| Element | What to record | Why it matters |
|---|---|---|
| Roles | Who takes on which specialist, technical and administrative tasks? | Makes responsibility and substitution traceable. |
| Working environment | Which systems and storage locations are authoritative for the project? | Prevents unclear parallel working environments. |
| Access | Which roles receive which permissions? | Connects collaboration with protection needs. |
| File & version rules | How are files named, versions distinguished and master files identified? | Reduces confusion in shared storage. |
| Decisions | Where are important project decisions documented? | Prevents context from remaining only in private messages or conversations. |
| Approvals | Who may approve which outputs, expenses or publications? | Makes responsibility clear before release. |
| External partners | Which access rights, deliverables and handovers apply? | Prevents unclear interfaces between organisations. |
| Role changes | How are accounts, files, open tasks and knowledge handed over? | Maintains continuity during staff changes. |
| Project closure | What is handed over, closed, preserved or archived? | Makes the transition out of active collaboration manageable. |
Different project types need different collaboration agreements
Small internal project team
Even with only a few people, shared storage, roles, approvals and substitution should be clear so work does not depend on personal devices or accounts.
Interdisciplinary project
Different working practices and specialist languages need clear interfaces, shared documentation locations and traceable responsibilities.
External project partners
Clarify access, exchange formats, responsibilities, deliverables and removal of permissions from the start.
Artistic collaboration
Alongside technical access, document roles, contributions, approvals and, where relevant, rights or publication questions.
Funded collaborative project
Partner roles, deliverables, reporting duties, institutional responsibilities and handovers should align with funder requirements.
Team change during the project
Accounts, project knowledge, open tasks, permissions and authoritative files should be documented so that a change can happen without losing control.
Collaboration is resilient only when critical tasks and resources can be handed over
Common warning signs in collaboration setup
The project has a technical and organisational single point of failure.
Context and traceability are lost during team changes or handover.
Permissions have not been structured according to tasks and protection needs.
There is no defined end point for permissions and project access.
Formal titles alone do not clarify who actually decides or is responsible.
Accounts, files, agreements, open tasks and knowledge can no longer be brought together cleanly.
Which service is responsible depends on the collaboration question
Collaboration is closely connected to these decisions
Training, workshops & consultation sessions
Relevant opportunities for this topic will be shown here automatically from the central calendar.
COMING SOON