How to manage technical writing projects remotely

I was asked to address how to collaborate on technical writing projects remotely.  Here is what I’ve found works well.  We have a virtual team of seven and a huge body of work for a government utility.  The work includes analysing and defining processes and writing: 

Processes	Procedures	How-to/ user guides
Special reports	Training aids	Work instructions
Glossary of terms and acronyms	An overall manual	Wiki of all information

The Methodology

Here is a high-level overview of how we manage our workload.  I hope this provides some helpful ideas:

Meetings

We meet at the start of every new project to

1.      discuss project structure and participants (for example:  subject matter experts (SMEs), those who will be required to review and sign off the documents.

2.      sign off rules to handle the details of how we will work to create and distribute documents.

We set two recuring weekly meetings.  Everyone involved with the documents (including representatives from the subject matter teams) is required to attend: 

·        one on Monday mornings (discussing plans for the week, any constraints, challenges or conflicts)

·        the other on Friday mornings (review and celebration of the week’s progress – usually with everyone having virtual coffee/ tea and cake).

Tools

1.      Our tools of collaboration are Microsoft™ Teams and SharePoint.

2.      In SharePoint we set up sites and folders according to rules all agree to, this includes an:

·        'In development' folder in SharePoint that is only accessible by those writing documents – it includes agreed to sub folders by topics

·        'In production' folder in SharePoint where finished, to be reviewed and signed off documents are stored in PDF-only format, accessible to users – with structured sub-folders by topic.

3.      We use a consistent and easy-to-understand language for labelling folders to make it easy for staff to locate documents.

4.      No other documents are stored in the collaboration sites but work in progress.

5.      We establish a structure that relies on one version being stored in SharePoint and use document history should previous versions be required.

Document Manager

We charge one person to be the document manager.  They have the responsibility to

1.      audit and maintain the document rules.

2.      manage permissions, structure and any problems with the SharePoint sites

3.      monitor progress of all documents, for group reporting.

4.      maintain the list of unfinished or incorrect information and return documents to the analyst to correct/ complete.

5.      to do a final 'polish' of all documents along their journeys to ‘tie up any loose threads’ and make decisions about content, structure, format, etc. to result in a ‘consistent quality’ of the product.

6.      PDF all final documents before they are removed from the development site and moved to the production site.

7.      pull all manual segment documents into the structure of the ultimate manual and wiki once a document segment is completed and signed off.

Document Rules

1.      We established templates for each type of document that all must agree to and use.

2.      We maintain a strict naming convention for files, folders and documents.

3.      We maintain a team Microsoft™ OneNote that includes

a.      a tab for each contributor for their ongoing discoveries, questions and segments of frequently used copy

b.     an ultimate progress list with the analyst writers responsible for keeping their progress deadlines current

c.       a shared list of tasks and who is responsible for what and by when

4.      When a document is being reviewed by an SME on an uncontrolled document, we provide the reviewer with clear instructions for how we require changes to be noted.  (For example, we ask the reviewer to use ‘Comments’ in the ‘Review’ section of Word, and not ‘Track Changes’)

5.      We instruct reviewers not to worry about spelling or formatting -- as this is all pulled to one consistent standard by the document manager.

Analysts Writers

1.      In our team, there are three process analysts who work with subject matter experts (SME) and collaboratively create process flow documents with them.

2.      After the process flows are developed, they are sent to the document manager to review.

3.      The document manager uses ‘fresh eyes’ to review the ‘as is’ and ‘to be’ approaches for logic and potential improvements

4.       The process analyst is responsible to store only ONE version of a document in the collaborative SharePoint (which can be accessed by other analysts -- who may make or be asked to make -- contributions)

5.      All documents hold a warning in the footer, ‘If downloaded, this document is an ‘uncontrolled copy’. 

6.      Copies of uncontrolled documents must be approved for release by the document manager if required.

Conclusion

Although this exact type of structure may not work for every project, it should give some hints at the many things to consider when working collaboratively and remotely. 

One thing I have learned is that if the management of the work becomes too complicated, or scattered in the hands of too many, it is doomed to be resisted and will fail.  I think the K.I.S.S. formula works best in all things.