How do you start documentation? Prioritizing the processes to document

You've likely found this blog since you're aware of all the benefits of documenting your business processes, but you haven't managed to start this important habit yet.

Starting anything can be difficult!

Hopefully, the information and templates linked in this article help you start and gain momentum to regularly create and update your wikis, standard operating procedures (SOPs), how-to guides, or any other word you use for documentation.

As you learned in the previous article, one of the best times to start documentation is today!

In this article about where to start your documentation:

• Why is documentation so hard to start and to keep doing?

• Three common roadblocks to starting documentation

• Start small to overcome overwhelm

• Start where documentation will likely be adopted

• Start to get leadership buy-in for documentation

• Tools and frameworks to help prioritize where to start documentation

• Taking action: Prioritize where to start documentation 

This blog content is from the prioritization session of my live course and on-demand documentation courses.

Why is documentation so hard to start and to keep doing?

Here are some of the common answers to why starting documentation is hard.

• Starting can be the hardest part because of overcoming inertia and overwhelm
  • Even if you know all the benefits of documentation for your business or role
• There is SO much that can be documented in a business
• You're wondering if your time is worth it if you don’t have a change process yet, for when the documentation needs changes or updates
• You are afraid the entire responsibility will always be on you... if you start it, does that mean you have to create ALL the documentation FOREVER??? That can be a scary thought!
• Maybe you’re worried no one will adopt it, no one’s gonna use the documentation you spent time creating, so that can be discouraging
• Or you’re unsure if leadership will buy in, so will your effort be worth it if leaders don't champion it, hold people accountable, and allot time for their teams to do it?
• Documentation is also a new behavior that is not common or normal in most companies and it takes courage to go against the norms
• Since it is not a common practice at many companies, it’s not a skill or habit that is taught to anyone (until now 😉 )

There are lots of interconnected reasons! So don't feel ashamed if you haven't managed to start your documentation yet. It is hard to start!

Three common roadblocks to starting documentation

To simplify where to start your documentation journey, I have three suggestions based on three common roadblocks:

• overwhelm
• adoption
• leadership buy-in

