How People In Remote Locations
Can Work on the Same Document
(other than using a wiki)

With the increasing use of "wikis" -- online platforms that allow documents to be accessed and edited by various people via the web -- it's never been easier to work collaboratively on documents with people in remote locations. TechSoup has great information in this free online article on what a wiki is and why nonprofit organizations should care at all about using such, as well as examples of nonprofit organizations that use wikis to work collaboratively with their immediate communities and remote staff.

But even with the increase in use of wikis, the vast majority of mission-based organizations (nonprofits, non-governmental organizations or NGOs, civil society organizations, public sector agencies, etc.) cannot afford a wiki platform of their own.

Not being able to afford a wiki platform does NOT mean a nonprofit organization cannot easily share data, documents and presentations among remote staff, and work together on such. In fact, the key to working together collaboratively online isn't your computer technology or your budget; it's how your humans save, share and respond to information and requests for feedback. It's mostly about trust-building, good organization and good management.

Most documents and files by mission-based organizations that need to be shared during a production process are word-processing documents. Even text that will ultimately be laid out using specialized software, such as Aldus PageMaker or Quark Express, usually begins life as a word-processing document. Therefore, it's particularly easy to work together on content early in a document's life.

Database content is also often easy to share -- you can send your data in a variety of formats to someone who will manipulate the data in their own specialized software, and they can save their data similarly, so that you can use it in your own specialized software.

Even presentations are easy to share, so long as everyone needing to view the presentation has the software necessary to do so (OpenOffice is a great, FREE alternative to Microsoft, and will allow everyone to have the same presentation software). If everyone has the same presentation on their computer, then a conference call is all you need to walk all of these remote people through the presentation and gather their feedback -- and a conference call is still cheaper than specialized collaboration software.

Here are some tips for successfully sharing documents and data among people in different locations, without purchasing specialized software to do so. Even if you have the luxury of a wiki, you may find some of the suggestions below helpful in motivating staff to use such:

For all documents and files that need to be edited/reviewed by several people:

1. It is vital that everyone understands that there are deadlines to be met, and that the deadlines are real. Provide a calendar to all document/data reviewers and contributors that highlights all deadlines: for content submission, first edits, second edits, phone conferences, final edits, etc. Reinforce these deadlines by sending an email reminder to reviewers two working days before each deadline date.

2. Designate a naming system for reviewers and contributors to use when they return a document or file to you with their edits. For instance, require that each person add their initials at the end of the document's name (ofcourse, you need to make alternative suggestions for people with the same initials).

3. ONE person will need to be ultimately responsible for reviewing all of the comments and data, and attempting to incorporate the changes into the document or file. If you have more than two people reviewing a document or file and submitting changes, it will probably be impossible to incorporate all of everyone's edits; the final editor must be empowered to make decisions regarding which edits to accept and which to leave out.

4. Consider having at least one online chat and conference call (yes, all at the same time!) regarding the document after first edits are submitted by reviewers, so that everyone can highlight what they think is most important about their own edits and additions.

5. In addition to a conference call with everyone, remember that some people may not feel comfortable sharing their feedback in a group setting; provide one-on-one opportunities for each person to provide feedback. Some people may even want their feedback to remain anonymous.

6. Keep track of who has not provided feedback, and seek them out specifically to find out if they have read the information and have comments.

7. Let reviewers see a later version of the document or file, to see how their edits were -- and weren't -- incorporated. Encourage them to provide feedback and, if there is some edit they feel strongly about that they don't see and still want, to highlight and, if needed, resubmit such.

8. THANK REVIEWERS at EACH stage. Even if they are staff and it's part of their job to review such, you need to make an extra effort to thank them for their remote contributions; it will make it easier for future remote collaborations, because they will see and feel the value of the time they spent reviewing and editing. Thanking contributors by name in an email to everyone who was supposed to review a document also reminds those who did not submit edits how important such submissions are, and can prompt their participation next time.

Word-processing and documents for publication:

1. For first drafts of documents, when the most important task is agreeing on basic text, save the document in a "low" version (you can find this under "Save as"), before you distribute the document to others. You can also save the document as an .rtf (rich text format) file; this will allow the document to be read by just about any word-processing software.

