While it may be both comforting and disappointing to know that no one has figured out the perfect set of tools or the perfect process by which to select the specific tools that will work best for your collaborative project, there are things we can do to make the process more manageable.
Selecting tools to manage the editorial process is no easy task, whether it’s working by yourself as a freelancer or piloting new tools for your organization. It becomes especially challenging when trying to build a tool chain that works for multiple partners that can encompass freelancers, non-news partners, and newsrooms big and small.
While it may be both comforting and disappointing to know that no one has figured out the perfect set of tools or the perfect process by which to select the specific tools that will work best for your collaborative project, there are things we can do to make the process more manageable.
Your tool set may change by the project, the partnership or the limitations of your working situation at any given time.
What follows is a guide to ensuring that basic structural needs are accounted for when working in partnership with others and a series of steps and questions you can answer with your partners to find and make use of the best tools for the work you are trying to do.
It takes time to assess, test and adopt tools, even more so when doing it across multiple partners. It is easy to get bogged down in deciding on your infrastructure. Avoid tools where the complexity of the tool itself outstrips the complexity of your project unless all partners are comfortable and well-versed with the tool and its complexity is an asset. It’s important to remember that partners should be equally able to afford and acquire the tool. Be careful to not push partners toward adopting something that’s new to their organization and that might cost them a lot of money just because it’s what your organization is most familiar with or is already using.
When working collaboratively, seek the simplest solution that is appropriate and fitting for your project.
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 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.)
Consider:
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.
Consider:
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.
Consider:
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:
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.
Consider:
More tightly integrated, long-term or complex projects frequently need to account for these needs:
This topic has an entire selection of books that could be assigned reading, but we’ll limit this discussion to the simplest set of considerations to make so that work can get done and that everyone involved knows who’s responsible for what, what its relative status is, the expected outcome and the timeline.
This can be as simple or as complicated as you like, everything from a shared spreadsheet to using tools that are dedicated to task management. Your needs here will be dependent on how complicated your project is. It’s advisable to not make the tools more complicated than the project itself. If you and your partners are well versed in a specific task management system, then it’s more likely to help than hinder, but if you and you’re partners are not on fairly common ground here, it’s easy to sink a lot of time into something that may be more robust than the work requires. Let the complexity of your project drive the complexity of tools in this instance. If you can make do with a spreadsheet that tracks the work to be done, that is fantastic. If you truly need a complex system for a complex project, then this particular need may require some planning and discussion among partners. In later sections, we discuss what things to think about when considering and testing tools.
Consider:
Similar to task management, perhaps this is a text file or spreadsheet with milestones and shared timelines or perhaps it’s a more complex Gantt chart or calendaring system. If you need infrastructure to support schedule management, its complexity should match the complexity of your project.
Consider:
These needs are less common but should be assessed as to whether they are relevant for the project you are working on.
Whether your partners would simply like to share language for social media posts to avoid duplicating efforts or your project has a sophisticated, coordinated roll out, some process by which to coordinate the marketing of the project can be useful.
Consider:
With collaborative projects that have a high level of audience engagement, it’s important to be clear by what means that engagement is taking place and how access and sharing will happen among the partners.
Consider:
Where are you recording what success metrics are being tracked, and how will you note status and benchmarks throughout the project and after its conclusion?
If you’ve outlined how you will gauge the impact of your project, do those metrics require some form of documentation, logging or tracking that will need to be in an accessible form?
Do you need a system for sharing analytics that are relevant or useful to partners?
There are six primary models of collaboration based on Sarah Stonbely’s examination of 25 collaborative projects.
“We have identified two of what we think are the most important elements by which collaborations are organized: duration of time, and degree of integration among partner organizations. As both of these increase, the level of commitment required to make the collaboration work also increases. Using these two variables, we have identified six different models of collaborative journalism.”
Those same elements: duration and level of integration are effective metrics to guide how complex your tool chain for collaboration must be and how much time it’s worth investing into choosing and implementing tools.
Shorter Duration
Least Integrated
Ongoing Duration
Deeply Integrated
There is no one system for collaboration and in the majority of cases, collaborative projects are assembling chains of tools that largely meet their needs as they collaborate. Considering which tools may be appropriate for a project depends on a variety of factors.
∞ Email chains
Adobe Creative Cloud
Airtable
All in the CMS
Asana
Basecamp
Caspio
CoSchedule
Dropbox
EditFlow
Etherpad
Evernote
Facebook Messenger
Flow
FTP Server
G-Chat
Go To meeting
Google Calendar
Google Docs
Google Site
Hipchat
Jira
Join.Me
Methode
Microsoft Teams
Microsoft Word
Monday
Notion
OneNote
Outlook Calendar
Paper
Podio
Range
Screendoor
Scrivener
Skype
Slack
Submittable
Telegram
Trello
UberConference
WhatsApp
Or bespoke builds for specific projects
To decide whether a potential tool is the right fit for your partners and your project, it’s important to think through how the tool is likely to be used.
For the most part and for most projects, a fairly open approach to permissions works for permissions management. Allowing most people to do most things is a reasonable plan. However, if you are managing a complex project with a variety of stakeholders, permissions management becomes more of a concern.
Free
Paid
Build
Building your technology should be a last resort if there is truly nothing out there that will work and if you have the means and ability to build and support the work and ongoing support and maintenance.
How much work is it going to take to use this tool compared to how complicated the tasks are?
Tools that are likely to be around for a while:
Using someone else’s tool or platform always means ceding some level of control.
When working with companies that create, manage or support technologies that we need to use for journalism, doing due diligence on their policies, practices and terms of use are an important part of evaluating tools for potential use.
Support users
Part of your collaboration documentation should include which tools are being used in addition to what changes have been made to either tools or workflow.
When bringing a group together and assembling the tool chain to be used by everyone, decisions have to be made. When recommending tools, there are details that everyone should be able to consider.
The mission of the Center for Cooperative Media is to grow and strengthen local journalism, and in doing so, serve New Jersey citizens. The Center does that through the use of partnerships, collaborations, training, product development, research and communication. It works with more than 270 partners throughout the Garden State as part of a network known as the NJ News Commons, which is its flagship project.
The network includes hyperlocal digital publishers, public media, newspapers, television outlets, radio stations, multimedia news organizations and independent journalists. The Center is also a national leader in the study of collaborative journalism. It believes that collaboration is a key component of the future success of local news organizations and healthy news ecosystems.
The Center is a grant-funded organization based at Montclair State University’s School of Communication and Media. The Center is supported with funding from Montclair State University, John S. and James L. Knight Foundation, the Geraldine R. Dodge Foundation, Democracy Fund, the New Jersey Local News Lab (a partnership of the Geraldine R. Dodge Foundation, Democracy Fund, and Community Foundation of New Jersey), and the Abrams Foundation.
For more information, visit CenterforCooperativeMedia.org.
This report is part of a series of five collaborative journalism guides produced in 2020 by the Center for Cooperative Media at Montclair State University, thanks to generous support from Rita Allen Foundation.
The Rita Allen Foundation invests in transformative ideas in their earliest stages to leverage their growth and promote breakthrough solutions to significant problems.
The guides were also produced in partnership with Heather Bryant, who agreed to update her Collaborative Journalism Workbook for inclusion as one of the series’ six guides.
To see the guides online, visit collaborativejournalismhandbook.org.
To learn more about collaborative journalism in general, visit collaborativejournalism.org.
Heather Bryant is the founder and director of Project Facet, an open source infrastructure project that supports newsroom collaboration with tools to manage the logistics of creating, editing and distributing collaborative content, managing projects, facilitating collaborative relationships and sharing the best practices of collaborative journalism. She published the Collaborative Journalism Workbook and works with the Center for Cooperative Media to build resources for collaboration. Bryant researches and writes about the intersection of class, poverty, technology and journalism ethics.