This is one of the posts in a Document It series. The idea of the series is to look at documenting as part of the way of working in church life. In this post we’ve established the importance. Among other reasons, we determined that documenting alleviates a single point of failure. This post addressed some myths of documenting, which often stop people from doing so. It is only logical that we look at best-documenting practices.
I’ll admit upfront: this list is not exhaustive, but I hope it’ll be helpful for you and your team. Church life needn’t suffer for no good reason. So, best practices are about standardizing how you document.
Let me start with the most obvious. You must document. The best practice is to have some documentation for what you do and why. Make documentation a requirement for all teams and functions. Of course, this should be within reason. No need to go extreme. This could be subject to discussion.
In case you haven’t read the post of why it’s important to document, read it here.
Good developers have great update notes. When there are changes in your way of working, follow suit by updating your documentation. Often undocumented changes can break systems and workflows. Update your documentation at regular intervals / as and when needed.
Set reminders or calendar items to check if documentation is still relevant. Test the quality of your documentation as you train new people. Part of training could be to get them to draw up a draft update to your existing documentation.
Log — Dates and People and…?
This relates to updating your documentation. When you update manuals or tutorials etc, make sure you state the date and name of the person who updated.
At a glance, you can tell when the most recent updates who made the last update when. This is about assessing the relevance and, where necessary who to go to for clarification.
You might want to think of other similar or important things to track for your church.
Avoid miscommunication by using standardized definitions. Often miscommunications happen because people use the same terms in different ways. While this may sound complex, it isn’t. A glossary is a list of terms used and what you mean by them in the context of your documentation. You might not have it from the start. Sometimes it is something you build and refine over time. That is, as others engage your documentation, you can update it.
Explain key terms and phrases to minimize miscommunication.
Any documentation, even great documentation, is useless if it’s inaccessible or unavailable. Make sure that members of your team know where to find documentation when it matters. Is it a cupboard, filing cabinet, in the cloud?
One of the best documenting practices is ensuring manuals are available when needed.
Greek Or Not
Unless you’re Greek and documenting for a Greek audience, don’t use Greek. If you do use Greek don’t complicate things. As matter of fact, this applies to everyone. As you create your guides and other resources, make use plain, straightforward language.
Develop a standard approach. An outline reflected in a contents page can be a great example. For instance:
- Introduction – what is the documentation for and what does it cover.
- Glossary – as mentioned above.
- On and Off
- How To Operate
- Other Details
The above might be far from ideal, but I hope the illustration gets you thinking.
Over To You
Do you have any best documenting practices to share?
What are some of the things you hope to find with good documentation?