Compliance is so important that even those people such as myself who are not compliance people must to do what we can to help customers work toward this goal. Today, I will give you three documentation tips from the implementation side of the project.
Tip #1: Get the Right Mindset
Here is the wrong mindset about documentation for compliant systems: “I’ll let all the documentation get done at the end of the project. I won’t worry about it, now. If the people working on the project, such as consultants or my own people, don’t feel like doing it along the way and it interferes with their work, I’ll let that slide because they’ll come back to it in the end.”
Here is the right mindset about documentation for compliant systems: “Documentation doesn’t have to be perfect but we have to start it or people will forget what has to be documented and the volume of it will be overwhelming.”
Here’s what happens when you get soft at let people slide on documentation – they know you’re a pushover and then you’ll never get them to do it. If you’re the one procrastinating it, you’ll just never get it all done if you wait until the end. People come and go from the project and, in the end, it’s just not documented and it will probably never get the proper documentation that’s as good as it should be. Plus, as a compliance project, there needs to be yet extra time to verify and check this multitude of documentation.
Make people do it. If they whine about how it’s “not their job” then they aren’t meant to be on a compliance project. Sorry, but that’s the job we have to do and the compliance authorities won’t excuse just because we “don’t feel like doing it.”
When I hear customers say something like, “Well, we had our software vendor do all the work but we didn’t allocate money to document it and no-one here knows anything about how it was all done but, despite that, we’ve put our regulated system into production,” I want to cringe. While I understand there’s a lot of money involved, you’ve put yourself into an awkward position. This is certainly a minority position but it still indicates a lack of control over the project and, here in 2017, don’t we know enough about project management to exert control over them? Don’t we know that a regulated system is all about control?
Tip #2: Prioritize It
We often get so caught-up in providing new features that we let other things slide. Okay, and let’s be honest, we sometimes do absolutely nothing else. If you don’t think you have the time to do your documentation then you don’t have the time to keep providing features, either. You should go back, re-prioritize everything, and only finish the top features and commit to doing all the appropriate documentation for them. Another way to prioritize is to build the most popular or necessarily products into your system, first, which does drive some of the work that needs to be done.
Bottom Line: Don’t build what you can’t document and support. If you built every great feature into the system but it’s not compliant, it could get shut-down and, then it’s not really the greatest system, ever, it’s the most non-existent system, ever (because it doesn’t exist if it’s shut-down and unavailable).
And if you’re sitting there thinking, well, if we get our system shut-down and have to go back to paper, that’s kind of an okay fallback position, then there’s something wrong with the process. There’s a lack of commitment, or the wrong system was purchased or something. Taking such a casual attitude toward the system is a dark sign of something desperately wrong, somewhere.
Tip #3: Get Buyin
If your management and users aren’t giving you the support and time to create a compliant system, you need to work to get their buyin. If you can get management to agree to give you more time and money, users to give up more features and create more SOPs (Standard Operating Procedures) in their place, or a combination of both, that’s a start. Sometimes, they’ll come up with yet other helpful ideas. But if you don’t get them all on-board for this, you’ll likely fight an uphill battle.