In the big world of Records Management, everyone has some key piece of knowledge to bring to the table. Some people are remarkable at developing a strategy to roll out new technology; others easily learn and become experts with the software and tools used in the field; while others have a deep understanding of the principals of Records and Information Management. However, regardless of their knowledge and skill level, everyone also has something new to learn. While assisting people with implementing their Records Management program in SharePoint, the following are two myths that seem to frequently come up.
Myth #1: One Size Fits All
This myth may seem obvious, but it should be spelled out quite clearly when discussing records and information management. Too often organizations will fall into this trap without realizing that they are even doing so. I’ll use a specific example, and then you can generalize from there.
Consider one of the building blocks of Records Management: Retention Schedules. Retention Schedules are essentially there to tell an organization when they can destroy their Records. The question here is “Where do these Retention Schedules come from?” Normally, someone who knows a little bit about Records Management will say “It comes from the law,” and this would be true, for the most part.
Financial Records, such as our T4 or an organization’s payroll information, must be kept for 6 years following the end of the tax year (at least here in Canada). This is generally understood as a legal requirement, and is used as the Retention Schedule for all Financial Records. That’s totally fair, and it is not wrong to rely purely on the legal requirements of Records Management to determine Retention Schedules.
But this is not the only way to build a Retention Schedule. Too often, people forget that Retention Schedules are an amalgamation of three key components: the legal requirements, the historical requirements, and the business requirements.
We’ve already discussed legal requirements, but what is an organization to do when there are no legal requirements? Great question! We must turn to the other two. The historical requirements are actually very simple. Is it something that society would like to remember? If so, then send it to an Archives when you think it’s ready to go. Or, if that is too much trouble, keep it yourself, as a “Permanent” record (Permanent is the most dubious concept in Records Management, but here, treat it as “Life of the Company”). It’s the only third requirement that is really tough: the business requirements.
"What works for one organization will invariably not work for another… organizations engage in different activities,  have different processes and different corporate cultures."
Here’s where organizations most often get tripped up. There is often a fear around Records and the Consequences of Destruction. How many times have I (woefully) heard the same excuse: “Well, we aren’t quite destroying our Records just yet. People are afraid.” This is a systemic problem in the Records Management community; and it stems from a lack of knowledge around the business requirements of a Record. Long after the legal requirements have passed, people tend to cling to Records. When asked why, they respond “What if I need to reference it in the future?” They aren’t sure of the business value the Record has, and they are afraid that they will lose that value if they destroy it too soon.
To compound this anxiety, people are fearful that they will make a mistake when determining a Retention Schedule.
This double-sided fear creates a sense of unease within the community, and we will often see one Records Manager turn to another to ask, “How long do you keep <whatever> Records for? 20 years? That sounds good to me! We will do that, too!” We now have the perfect storm of poor Records Management. This belief that ‘one size fits all,’ and ‘whatever everyone else is doing must be right so we will do it too,’ is counter to the entire purpose of Records Management.
The purpose of Records Management is not only to care for Records during their Lifecycle, but also to ensure their prompt destruction at the end of the Lifecycle.
To counter this myth, I must urge everyone in the community to look more closely at your own organization. The purpose of gathering business requirements is to determine how long your organization needs to keep Records. Every organization is different - this cannot be repeated enough. What works for one organization will invariably not work for another. Not only do organizations engage in different activities, they also have different processes and different corporate cultures.
Perhaps a brief two-year Retention works perfectly for your users – it may not work for another organization, because the users tend to use their records longer or are less willing to destroy them. Whatever happens to work for your users, document it as The Retention Schedule for Your Organization, get it signed by the general manager and then (this is most important part!) follow it. With that, you are fulfilling your Records Management duties (congrats!). In many situations where there are no clear legal guidelines, in the eyes of the law, as long as you have clearly defined your Records Management process and are following it, then you are effective.
Myth #2: We Only Need to Manage “Records”
Whether it be municipal government, medium-sized non-profit organization, or a corporate behemoth: there’s a common belief that organizations only need to care about the “records.”
As such, my favorite rebuttal is: everything is a record.
Here are the two main reasons for my stance:
- It cuts through the ever-troublesome question of “what is a record?” This can help basic users as well as those in the information governance sphere
- It creates a shift in perspective that allows us to talk about information governance rather than just “records” management
Why is the first question, “what is a record?” so troubling? The answer is simple- it scares end users. End users will always be afraid of “Declaring” documents as “Records” because these are big concepts that are very loaded. If we instead tell the users that “everything you create is a record,” there may still be some fear, but now we have reduced the amount of questions they have to ask. No longer will end users be paralyzed by fear when they ponder the question “Am I creating a Record?” Much of the fear is around the unknown aspect of this word “Record” and what it means.
It can also help crystallize the purpose of Records Management, which I have tied closely with Information Governance. Since everything is a Record, everything has to be dealt with one way or the other.
Now, one of the major misunderstandings of this concept of a “Record” is that it needs to be kept, in some cases forever, but in other cases for at least a number of years. This is not true. Many records can be destroyed very quickly; in some cases, immediately! I like to call these “Transitory Records”. Some organizations and people use the term Convenience Files, but I dislike this term for two reasons. First, it doesn’t have the word Record in it, and makes people think they are less important, and second, Convenience Files usually imply duplicates of records created by different working groups. When we call something a “Transitory Record,” it gives it power and helps people understand that it’s very important to ensure that Records are kept as long as required by law. It’s also very important that Transitory Records are destroyed as soon as possible, otherwise they wouldn’t be transitory.
"Once we’ve fixed up this entire business process and built in some automated and manual processes to ensure that Transitory Records are being dealt with properly, we can finally have some decent Information Governance."
So, let’s stick with the term Transitory Records. Here’s where we get to the Information Governance part of things. The main theme of these items is in the first word: “Transitory.” As in, get it out of here once it’s done. This should be the focus of two separate pieces of the Information Governance attack. First, the Retention Schedule (because indeed, these Records must have a Retention Schedule) should be “Obsolete + 0 days”, or maybe + 30 days if you’re feeling really generous. The point remains; let’s get rid of them as soon as they are no longer needed!
The second focus is determining at which point these Transitory Records have used up their purpose and are outdated (more specifically, what is the “Obsolete” event). Now of course, as I said in the previous section, every organization and every type of document that is created will have different requirements. However, no matter what, you should be able to figure out a Transitory Record’s obsolescence point if you simply examine the business process that creates it. Now we get to dig into the business process around these Transitory Records, which is fantastic! Not only do we have an opportunity to better understand these records and create the ideal retention schedule for them, but we also have an opportunity to optimize the business process itself.
Once we’ve fixed up this entire business process and built in some automated and manual processes to ensure that Transitory Records are being dealt with properly, we can finally have some decent Information Governance. One of the central problems of modern business is too much bad information getting in the way of the good information. Ensuring that Transitory Records are dealt with properly is a big step towards having superior information.
I’ve argued in favor of the approach that “everything is a record,” but I will share one final point to put the argument to rest. In the modern world where the media (and others) can freely request certain types of information through freedom of information requests, it is important to remember that the media and the general public make zero distinction between “non-records” and “records” when it comes to a good story. Since the general public doesn’t know the difference between an approved project outline and a draft of a project that never came to fruition, but could have cost “$50 million taxpayer dollars,” then we as records and information managers shouldn’t know the difference either.
Voila! Those are my two favorite records management myths to discuss with the community. Hopefully this will be useful in crystallizing some ideas you’ve had kicking around for a little while, and maybe give you the inspiration to finally clean some things up!
Do you have more questions about Records Management? Feel free to contact our RM and SharePoint experts, or sign up for a free demo of our solutions to find out how we have helped streamline and simplify end-to-end RM for organizations.
Bonus! To check the health of your current Records Management program, and learn about the Top 9 RM Pitfalls and how to avoid them, download our free brochure: