Processes are a necessary evil, especially in business. There are a few reasons why:
1. Reduces recover time – For instance, if someone were to leave tomorrow, you can quickly get his/her replacement up to speed
2. It eliminates mistakes – Everyone is following the same process, so the number of errors that can occur decreases
3. There is accountability – You can always figure out who did what and when. You won’t get any of the “Not me” that can occur when there isn’t some level of transparency
When multiple people are handling the same documentation, you want to have a process in place. You want to ensure that everyone understands the process, what their roles are, and the inputs/outputs.
In documentation, these are the parts that you want to ensure are in your process if you want to have no issues.
Have a Central Repository
Collaboration tools, like Google Docs, Zoho, Sharepoint, etc., have made it easy for teams to have a central place where all of their documentation goes. The worst is when you are working on a document, and someone else is doing the same. You are left with not knowing who’s changes should be the final ones. You want to ensure that the tool you use for your documentation library has the functionality for users to check in/check out. You also want to ensure that there is some type of version control. Perfect example: I was working on a proposal with several people. I accidentally uploaded another document over that one. I didn’t sweat it though because I was able to retrieve the previous version (the true one).
Make Time for Reviews
It doesn’t matter what kind of document you are working on, you need to have someone else review it before the client sees it. I’ve said this before. When you have been working on something, those are your words, so your brain will automatically start filling in the gaps that you might have left. Someone else will be able to quickly pick those up because he/she is not that close to the document. When you are dealing with clients, reviews are a must, so make time for people to review your document (ensure they have track changes on) and send you the feedback.
Have Client Sign Off
There are exceptions like meeting minutes that don’t need a formal client sign-off. However, more often that not, you want the client to sign off on the document. Project management and requirements documentation are great examples. You want to ensure that you have somewhere the client signed it saying that he/she received it and agrees with the content. Later, if the client says, “Hey, I never approved this,” you can go back to the document and say, “I have right here that you signed off on such and such date.” I just had to do that today. The client signed off, went through the user acceptance testing, and then wanted to say that something was not right. I had proof that I could show my boss that said, “Yes, we have it right here.”
Don’t bypass a documentation process. Believe me, I have seen some teams who have done that, and it always ends up hurting them in the end.