The tools you use should reflect meeting a specific need for your project or situation rather than an effort to use the latest and supposed greatest of what’s available.
A collaboration’s needs can vary widely depending on the complexity, degree of integration and duration of a project or collaborative relationship. (See more about this at collaborativejournalism.org/models/)
Simple projects with a limited number of partners and a limited duration of engagement with a low level of production expected don’t require all that much infrastructure and many can get by with email, instant messaging and some shared storage and files. But as projects get larger or more complex, there are multiple needs that a project might have to account for. The following sections are organized by core needs, common needs and potential needs.
Every project needs to consider how these four needs will be accounted for from an infrastructure perspective:
- Communication Among Partners
- Asset Management
Communication Among Partners
Communication is the linchpin and most important factor upon which the success or failure of a collaboration often rests. Accounting for how communication will take place, by what means and what the expectations are for frequency and conduct is a critical component of collaboration
There are three primary pathways for communication:
Voice: One-to-one calls or teleconferences
Text: Email, instant messaging, group chat, text messaging
Video: Video chats
Text-based tools provide records that are easy to make available to the group at large when there is a need for everyone to access the information or be in the loop. But easy access is harder to accomplish with voice and video. If you find yourself often using teleconferences or video chats to brief partners, consider what note-taking or recording steps are necessary to make sure that absent partners are fully included. (Note, this is also important for equitable accessibility considerations.)
For everyone involved to be fully included and empowered to participate, they must all have access to the essential information about the collaboration: the goals, the timelines, procedures, commitments and deliverables. This requires a level of documentation that matches the complexity of your project. Perhaps this is a simple Google Doc that has been shared with everyone or perhaps you need a living set of documents that are a running resource connecting everyone with the information they require to remain fully engaged and effective in their work.
Regardless of the nature of a collaboration, at some point, partners will likely need access to the content itself either for collaborative creation, editing, reviewing, or previewing it as part of the process.
This means deciding how content will be shared and what permissions might be necessary to grant to different users. The most permissible version of thinking here, and likely the most common, is that most people can see and work on most things, with less need for tight control beyond whatever expectations have already been set by leadership or mutual agreement.
One of the primary challenges in this need space is version control. If content is being moved around via file-sending through email or shared storage where files are fixed at a point in time with limited edit history, then it can be easy for multiple parties to be working on different versions at the same time, making a final merge of content difficult or time-consuming. If content is moving around this way, file-naming conventions become particularly important.
The scenario becoming more common and reducing the headaches in this space is a system that uses a browser or app-based version of the content that multiple parties can collaborate through with fewer opportunities for overwrites or lost changes. A challenge to look out for here is permissions and ensuring that everyone has access and the potential for additional cost as tools that charge by the seat may become cost-prohibitive when you need a large number of people to have access.
As you’re planning your project, establish how content needs to be available to partners and at what point in the process.
Collaborative creation/editing: Content needs to be available to all relevant parties as early in the process as possible along with a clear idea of how changes will be made. If this is by moving files around via email or sharing services, establish naming conventions and expectations around comments in the files so that changes are clear.
Review/Preview: Partners need access to finalized content to plan around running that content, to offer feedback or to otherwise be aware of what partners are producing. This can be accomplished through a variety of means. The challenge here is ensuring that any updates, corrections, etc. also propagate to all partners who had access to the original version.
This refers to both internal planning assets like notes, timetables, story budgets, contact sheets, logos, etc. and the publishable rich assets that partners will need access to for whatever platforms and versions of content they may be publishing.
This often happens via email, but it’s wise to maintain assets in a central repository to which all relevant parties have access. This helps ensure version control and consistency across partners and platforms.
Consider what assets you will likely have as part of your project and create a clear structure for managing and making them accessible.
Common Asset List:
- Embed Codes for interactives/visualizations
Additional considerations: File naming conventions for photos, audio and video clips are important as it is all too easy for people to dump a lot of things into a folder without proper metadata or names. Sorting IMG0001 through IMG9000 is a task that no one wants to do after the fact. Establish a baseline of expectations here to keep this a manageable situation.