Overview (The 'too long, didn't read' version of this article):

• For overwhelm – start small with one of your own tasks you repeat often
• For fear of other people not adopting documentation – start with a process, person, or team where it is the most likely to be adopted
• If you have a fear about not getting leadership support for teams to create and use documentation – start with documenting a process related to current business goals, ones that you can measure the before and after metrics, to show the improvement resulting from documenting the processes

Most importantly, don’t overthink it!

Start taking action.

If you’re not sure what your roadblock is, choose the start small option. Overwhelm is the most common roadblock and the 'start small' advice is what some of the frameworks are based on.

If you can find a process that meets more than one of these solution criteria on the right side of the above chart, then that is likely a great choice to start with.

Let’s talk more about each of these options to help you conquer your documentation procrastination.

Start small to overcome overwhelm

To overcome overwhelm and build your documentation muscles and habit, start by documenting a small task you do yourself, for this first document you create.

If you repeat the task or process often, you’ll have more chances to test and improve your documentation.

Start documenting with something YOU do and then work up to involving other people in creating documentation later on. Documenting a process or task you don’t do personally is not starting small, because you have to figure out how to gather that information about how to do the task, verify it, and more. There is a lot of uncertainty and herding cats (stakeholders) when documenting other people's processes, which can slow any momentum in your new habit-building. 

Where to start:

A few examples of starting small could be documenting:

• The steps to create a weekly meeting agenda
• Instructions for creating a weekly newsletter
• Steps for creating or communicating a weekly report

Where not to start: 

Do NOT start your documentation journey by documenting something long and complex such as a detailed explanation of

• The entire sales process
• Your complete customer journey
• Tax preparation

Starting with those processes could be tedious, frustrating, and may not give you the satisfaction of a small win to motivate you to continue your documentation journey.

If you'd like to read more about the benefits of starting small in general, check out these resources:

• The Habits of Successful People: They Start Small by Joel Gascoigne, CEO and co-founder at Buffer

• A quote by author Simon Sinek

• The Power of Small Wins by Teresa M. Amabile and Steven J. Kramer

• I’m Using These 3 Simple Steps to Actually Stick with Good Habits by James Clear, Author of Atomic Habits

Let’s move on to the next common roadblock to starting documentation.

Start where documentation will likely be adopted

If your main concern or roadblock to starting your documentation is being worried that your team won’t adopt and use the documentation, then choose a task or process of a team member who you think is most likely to use documentation.

Where to start

Examples of tasks or processes to start documenting, if adoption is your roadblock:

• Maybe one of your developers is likely to use and make documentation, so you start documenting tasks related to developers
  • Example: How to internally communicate a change in the product/website 
• You are training a new team member to do a process you’re very familiar with, perhaps delegating some of your own work to them 
  • This is a good choice because new team members are more likely to adopt new habits. They are already in a new work environment and learning how the job and company works. 
  • Related but not quite as easy: training current team members to do a new-to-them task or process may be a good choice as opposed to re-training them to do work they are already doing.
•  Processes people are struggling with completing successfully
  • They may be willing to try something new to succeed, such as using documentation, which is a new habit

Where not to start

If adoption of the documentation is your main roadblock to starting your documentation: DO NOT choose a process that you know a team or team member will resist. Don’t make your job harder for yourself.

Examples of where NOT to start:

• Sales processes that would affect the closing speed or other factors that sales reps may feel prevent them from attaining their quota
  • You’ll probably get a lot of pushback on any changes related to that type of work. Document these later.
• Processes for executives (other than yourself).
  • You'll likely get more pushback from executives who may think they already know the best way to do everything, and don’t want to be told what to do
• Processes people already dislike 
  • If people are dragging their feet to even complete the process, and complain about it a lot, then associating a new habit like documentation could make it harder to get them to use documentation in the long run
    • It could also paint a negative perception of documentation in their mind if they immediately associate it with tasks they dislike 
  • You’d be convincing them to do the process and also convincing them to use the documentation. That is extra work. 

If you'd like to read more about the team adoption in general, check out these resources:

• Benjamin Hinson-Ekong writes about How to Build a Culture of Documentation

• Levi Olmstead writes How to Drive Business Process Adoption (+Examples)

• Forbes writes 15 Tips To Help Executives Accelerate Tech Adoption In Their Businesses (you can replace the word 'tech' with 'documentation' and the advice applies) 

Moving on the the third and final suggestion of where to start your documentation…

Start to get leadership buy-in for documentation

If you are worried about getting leadership buying for taking the time to do or improve documentation, or getting managers and leaders to help convince other people to use or create documentation, then start with a small task/process, something you do or manage, that is related to a business goal and easy to measure improvement. 

You want to be the person in control of the measurement, the data collection, to make sure you get the information you need to prove that documenting the process helped get your company closer to its goals.

It will also be easier to show improvement if it is a task repeated often, so you can gather more data about the improvement.

Good criteria to choose a process to document for leadership buy-in:

• Something you do or manage
• Related to business or department goal
• Easy to measure
• You’re in charge of measuring, so you don’t have to ask another department like IT to have access to the data you need
• Task/process repeated often so you can show improvement over the times the process is completed

You might not be able to find a task or process that hits all those points, but aim for as many as you can.

Where to start

Examples of where to start your documentation if getting buy-in from leadership is your concern:

• Any tasks that could measure xx% fewer errors or take xx% less time, if your business goals relate to saving time or accuracy, or relate to customer experience improvement from those factors
  • If you and your team currently track time, you have an advantage here, if efficiency helps achieve your business goals 
  • A task takes xx% less time now that you/people aren’t searching around every system trying to remember what to do, or it takes less time now everyone who does it is using best practices and not forgetting steps
• Document how to do quality control checks to prevent errors
  • If you track errors, your measurement could be xx% fewer mistakes to fix after providing documentation
• Document how to write a better sales email for a particular stage, to measure stage conversion % increase
  • A lot of companies already track conversion between sales stages, so if this documentation is the only change to that part of the process, you could attribute any conversion rate change to having and using documentation

Where not to start

If getting buy-in from leadership is your main roadblock to starting your documentation: DO NOT start with documenting a process that is hard to measure or unrelated to your business goals.

Examples of where not to start:

• How to make a custom Slack emoji
• How to plan a company employee event (if unrelated to goals & you haven’t measured employee event satisfaction in the past to compare)

Consultants often advise starting documenting in this measurable impact category:

Adi Klevit, founder and CEO of Business Success Consulting Group, gave related advice in a documentation post for Trainual. Though unrelated to leadership buy-in, Adi suggested starting where documented processes would help most, such as the department with the most problems or the most negative customer feedback. It sounds similar to the advice above about starting with measurable business impact. I would agree with the advice, as long as you don't have any of the other roadblocks such as overwhelm or adoption concerns, otherwise it could be a lot of pressure on yourself to make your first document ever about a critical business process 'fire' you're urgently trying to put out. It could be tough to get it to a shareable 'finished' point, to motivate the adoption of it, and to gain momentum to continue documentation habits. This could be a situation where the advice depends on your role, company, and influence.

Layla Pomper at ProcessDriven recommends starting with a small process in pre-sales or post-sales, something near where the money comes into the business. Similar to the above, I would say this advice depends on if that is too much pressure on yourself to overcome overwhelm by starting with such an important process for your business. Though the "small" part of the process instructions in the video are helpful to overcome overwhelm, combining the "start small" advice. The advice also depends on if you are involved in pre-sales and post-sales since documenting other people's processes can be more difficult than documenting your own.

If you'd like to read more about gaining leadership buy-in in general, check out these resources:

• Caity Cronkhite discusses Making the Business Case for Documentation on a webinar for Good Words 
• Leadership Buy-in from The Book of Accessibility
• Steve Sonnenberg writes 5 Tips To Get Leadership Buy-In For HR Initiatives (though documentation should be a company-wide activity) 

Tools and frameworks to help prioritize where to start documentation

Some of the following frameworks are included in the free pre-work template in my documentation course, and some of them are available in the paid workbook or individual worksheets.

You can combine these methods to help you narrow down your list or get more clarity.

I have a suggested order to use these frameworks, but do what works best for you.

In general, I suggest starting documentation with your own processes/tasks to help you complete the first pieces more easily and gain momentum to continue the habit of documentation. That is what most of the frameworks and progression are assuming.

Task Tracking/Audit

Track the tasks or processes you complete in a week.

Write down a general description or name of each task each day.

Add any additional thoughts about the task, such as if it relates to a larger process, a problem you had with the task, or if you want to delegate this work to someone else. 

If you use project management and/or time-tracking software, you can pull this information from those systems

Brain Dump

The second step, or second tool, I suggest is a good old-fashioned brain dump.

Make a list of the ideas you might already have about which processes you want to document. The adoption and leadership buy-in suggested tasks/processes may fit into this exercise better than the task tracking exercise.

Scoring

After you have a list of potential documents, from task tracking and/or the brain dump, you can score the processes using criteria such as if they:

• Repeat often
• Are part of a larger process you want to improve
• Are related to delegating and training someone else
• Took longer to complete because you were uncertain how it should be done
• If many of the tasks tie into one larger process you can already identify

The ones with the most points, or most 'yes' answers, might be a good choice to start documenting first.

Eisenhower matrix

Another option for prioritization is an Eisenhower matrix, which categorizes urgent vs important. For this use, it means urgent to document or important to document.

This is a good choice to use if you don’t like that scoring method, or if it's not working for you, or if everything had similar scores.

Impact, Effort, Change Management Analysis

This final framework is not in the course workbook but it is in another class that I helped create and teach, the HubSpot Academy RevOps bootcamp.

It’s an analysis where you assign a low, medium, high score to each task or process you are considering, for each of these three components:

• Impact: business impact, will it affect the business’s overall goals if this is documented and more people are consistently trained on best practices?
• Effort: Will it be difficult to document, such as needing to consult with multiple team members or dig through multiple tools to figure out the process?
• Change management: will it be difficult to get people to use documentation for this particular process?

Tasks/processes with high impact, low effort, and low change management may be a good place to start documenting.

If you still need a tie-breaker after all these tools, it could be helpful to add a fourth component here of ‘urgency,' high, medium, or low.

Resources:

• Dan Silvestre describes 7 frameworks for prioritization

Taking action: Prioritize where to start documentation

 I hope I have armed you with enough advice, tactics, and tools to start your documentation!

Take some time today to identify and prioritize your first 10 processes/tasks to document.

I suggest also adding a note next to each one, reminding yourself WHY you put them in this particular order.

You can use the free resource below to get started.

This blog content is from the prioritization session of my live course and on-demand documentation courses.

See more of the course content in this comprehensive guide to business process documentation.