Culturish, remote culture experts, recently hosted a Teamwork User Group session about 'Using Teamwork to Document Processes' with Susan Fennema, Chaos Eradicating Officer (CEO) of Beyond the Chaos.
Topics included:
Watch the video below or continue reading to learn highlights from the event, hosted by Amber Kemmis and Nicole Pereira of Culturish.
Susan shared her screen to show how her team documented processes. Amber and Nicole said this was the first time in Teamwork User Group (TUG) history we saw behind-the-scenes screen sharing in someone's own Teamwork!
If you'd like to receive links to documentation resources like this in your inbox weekly, sign up for my 'Thursday 3 things' documentation email.
Susan found Teamwork while looking for an alternative to Basecamp, when she needed more functionality in a project management tool.
She and her team loved it so much that they became Teamwork partners in 2017. They make it clear to clients that they are not recommending Teamwork as partners, they are recommending it as fans.
Her team's goal is to get business owners out of running the day-to-day of their business operations, and Teamwork is their most recommended tool for doing that. It's rare that Teamwork is not the best-fit system for clients. "We love that Teamwork.com can be the single source of truth," Susan said. Users don't have to switch between multiple tools to complete their work. You can use Teamwork to do almost anything, including documenting your processes.
Susan said that documenting processes is a very underutilized use of Teamwork. That is why she was talking about it today, to bring more attention to these tactics for documentation!
Susan suggests starting with two internal projects: an admin project and an operations project.
The admin project is for the management team, such as HR tasks. You can lock down what the management team works on with privacy permissions settings if there are tasks that other team members don't need to see yet.
All other internal tasks can live in the operations project, for running the company. "It's where the magic happens," Susan said.
Some of the task lists that live in this project include the process review list (discussed later), steps for sending team birthday gifts, holiday cards and gifts task list templates, team meeting agendas, and general reminders to do regular internal tasks. Having everything as a task means it will show up in Teamwork's My Work area, so all your to-dos are in one place.
In this screenshot of the operations project, you can see the taskslists are on the left.
There are task lists for reminding people to do their timesheets, for example.
Interviewing, hiring, training, onboarding, offboarding, and other essential processes can all be set up in Teamwork.
You may also want to set up an onboarding project outside of the other projects, if you have trainings for team members to interact with. For example, each team member may have their own task list in the onboarding project. Some of her clients want to use Trainual for this, but you can actually do the same activities in a Teamwork task list in the same system where the team members are working anyway. đ
Susan has very few custom project templates since they only sell two ways to work with them, and each project template has internal onboarding steps to list out all the steps to set up the project.
Most internal work makes more sense to set up as task templates that will live in projects that already exist, such as loading task lists inside the marketing project.
Nicole shared that they have a project template as a 'shell' and all the project-level settings are there. Then they have a lot of task templates that allow them to modularize a project to match what the client purchased.
Another participant in the chat said they have 4 basic project templates and about 50 task list templates to build projects a la carte, to do different things for different clients depending on the services purchased.
Meeting agendas and notes as tasks in a task list
One popular topic that Susan discussed was using a task list for a meeting agenda and adding the meeting notes in the task comments. For example, if your company does EOS (entrepreneurial operating system), have a task list for the weekly L10 meeting agenda, seen in the screenshot below.
This task approach allows you to check off (close) each task as you discuss it during the meeting.
At the end of this task list template, there is a task to add this same template to the project before the next meeting. They are not recurring tasks. They are newly added task lists each week, to keep the comments and other history more organized.
If it is a 1-1 meeting and it needs to be more private, perhaps you set up a project for each team member for their 1-1s or special training, to better set privacy permissions on the entire project compared to the possible privacy settings on a task list.
An essential task list is the process review list. This is part of the process of processes, when you understand that processes evolve and grow. Processes are not a task where you check it off a list. You wouldn't say, "I did my marketing... done!" and never come back to it. Processes are living and breathing and should grow as the company grows or evolves. Having this process review list of tasks ensures the processes are reviewed and updated on a regular basis.
The process of building a process should also be a notebook or task list template that people load when they begin documentation.
Susan suggests using Teamwork Notebooks to document processes. These are combined with task list templates for a checklist of the steps involved in a process, so the notebooks don't become too long and to give more accountability for completing each step and not forgetting one.
Make sure you document properly by recording how, who, how often, and when are you reviewing the templates and processes.
In the notebooks area, the "How to" category is where the processes live.
She suggests separating policies from processes, and communicating that the policies are non-negotiable rules, while the processes make everything run.
A naming convention she suggests for processes is starting every name with a verb, which you can see below.
When writing the documentation in the notebooks, be careful not to duplicate content. For example, the sales process and the invoicing process should not have overlapping duplicate content in each notebook, even though the processes lead into one another. Instead, link to the other processes when one starts or the other begins, then you only update the information in one place. If you're typing the same things in two places, you risk getting it wrong or mismatched immediately or when editing it later.
Any word or phrase is searchable, to easily find the correct process to read
When you complete a process in your work, document it to make sure you donât make the same mistake on something you only do once a year, for example.
If you have a document and task list template that explains 'The process of processes,' with all the steps involved, the information about creating and editing should be in there!
Part of creating the process, one of the tasks in the list, is setting up a recurring task to check the process in x months, by creating a new task in the previously discussed process review task list. You need to update the process at least once a year.
Or, if you're just getting started with documentation and you're completing a lot at one time, set the reviewing date to be during the least busy time of the year for your business. Then as new processes are created, schedule them review for a year from the writing time, so it breaks up the work across time.
For editing processes, aside from those regular review tasks, some of the triggers that indicate a need to edit a process are tool changes and when you're dividing up work to new people and new roles in the company.
Though the 'keeper of processes' has traditionally been Susan, she is trying to get away from this responsibility. Many business owners are horrible at operations, but since she is an operations consultant, that responsibility stayed with her longer than usual. The 'process keeper' role should go to someone at the company who is detail-oriented, ops-minded, and understands how the whole company works together. It could also be multiple people, divided by departments.
If you divide the process responsibilities between departments, then you need an oversight committee so the crossover processes don't get lost. Crossover processes include things like the handoff between sales and service delivery.
When you're creating processes, part of the 'process of processes' is assigning the process keeper a task to review it. If that process keeper person leaves the company and is removed from Teamwork, Teamwork will give you a message about who to replace them in the task assignments. This is a helpful reminder to cover the handoff of those tasks during offboarding.
When processes change, another benefit of working in Teamwork notebooks is the 'include changes in email notification' button, the checkbox at the bottom. This will highlight the actual change in the notebook and not just send the whole document link for people to scroll through and wonder what changed. You can also choose which people are notified.
Publish as a new version so you have version control, and you can see who edited it in the past, when, and what was changed.
Susan said it is overwhelming if you share every change with everyone, all the time. This feature helps you to weed out info that is relevant to team members.
If your Teamwork is integrated with Slack and these update messages go to Slack, people can add an emoji to the Slack post to indicate they read and understood the change. This is a good idea when it's a larger change that people need to be aware of.
This same feature and process is also how you roll out new processes, notify everyone in the notebook, and follow up with a Slack message so people can respond to it.
Susan likes Slack notifications instead of email, since she is in Slack more often, it cuts down on email, and the Slack message allows you to click and go straight to the task in Teamwork or reply right in Slack.
If you only had a document (the notebook), there is not a high likelihood that all the steps would be completed. Some would be missed or misinterpreted.
The checklist format, the task list templates, is easier to follow and can be checked off (closed) as each step is completed. It also has due dates, so the steps are more likely to be done and not forgotten about.
Amber said her team sometimes gets overwhelmed when subtasks are used as a checklist, when they include many steps, so they set up the parent task that can be closed without closing subtasks. But if she finds that people start skipping the steps in the subtasks, then sheâd change the format back to require the subtasks to be closed individually. For example, developers may complain about the extra tasks, as it can be easier to overwhelm them with little tasks that ops people don't mind.
If someone leaves the company and a new person comes in, they are not lost since they have these processes to refer to.
Having processes documented in one place gives you one place to train people and one place to remember how to do things. A lot of times, mistakes are made because people are going off memory and not looking at the documentation.
Some of the companies she's worked with say they have processes. Then the clients say they aren't sure where they are and think they can maybe find a link... but they find the processes haven't been touched in 2-3 years. This is that incorrect mindset of thinking, "Check, I documented!" and then not coming back to it. No one properly rolled out the processes or is using the documentation.
Something she often hears from clients is that they have a process, but no one follows it. Susan says this means it's either a horrible process, not rolled out, or no one set expectations that this is the way we run the business.
Processes bring accountability to the business.
If only two people arenât following the process, those people need to be told that the company cannot scale and grow if they are not on the same page and running processes the same way.
If no one is following it, then dig in and find out why isnât it being followed. Is it too hard? Is it outdated?
You need to ask the people who are actually doing the process: why isnât the documentation being used?
Another benefit of documenting processes, for people who are non-confrontational and don't want to address people directly about their mistakes, is that it gives you an easier way to approach that situation.
If an outcome is not what you expect, you can ask someone what happened in the process, blaming the process instead of the person. The person involved hears that so much better, and they will be more likely to jump in and help you fix the process. Or, at a minimum, you learn if they followed it or not. This helps you approach it differently than screaming at them about the mistake. Maybe they did follow the process documentation, but they tell you that something different happened or didnât happen, and then you can fix the process. The team member may be thrilled they could help fix it, everyone else doesnât make the same mistake, and now business is a process-driven business.
If you want to assign a job title, and not a specific person, to the tasks in the task list template, there is a âChoose laterâ option when assigning tasks. This is difficult to find if you're in the new beta UI. Make sure you are naming the same role the exact same thing in order to change the assignee of all tasks to one person using one click when you load the task list into a project. Even one character difference will make you assign the same person twice.
A discussion about pre-populating a job title name in the task list template brought up the topic of having multiple people assigned to one task.
Susan likes that Teamwork makes it hard to do this, at least in the task list template area, because having multiple people assigned to one task makes it unclear whose responsibility is it to do it and to close it. Having the same task created for each person is a better plan.
Amber said if multiple people are assigned a task, it creates a challenge for forecasting resources (people's workload time).
She has tried having a shared fake user set up in Teamwork, like developer 1 and developer 2, so you have a capacity view of that role before assigning it. When you're ready to assign it, remove that fake user from the project, and then Teamwork asks you to reassign every task that fake user had to someone new.
An event attendee was looking for a better way to remind people to complete their timesheets. Susan's team has tasks for reminding people to do it, and they check for late tasks once a week.
Susan gives her team the opportunity to delete the reminder task if they don't need reminders, but only after the first month to create the habit.
If the company is an hourly-paid business where there are real consequences to not getting paid when people are not logging time, it can be easier to convince people to do it.
But if logging time is only related to workload forecasting and adjusting, you need to approach it by saying you're trying to make life easier for that person. You know that doing a timesheet adds work to their plate, but it will make life easier by managing workload so they are not overloaded.
Amber said that having tasks ensures accountability. People are able to check a box to say something was done, which is better than just a reminder to do it. It has an honesty principle to it.
As a manager, you can get notified when the team members check the time-logging task as complete, but it may be easier for you to have one recurring task for yourself to go see if the team's time-logging tasks are closed and the time was logged.
Thank you, Susan, Amber, and Nicole, for sharing this helpful documentation information!
Read more about how to create a system for documentation in this guide, and sign up for related emails below.