2. If everyone does have the same word-processing software, have them use the edit features that come with most such products, which cause text changes to the document to be in a different color than the original. Otherwise, reviewers should put their changes in double brackets [[edits]], to make the changes easy to find.

3. To allow reviewers to see a document in its designed form, such as via Aldus Pagemaker, simply save the document as a PDF file to submit to reviewers. However, submitting edits to such a document is tricky for most people, because most use the free version of the PDF reader, which does not allow a document to be edited. If you have allowed reviewers to edit text earlier in the process, their feedback should be minimal by the time a design is drafted, and their changes should be easy to write out and fax back to you.

4. Ofcourse, web designs are particularly easy to share among reviewers, no matter what kind of software they have, so long as the pages have been designed for the vast majority of browsers, not just one kind. Reviewers can insert their comments directly into files, in a different color or font style than the rest of the text (so long as they know HTML).

A caution on the sharing of designs, from consultant Jack Vickery of Vancouver:

"Designing web pages when there is a significant difference in resolutions or the restriction of colours used can be extremely frustrating. I once spent several days of back and forth emails with a client who was complaining that the photos I had placed on her web site looked horrible. It was not until I saw the web site on her computer that the penny dropped, she had the resolution set to 600 x 480 and 16 colours (required by a scrabble game she liked to play). Once I showed her how to reset to something more common the problem (literally) vanished.

Database sharing:

1. Everyone needs to have the same field names for data they are going to share. For instance, one person shouldn't call a field "first_name" and another person call the same field "firstname". Get uniformity in all field names to make data sharing easier.

2. Agree which fields of information will be shared and which will not . All staff should not have access to, for instance, the names and addresses of an organization's donors, or salary data for staff.

3. A database design can be shared via screen captures, if different people and organizations don't have the same software (but probably, you aren't sharing database designs but, rather, DATA).

4. Have a way to identify what data came from which organizations, departments or offices. Each individual record should have a field that tells the person or organizations from which the data in that record (name, address, phone number, etc.) came from.

5. Follow the guidelines outlined in Importing Information Into A Database

You can share files as attachments to email, but you run the risk of such emails being blocked by junk mail filters. A free alternative is to create an online discussion group via YahooGroups or SmartGroups, and use the file-sharing function for the group to share your data with others. Both of these free options allow you to restrict membership and the viewing of any data that you put up on the group, and use of either will NOT create more junk mail for users (provided you keep your group private).

Ultimately, no matter what method you use to share information and solicit feedback, trust will make or break the system: everyone involved in the process should feel that you can be trusted you to hear and value their feedback, they must quickly and easily "see" the value of their participation, and they must see the results of the time and energy they spend in reviewing information and providing feedback. No software in the world can build trust; only the way you respond and relate to others can do this.

Do you have other tips for working on documents remotely, without having to purchase special software? Send me your suggestions!

Also, check out MacWindows, a site for macintosh/windows integration solutions. Includes tutorials about making Macs and Windows work together, practical info for users of cross-platform products, and listings of products and links to manufacturers sites.

 
This information was originally prepared for and published in TECH4IMPACT, a monthly e-mail update to help mission-based organizations use computer and Internet technologies to benefit people, communities and the environment. To receive TECH4IMPACT regularly, you can subscribe manually, by sending a BLANK e-mail to:

tech4impact-subscribe@yahoogroups.com

Disclaimer: No guarantee of accuracy or suitability is made by the poster/distributor. This material is provided as is, with no expressed or implied warranty.

All Coyote Communications materials are works-in-progress. If you would like to add something to these materials, please contact me with your suggestion; if your contribution is used, you will be credited (unless you don't want to be). Please include your name, email address, web address (if applicable), the name of the company you represent (if any), and any other information you would like to share.

Permission is granted to copy and/or distribute a limited amount of material from this web site without charge to recipients if the information is kept intact and without alteration, and is credited to:
          

Please notify me if you intend to use these materials or to quote me.

my consulting services | about Jayne Cravens | return to home page |
contact me | linking to or from these pages