How to Use Collaboration Software to Map Workflows
On the very first day of my very first real job, the most senior editor of the journal-publishing company that hired me took me to a huge flowchart pinned on a wall. "Here's how an article goes from written to published," she said. She walked me through the whole process, emphasizing the parts where my team and I were involved. This was 2001, before collaboration software was freely available, but the lessons I learned that day apply even in this age of Asana and Slack.
Every journal article went into an oversized poly envelope with a piece of paper taped to the front. The paper was color-coded to the journal in which the article would appear. We called this a job jacket. Every time the article went to a different department, whether to the copy editors for proofing or to the keyboarding department for changes, the history of its journey was logged on the job jacket. When one employee was done with it, she would assign it to a new department by writing a line on the track sheet. Anyone who saw a job jacket knew exactly all the stages that the article had been through and where it was supposed to go next.
Thinking back on it, these job jackets were a precursor to and physical manifestation of today's workflow software, like Asana. The workflow chart that was pinned to the wall was an excellent orientation for me, as a new employee, and anyone else being onboarded. It gave me a crystal clear picture of what the organization did, and how.
In today's world, where we push for paperless environments and have largely moved to electronic files and folders, it's easier to forgo creating these kinds of workflow documents and keeping them up to date. But for all businesses and even hobbyist-level teamwork projects, it's super important to document your workflow.
Why Document Workflow? Why should you document your workflow? There are a few absolutely critical reasons, including the following:
- It helps business owners and managers fully think through and understand what happens at every stage of the business process, and why;
- It enables unnecessary steps to be identified and cut out of processes;
- It reminds employees or team members who may be distant from certain stages of the business why they exist and what value they provide;
- It's essential for onboarding team members;
- It's one of the best ways of explaining to potential colleagues, clients, and investors how a business operates; and
- It allows a team to more effectively start using collaboration tools.
To that last point, I've already mentioned Asana. Asana is a workflow-management tool, kind of like a to-do list on steroids. It is very similar to the job-jacket system I used in my first publishing job. Asana lets you track tasks that need to be done and push them through a process. Every task has a history of all the steps, or subtasks, that it's been through. When one person is finished with the subtask at hand, she or he assigns it onto the next step and directs it at a person or department who will pick it up next.
I've made the analogy before that Asana is like a deck of cards, whereas project management software is like a board game. When you open up a board game, you might have something like a board, a variety of playing pieces, and a clear rulebook for how to play the game. Everyone who is playing agrees to those pre-determined rules. You could deviate from the rules, but the game has been designed for maximum enjoyment when you stick to those rules, so you do.
When you play cards, however, everyone who's playing needs to agree on what game will be played and what set of rules you'll follow. You could play hearts or you could play spit. Some card games are well-known with established rules, like Texas Hold'em. Then there are other games that have variations, such as rummy (gin rummy, straight rummy, 500 rummy, and so on) and you need to hash over the rules with everyone at the table to make sure you'll all be in agreement about how to play. There's also the option of inventing on your own card game, with unique rules that you have to teach to everyone who's up for playing.
Asana (and many other collaboration tools; I'll give more examples in a moment), as I said, is like a deck of cards. So to make Asana work, everyone needs to know how the game is played, what are the rules, what is the objective, and how the game ends.
What About Kanban?Kanban boards are another example of collaboration tools that are more like a deck of cards. Trello is one example of an online kanban tool. Software development and programming teams often use kanban in a highly specified, predetermined way (like playing Texas Hold'em), whereas those using kanban for personal use can make up any rules they like.
If you have a documented workflow, you can easily map that workflow into Asana. It is much easier to start using Asana when you already have a documented workflow because it means you've already thought through the entire business or team process from top to bottom. Adopting Asana takes some trial and error no matter what, but it will be much messier and more frustrating if you do it without ever having documented your workflows before.
Mapping Workflows With workflow software, there's usually something that gets completed, even if the whole process is ongoing. Whatever can be completed is usually your tasks or subtasks.
The idea of completion is very different in project management software. A project by definition is something that is completed and delivered on a date. But not all types of work are projects. At the journal-publishing house where I worked, an article would be complete when it was printed. Similarly, each issue of a journal had an end date when it was delivered. But copy editing was never complete. It was ongoing work. It still needed to be tracked. It had concrete task assignments—copy edit this article—but copy editing itself didn't have an end date or deliverable.
The process of mapping a workflow also involves identifying exactly which processes or procedures need to be explicitly assigned and tracked. This precision and level of detail is very important.
Think about a recipe for cooking. Recipes don't list every single step because many of them are implied or understood. Recipes don't tell you to crack eggs, empty their contents, and throw out the shells because "add eggs" already means that, and it becomes needlessly cumbersome to list out all those steps. Similarly, in a work environment, it might be understood that "edit article" means "check the headline, check the byline, copy edit the piece, and leave any questions for the author."
In some situations, however, you might need to be explicit to a finer degree. I once worked in newspaper publishing where checking headlines, photo captions, the date on the bottom on the page, and the page number should have been separate steps from copyediting because they were often overlooked.
In other words, you have to figure out what level of detail is necessary. Too many steps, and people who use the software are going to ignore the procedure. Too few, and critical mistakes might happen. It will likely take some trial and error to get it just right, but you have to make some decisions before you start.
Mapping Mindsets When mapping workflows, you'll also spend time figuring out how your organization thinks, collectively. What is your organization's mindset about projects, people, or topics of interest? It's relevant in Asana, as well as in other collaboration tools.
Slack is a good example. Slack is a messaging platform that emphasizes pull rather than push notifications, so it's all about opting into the messages you want to receive. To make good filters for those notifications, you need to rely in part on Channels. Channels are like groups, and to make Channels effectively, you have to know how your team thinks about, well, everything. Do you think in terms of departments or projects? Do you think in terms of topics or clients? If you run a real estate company, maybe you think in terms of neighborhoods, or property value thresholds, or agents. You need to figure out your team's mindset before creating Channels so that they are actually effective at facilitating teamwork.
Collaboration tools often include more ways to organize information, such as using color-coding, tagging, and sometimes even color-coded tagging. Remember those color-coded job jackets I described earlier? Same deal. When used properly, color-coding is a visual signifier that immediately conveys information clearly. For that reason, color-coding increases productivity. I highly recommend using color-coding in a collaboration tool, as long as you first make sure you understand the team's mindset about why something should be color-coded in the first place. What information needs to be conveyed immediately and without words? You have to understand your team's mindset to be able to answer that question.
Including Culture It's important to document workflows before mapping them to a collaboration tool, and it's just as important to understand and map mindset. The final piece is culture.
Collaboration tools mirror company culture, and vice versa. It's really important to establish general rules of engagement regarding professionalism, level of formality, and where it is and is not appropriate to go off topic.
From an employee's or team member's point of view, collaboration tools are very often used as a place to blow off steam. In my experience, people will air their grievances regardless of whether the collaboration tools give them a dedicated space for it. Some organizations value open debate and even heated discussions about work, whereas others see it as distracting and potentially dangerous.
Collaboration tools alone can't dictate whether people will vent and dissent in the appropriate places. It has to come from company culture. People in leadership positions need to make clear whether they want team members to speak up with complaints and arguments within the context of the work or outside it. Who needs to know when there's a problem? Do team members want anonymity before expressing a concern or complaint? Is complaining done for catharsis or to highlight potential problems with the work and workflows? If it's going to happen anyway (and it is), it's better to take it into account and make decisions about it rather than pretend it isn't happening.
Additional Resources Another resource that makes mapping workflows easier is mind-mapping software; see these tips on how a mind map can declutter your project management. If you're in the early days of using project management software, these four tips for getting started should help. And for a deeper look at Asana, it helps to read some tips for using Asana.
This article originally appeared on PCMag.com.