Standardizing Processes: How to Create a Documentation Style Guide

Standardizing Processes: How to Create a Documentation Style Guide process.st /standardizing-processes/ 8/21/2017

From putting together flat-packed furniture to avoiding nuclear war, we’ve talked at length on why processes are important.

They’re the lifeblood of any consistent business, allowing it to repeat its successes, avoid mistakes, increase efficiency, and create effective to do lists. Without them you have no hope of even knowing what you’re doing right or wrong – you’ve more chance of putting together IKEA furniture with no instructions than of improving your situation and growing your business.

1/9

However, without standardizing processes you make, anything you document will do more harm than good.

Different layouts will make it hard to distinguish what the correct version of the process is, varying language across your teams will make working together a nightmare, while multiple naming and storage methods make it impossible to search for the process you need.

So, today I’ll show you how to standardize your processes by creating a documentation style guide which suits your needs. This guide can then be followed whenever anyone in your business needs to document a workflow.

It’s time to unify your company and cement your success.

Standardizing processes: how to create a documentation style guide When standardizing processes you need to create a documentation style guide which everyone can follow whenever they need to document a new process. To do this, you need to do six things: Meet with your team leaders to create a unified document Choose a centralized platform to store your processes Decide on a naming and tagging convention Settle on a consistent format Clarify universal language for the whole company Set requirements for every process Let’s tackle each of these in turn.

Meet with (at least) all of your team leaders First up, it’s vital that you consult your employees when creating this guide. They’re the ones using it after all, and without knowing how they currently document their processes and other information such as the language they use, you’re never going to be able to judge what the new standard should be.

The main goal here is to create a united guide which your entire company can follow to bring a high level of consistency to everything you do. As such, it only makes sense to gather members from as many different departments as possible.

Meeting with all of your employees at once, however, may not be plausible if your business has more than 10 or so workers in it. As such, you should instead meet up with all of your team leaders, which will give you the best of both worlds.

The other benefit of including your team leaders is that by letting them weigh in on the guide and help to shape it, you’ll have an important promoter of it in every team in your company. They will want it to succeed because they helped create it, and they have the power and personal connection to help cement it with the regular employees in each department.

So, arrange a time when you can all meet up, then work through the following points as a group to make sure that every section of your company is taking part in this consistent approach to your processes.

Select a centralized platform When creating a documentation style guide your first priority should be deciding what platform you’re going to use to document everything. Thankfully, this can be a pretty simple decision if you take the following into account: 2/9

It must be easy to use (for creating, editing, running and viewing processes) Processes must be easy to track There should be room for custom branding elements Everything should be centralized (stored outside your own facility) Variable permission levels are a bonus for small businesses, but a must-have for larger Most of these are easy to see the value in, but it’s worth going over the last two in a little more detail.

First, centralizing your processes. This means that rather than having a particular person or location for your processes which can only be accessed either through that person or location, you’re storing everything somewhere where anyone can access it at any time.

Variable permission levels play into this idea too, since not everyone will need access to everything (for example, you may have sensitive processes you want to protect). So, since your processes can be accessed from anywhere at any time you limit the permission of your users/team to make sure that they can only access the relevant items.

Unfortunately, traditional business process management methods such as Word and Excel all fail at one or more of these hurdles. Word is easy to use and can be centralized by using cloud storage, but is a nightmare for running and tracking your processes. Excel is better at giving an overview of your individual process instances, but it’s horrifically clunky for expanding on instructions for complicated steps.

Instead, try using Process Street.

3/9

Not only are we the best process documentation software around, but with Process Street everything you need to effectively standardize your processes can be achieved with next to no effort.

Individual checklists are automatically sorted, your process overviews automatically update, and you can fine-tune your permission levels to let even non-Process-Street-users access the checklists they need to run.

Decide on a naming convention Having a naming convention for your processes may seem a little trivial, but by setting one up you can make navigating your processes incredibly simple. Not only that, but you’ll also be giving realistic expectations of what each process will achieve and when it should be run.

There are three main factors to consider when creating a naming convention; your word order, ID system, and tagging system.

The word order used is pretty simple – you need to decide whether to name your processes using either a verb or noun first. For example, “create an invoice” has the verb first, whereas “invoice creation” starts with the noun.

Although the word order is largely down to you and your employees’ personal preferences, the general consensus is that using verb-first process names make everything easier to understand.

As for the ID system you use, this will largely depend on how you’re going to organize your processes, and thus what platform you decided to use. If using Process Street then there’s no need to have any ID element to your naming convention, since all processes can be sorted into folders relating to the various teams and then permissions limited so that nobody sees what they shouldn’t.

Otherwise, decide on a prefix for the various categories your processes will have. This may be a two or three letter code to indicate the team the process relates to, a number to identify the focus of the process (eg, 01 for internal, 02 for external), or a combination of letters and number which both relate to a specific notation.

4/9

Finally, your processes should also include a tagging system to make sure that they can be easily searched for.

Shared tags can also benefit your employees by giving formal categories to your processes, letting them search within a tag for processes related to their current situation.

