Goals:
Establish guidelines as a team on how we organize and store our content.
Migrate content out of repositories that are going to be sunset.
Review and update how we document our work and tell others about it.
Track the completeness and accuracy of our documentation moving forward.
My role:
I lead this work for my team, coordinating with individual team members and managers depending on the stage.
Deliverables:
A content strategy for the team, including detailed guidelines of how we use various content platforms and tools, best practices for documenting our work, and a maintenance plan.
A redesigned Confluence space for the team.
Documentation templates and automated workflows (via Smartsheet) to keep them up to date.
Results:
Content was reviewed and removed from repositories that were going to be sunset.
We created consistent documentation as a team in our Google Drive.
We created consistent documentation as a team in our Confluence space.
Before:
My team maintained multiple repositories for content. These varied based on use case, audience (internal vs external customers), how other teams work, and organizational preferences. The lack of predictable guidelines made it difficult for the team to find existing content and decide where to create new content. This was especially challenging as a globally distributed team working asynchronously – we were not working as efficiently as we could be.
Some applications and tools were getting phased out as integration with our parent company ramped up. The team needed to adapt additional tools into the workflow, including balancing two versions in some cases.
Lastly, process and program documentation was spread out and very out of date or completely missing in some areas. The team relied on individual knowledge and expertise, which made it difficult to hand off programs, know who to contact in an unexpected situation, or fill in for coworkers on vacation.
After:
Predictable guidelines made it easier for the team to find existing content and decide where to create new content. This promoted efficiency and productivity in the flow of work.
Team documentation looked more consistent and we had a process to review it regularly.
We differentiated between detailed operational documents for team members and more high-level descriptions of our work aimed at other teams.
We reduced reliance on legacy platforms, so were ready when licenses expired.
Process:
I used several tactics to achieve the team’s goals:
To set guidelines for each platform’s use and the best type of content it supports, I opted for a task-based approach, building use cases with specific examples. Sample guideline:
When the guidelines were ready, I shared them publicly and often via Slack, meetings, email, and through managers.
I created checklists to help the team wrangle their content. For example:
Each team subfolder in Google Drive has a folder called “ARCHIVE (Team Name)”. Criteria for archiving include:
⃞ Files/folders are not in active use and are not likely to be referred to again
⃞ Files/folders are redundant or duplicate information saved elsewhere
⃞ Files/folders belong to a program/project that is not being actively worked on
Once the guidelines were in place, we needed to migrate content to and from the right places. For example, runbooks needed to move off Confluence into Google Drive, so Confluence could be refocused on describing our work to other teams in the company. To that end, I reorganized the page tree to reflect who we are and what we do.
I held office hours and spoke to team members one on one, and also surveyed them for feedback. Sample survey questions:
To create templates, I looked at several examples for inspiration and reviewed all the existing documentation to find commonalities. I included helpful placeholder text and examples in the templates so whoever was filling it out had all they needed in one place. Snapshot of a template in Google Docs:
The last - but in some ways most important part of the process - was creating a maintenance plan and way to track quality of the work. The team needed to review their documentation and folders on a regular basis to ensure they stay up to date, and to archive anything that’s outlived its usefulness. We needed guidelines to follow. Sample item on the maintenance plan:
We also needed a way to make it stick. I used Smartsheet to set up automated notifications for reminders and update requests. There were also reminders to managers to check that individual team members had updated their documents. Sample automated reminder:
To help managers check the quality of their team’s documentation, I created a checklist based on 3 criteria:
Completeness (answers the question “Are all sections of the document filled out?”)
Accuracy (answers the question “Is the document up to date?”)
Usability (answers the question “Can someone use this document to get the work done?”)
The document assigns scores based on the responses, which allows managers to compare their team members and suggest areas for improvement.
Throughout the process, I kept some key messaging themes in mind:
This is new to the team and we may need to tweak the plan as we learn.
This will (eventually) save us time and make it easier to find things, cover for people on vacation, and react quickly to an incident. The time we spend now will help us moving forward.
Feedback is welcome at all times.
What I’d do differently:
It was important to be sensitive to the level of change fatigue the team was already experiencing given recent events and workplace changes. I wanted to make it as easy as possible to follow the guidelines, use the templates, and voice feedback.
I sensed there was much more enthusiasm for the idea of updating documentation than there was appetite for following through. That’s why I felt it was important to ask for feedback regularly, so that the team was more bought into the system.
I expected managers to hold their individual team members accountable, and sometimes this was more successful than others.