Congratulations on starting your business process documentation! đđđ
Sometimes starting can be the hardest part of any big project or new behavior, and documentation is really a habit or behavior.
Now the next hardest part is⌠continuing the habit!
In order to help convince other people to use or be involved in documentation, youâll want to have a proven documentation system for yourself first. Youâre the beta tester to make sure this system works before adding other people into the system.
There are a few reasons why I recommend setting up your personal documentation system first.
So when you add other people into the system, they:
If you'd rather learn this material in a live course format, this blog content is from my documentation systems workshop and the full documentation course. Many of these topics are also included in this guide to documentation.
So letâs back up for a minute and talk about what I mean by 'system.'
A lot of readers may be in the tech industry and immediately think about software as the system...
What I mean by system is similar to the Oxford Dictionary's definition:
If you skip all this people & process system work and go straight into choosing a tool and expecting the tool to work miracles all by itself, that is likely to fail. I donât want you to fail!
Yes, it would be nice if a magic bullet tool did 100% of this work for you. One where you just buy it, and now there is a whole knowledge base of documentation that is automatically updated all the time...but weâre working with human behavior, so it's not realistic to think a tool can solve all the problems.
The major elements of a documentation system to set up BEFORE choosing a documentation storage tool are:
You'll want to first set up a system to help you avoid procrastination since documentation is rarely urgent, though itâs an ongoing activity that is important for its long-term benefits.
Start creating your systems by reserving time â making time to create, use, and improve documentation.
Think about:
A few ways you could reserve time for this work:
Having a system of reminders is very important. Don't just have this task sitting on your calendar or in your project management system, but think about how it is going to get in front of you to remind you to do it.
Some kind of popup or time-delayed notification could work well.
So youâve got the time reserved, and you have reminders to actually spend that time doing the work, yay!
But when you arrive at that time on that dayâŚyouâre overwhelmed and donât know what documentation tasks to work on.
You spend that whole time block trying to figure out what to do first.
Does that sound familiar?
To solve that problem:
A good example of being specific with tasks/time block:
âComplete the drafted document about creating a marketing email.â
(Add a link so youâre not searching for the draft.)
A bad example of a time block or task name:
âDocumentationâ â unless it links to your list of what to do next
Interlinking everything is a big part of creating a good system.
Make it easy to find what you need to work on, and spend less time searching around in all your tools.
Here is some advice on overcoming common roadblocks:
In the first session of my course, class members finish a top ten list of documentation to create or improve.
That will guide the documentation project management to prioritize what to work on first.
But what happens when youâve completed the first version for all the documents on your initial to-do list?
When you get to that point, here are three project management tactics I suggest using in your documentation system:
Every person and/or every company does project management differently, so think about how best to make these tactics work for you.
After you have your personal documentation project/time management system set up, and youâre feeling confident youâll actually keep doing the new and updating documentation, then itâs time to start getting into the habit of good communication about documentation.
This also is a start of your change management, getting people used to seeing you talk about documentation before you ask them to be involved in it.
Eventually, youâll have many interlinking methods of communicating about new or improved documentation.
But start small.
Pick one channel to start this communication while youâre building your own documentation system. Examples of channels could be a messaging system, a recurring email, or adding it into a live meeting that already occurs.
Test it and see what people respond to. Then expand.
What do I mean by communicating about documentation?
When you're focusing on your personal system, think about documentation communication as informing other people about what you are doing. The only action they may need to take is to read what you are sharing.
Here is an example:
âThe marketing email process document (link it) was updated with a new approval process. Marketing team members should review it and reply to me with questions.â
Which could be added to:
These were the three channels I used at my last job, but I didnât start using them all at once,
Choose one channel to start with.
Then one channel will always be the source of truth that youâll use to pull/copy and paste the information to put onto the other channels.
After testing one communication channel and getting into the communication habit, when you start involving more people in your system, it will be very important to repeat the information/communication in several places.
So if we're using the three channels that were on the last slide, we'd be using Slack in real time to first send the communication, then copying that information into a newsletter, and into a meeting agenda.
Itâs not realistic for people to remember something they were told once in one format.
Announcing that you finished a piece of documentation one time is not going to help people remember it exists.
There is a rule of 7 in marketing which explains that people need to hear or see things 7 times to start to remember them. Seven is a lot, but three times can be manageable for each piece of documentation news.
This is also important since not everyone on your team is going to pay the most attention to the same channel or the same method of communication - verbal, written, etc.
It may be annoying for you, as the announcer, to repeat yourself. But eventually, other people will be doing the documentation communicating, too. You may not be the one doing all the communicating yourself forever.
But remember -- Poor communication about documentation is a big reason why people donât use it. They simply donât remember it exists.
This tool topic was probably what many of you were waiting for, because this is the 'system' most people think about when they see a mention of a documentation system.
But remember that the tool will not be very useful without doing the people & process work to make it useful â such as setting up your time accountability & communication methods!
So once youâve figured out when to do it, what to do, how to communication about it...
Now where are you going to put the documentation? What tool will you use?
In that first stage of creating your version 1.0 documentation, use the tool easiest for you.
The habit is more important than the tool, especially in the early stages.
Though you can hire someone later to migrate your documentation from one system to another, or delegate that task to someone on your team later on, it is very difficult to hire someone to write your processes for you. I would be very hard for someone to extract that information from your brain.
Write version 1 first.
Don't spend weeks researching documentation tools when it's a better use of time to spend those weeks completing your version 1.0 of documentation in whatever tool is easiest for you, a tool you have now. Though tool research can be much more fun (and distracting) than doing the documentation! đ
Once you're finished with your first version of writing your top-priority documentation, using the tool that was easiest for you to get started writing, then you will start to think about a tool easiest for your team to use. This may or may not be different than the tool youâre currently using for yourself.
My #1 tip is to use a tool your team is already using daily so you don't have to teach them a new tool IN ADDITION to teaching them new habits about creating, using, and updating documentation.
This is my top tip because new tool adoption is hard, even when people are using one tool to replace another tool that does the same work (in a different way or different UI). For an example of replacing a tool to do the same work, in a Salesforce to HubSpot migration, your work isnât fundamentally changing, but the way you do the work within the tool is changing.
So unlike simply migrating tools for your team's current work, documentation may be an entirely new area of work or new habit, especially for the people responsible for creating and editing it.
Building new habits is hard.
It is extra difficult if youâre adding tool adoption on top of that new habit.
We want to make documentation as easy as possible to get other people to use, create, and update it, so using a current tool is a great place to start creating those habits!
But what do I mean by a tool your team is already using?
You may be thinking, "My team isn't using documentation, thatâs why I am reading this blog!"
When thinking of what current tool to use, consider:
Here are a few factors to consider, especially if you DO have to choose a new tool,
Does the documentation tool have the ability to:
Here are a few tools you can look into when youâre ready. (Remember, this is not step 1 of building a system!)
Keep in mind that screenshots, videos, and other media may also need a file storage location & strategy.
Google Docs is an easy place to start documentation, but in order to have the individual documents not feel so lost and floaty, it requires setting up a good drive/folder navigation system and onboarding/training the team about using folder navigation instead of searching the whole drive in the search bar...and that takes work and habit building.
You can also make it a practice to link those Google documents or folders into other places the team members would be looking first, like pinning them in Slack channels or linking them in a project management task template for a related task.
Keep that bigger 'system"' thinking in mind, linking everything together so people can easily find it when they need it, in the place they are looking for it.
Eventually, you may want to consider Wiki tools like Notion, Guru, or another knowledge base,
Knowledge bases are nice since you can refer to documentation as a 'wiki' which is easier and friendly language, and it may be easier to find information compared to using documents in a Drive, You'll also have more formatting choices and potential integrations with Slack or another 'home base' tool.
Start documenting what you will use for your documentation system:
In my classes, I have a template that helps document these decisions, which you can also purchase separately in this documentation systems workbook if you wish.
Good luck in starting your documentation system!
Next: Learn how to add other people to your system.