Again, your tagging convention will largely depend on the documentation software you use, but if you’re using Process Street then each tag will display on your dashboard. This can be clicked to display all templates with that tag, letting you and your team easily navigate their process library.

Settle on a consistent format The formatting of your processes is the most visible sign of standardization, and as such must be uniform. This means laying out a set plan for: Basic design Task layout Text formatting Image formatting Color scheme Voice and tone Again, if you’re using Process Street then several of these aspects will be already taken care of, but you’ll still need to lay out the precise format of your task lists and contents.

For example, the tasks in your processes should only ever describe a single action so as to not overwhelm the reader. This also means that the satisfaction of completing a task comes more frequently, which in turn encourages them to perform the rest of the process.

5/9

Using images to engage the reader is all well and good, but when used too frequently they become a distraction. As such, you might want to consider limiting images to only those which demonstrate an instruction in the process.

Having a consistent voice and tone can also be great for onboarding new employees, since they will be both taught how to do their job and given a sense of the kind of attitude the company has, and what they should emulate in order to present a united from to those outside the company.

Define consistent language across all departments It’s only natural for teams to have their own cultures and practices – this comes naturally from working with the same group of people day in, day out. However, while they may understand each other, you need to make sure that their language is understood (and unified) with the rest of your company.

Think of it this way.

Let’s say that you have a new feature coming out which present a tab where the information from every process your run is gathered and sorted into one view. Your support team might call this “process summary”, while your content team could know it as “template overview”.

6/9

While they are working internally there’s little to no problem, since the rest of their team refers to the feature using the same language.

However, upon release your customers will be presented with an image of your company in organizational shambles. Your promotional content surrounding the launch will tell them “template overview” is out, but upon asking your support team they may have little to no idea what feature is being talking about.

To avoid situations like this, make sure that the language used in your processes is the same. If needed, dedicate an entire section of the documentation style guide to providing a glossary of how to refer to particular features, items, and concepts across your entire organization.

Remember that this list shouldn’t be static either – as more terms crop up either from product releases or feature expansions you should go back and expand the list to include your new terms.

Set requirements for every process Standardizing processes is as much about defining what your processes shouldn’t be. As in, they should not be created without a clear purpose and scope in mind.

So, beyond the general layout, style, and tone of your processes you should be using the guide to define what requirements should be met before documenting them in the first place.

As a rough outline, your requirements should be something like the following: Describe the process in a couple of words – couple this title with any naming conventions you’ve set out.

7/9

Define who is running your checklist – this must be one person, although tasks can be delegated to others too.

Note the singular goal of the process – to know what the process should be, you must know what it is trying to achieve.

Set out the scope of the process – every process must have a set start and end point.

State how often the process will be run – this will give you an idea of how useful it will be to document, and give a time frame for each checklist’s completion.

Make sure you’re only documenting a single process at a time – if a process contains steps that are not necessary to carry out every time it’s run, you’re probably trying to document two separate processes and need to break them apart.

Most of these elements are straight forward, but I’ll expand on the last one a little more, since this can get confusing no matter how many processes you’ve documented before.

Every process you standardize should be performed from start to finish every single time it’s run. While this sounds obvious, this means that if there are any steps that aren’t necessary to carry out every time the process is run, then you’re actually trying to document two distinct processes at once.

We’ve covered this topic before in our post on creating a process, but to summarize, think of the process for making a cup of coffee. While your first reaction might be to say “buy the beans, grind the beans, pour water onto the grinds” and so on, this is exactly the problem I’m talking about.

You don’t need to buy coffee beans every time you want a cup of coffee. Therefore, buying the beans is part of another process, and you shouldn’t include it in your documentation.

Try this pre-publish checklist for standardizing your processes If you’re thinking “I don’t have time to create my own style guide – I’ll document my processes first, then standardize them later”, then stop right there.

For one thing, you’ll never get around to standardizing your processes if you do that. The more you document, the more work it will be to go back and standardize all previous ones and create a documentation style guide for future reference. You may save time in the short-term, but you’re only messing up things for yourself in the future.

Plus, if you’re really convinced that you don’t have time (which, compared to what you’ll save, you do) to create your own guide, you can always use the free template below to cover the basics. Just copy it into your Process Street organization and edit the specifics to what suits your company’s style.

Make your documentation style guide highly accessible when standardizing processes Once you’ve got the core elements of your style guide agreed upon and documented, you need to make sure that the whole thing is easy to access. No matter what time of day, location, or seniority the person accessing it has, they need to be able to open your guide and find the information they need.

As such, you’ll want to share the guide with as many teams and in as many locations as possible. If you use Slack, make a link to the document a pinned resource at the top of your teams’ channels. If you run an onsite operation, print off a copy for each employee (or, at least the ones who will be creating your processes) and make sure the most recent version is fully distributed.

Whatever you do, just make sure that when your employees need to standardize processes, your documentation 8/9

style guide will be easy to find and simple to follow, no matter what team they’re on or what experience they have.

Remember – the way you conduct your business sets an example for your employees to follow. By making sure that all of your processes (which can be followed for almost any task that is performed) present a standardized, efficient front, you encourage your work force to do the same.

9/9