The phases of project initiation and project closure are substantially covered in blog posts, talks, and other resources across the TechComm society. Today, I would like to address a less frequently discussed phase – replacing a technical communicator in a project team.
Before we begin – to make things easier, I’ll refer to a technical communicator as ‘writer’ in this article.
Let’s take a look at what we have:
- You used to be the single writer on your project team.
- For whatever reasons, you will be leaving the project, and a new person will start working in your place. (Reasons may vary – you are leaving on an extended vacation or sick leave, you are switching to a new project, or relocating to another city, etc.).
- You want the new writer to get a smooth start.
The idea is to provide the new writer with all the necessary information so that even if you are unavailable, the new writer will still be able to deliver quality work and make quality decisions, without wasting time trying to contact you or figuring things out themselves.
Here is the list of things you should consider before the new writer joins the team.
The list may vary depending on the project, but in general, make sure that the new writer gets the following:
- Credentials and access to the source control system.
Don’t forget to explain how you typically worked with the source control (folders, naming conventions, wordings for commit messages, etc.).
- Credentials and access to the test/development environments.
Explain the purpose of each environment, mention which ones you use to make screenshots, and which data may and may not appear on screenshots.
- Corporate account (e.g. a separate account in the customer’s Active Directory).
If this account is needed, think how the new writer will be able to work until the account is provided. In big corporations, the process may take up to a month.
- Credentials and access to task tracking tools such as Jira.
Same as for the source control, prepare to explain what your typical workflow looks like.
- Access and/or credentials to design and prototyping tools such as Sketch, Figma, Zeplin.
- Notify the team about the new writer.
- Indicate the timeline until which you remain on the project and when the new writer will fully replace you.
- Make sure that the new writer is officially introduced to the customer (via an email). Don’t forget to let the customer know that it was a pleasure working with them (this is just common courtesy).
- If the project team is multinational/multicultural, make sure to explain the cultural background of the project – communication routines and habits, courtesies, things that are (not) recommended to be said/done.
- List of people on the project team – who is responsible for what (according to their job title, and the actual roles on the project).
Note that the project team includes the customer as well 🙂
- List of SMEs, what they are responsible for, and survival tips such as who can review the document if the SME #1 is unavailable for whatever reason.
- Tips on how to deal with people in the team – e.g. John never answers on the same day, Alice usually needs 2 days for a review, and Garret likes to talk about the weekend during the interviews.
- If your project has mailing lists, make sure the new writer is added to all of them.
- List of communication platforms used (Skype for Business, Slack, etc.). If the project uses multiple channels of communication, explain when to use which (and yes, better prepare examples beforehand).
- Forward the invitations to all meetings that you attended yourself – backlog grooming, sprint planning, status calls with the customer, etc.
- Explain the purpose of each meeting, the role of the writer, expectations, etc.
- Original estimates that you followed.
- Estimates for any deliverables that were suggested but not approved (just in case they come back somewhere in future, you never know).
- Assumptions based on which the estimates were created (e.g. screenshot updates weren’t included due to budget restrictions).
- What was agreed to be delivered to the customer.
- And why. This part is important because it framed the old decisions and most likely will need to be considered when making new ones later.
- E.g., the customer was actually willing to have a help system, but they wanted the ability to edit source files so we went with Word files instead. But one year later, the customer starts using Confluence, and bingo – you can suggest having a knowledge base instead of Word files.
- List of project decisions related to documentation. These are basically the “why’s” – why we decided to have these deliverables, who and what influenced these decisions, and why.
Reporting and task tracking
- If the project uses Jira or similar tools, provide the link to Jira.
- If the project uses estimates, list the typical timelines for typical deliverables. If to stay within a reasonable range, it will be easier for the team to get up and running with the new writer.
- Explain the flow in Jira – who creates tasks (the writer, manager, customer, etc.), what their life cycle is, and how they relate to sprints and releases.
- Explain how you typically approached the tasks, where you found the information, even down to things like using Grammarly, adding borders to images directly in Word, or the sites where you took the icons.
- Style guide – be it Microsoft Style Guide, or any other. What’s even more important is to explain the items not covered in the style guide, or points where you consciously deviate from the style guide to fulfill the project needs.
My personal suggestion is not to rely on your memory and gather this information in a file that you can share with the new writer. From my experience, 3 months later, you will have a hard time remembering all these things yourself.
If you’ve had experience handing or taking over a documentation project, feel free to let me know if there are any other points to consider.