Part six
Where the rubber hits the road: implementation
Retention implementation plan
During this series we’ve been looking at ways to simplify the retention schedule into bigger buckets. A retention schedule will usually take the form of a table which can then be applied to systems, and communicated to staff. The retention schedule may be supported by a written document, usually a retention policy or records policy which outlines governance, scope, roles, responsibilities, compliance expectations etc. The last piece of the puzzle is the implementation plan, which is the practical application of the retention schedule to records held in systems.
Document the practicalities
It’s inevitable when talking to stakeholders that they will flag up concerns about practical implementation of retention very early on. In fact they are likely to identify practical issues as reasons why longer retention periods should be applied to certain records. In an ideal world, these practical limitations should never dictate the retention period for a records class. Instead steps should be taken to improve the metadata, or improve the process so that new records can be managed appropriately and the legacy dealt with more strategically.
Adopt a risk-based approach
Because we work in complex environments it is necessary to have some kind of strategy to apply retention both to newly created records going forward and to records created in the past. This means having a good information architecture that supports retention management and a risk-based approach to the legacy records.
Leverage simple systems rules
This is just one element of planning for retention implementation. There are numerous practical considerations to take to get through the bulk of retention management. And yes, you guessed it, opportunities to lump things together in the implementation plan. For example, your retention schedule may have the following two rules:
- Financial management 7 years from end of financial year then delete
- Annual strategic planning 7 years from end of financial year then delete
The two classes stem from different functions, but require the same retention treatment. This means that a retention rule may be created in systems that says “delete content 7 years from end of financial year”. It will do the job for both classes, as long as disposal is done in line with the retention schedule (meaning also metadata is collected) it doesn’t matter what the technical mechanism. This is also helpful for more manual applications of retention where searches for eligible records are done for anything older than 7 years in relevant system areas for both functions.
Capture stakeholder intelligence
Finally, remember those tricky discussions with stakeholders where they provided masses of detail? An implementation plan is the perfect place to capture all that valuable intelligence. Not the retention schedule. Retention schedules need to be super-simple.
Avoid complex rules
While there’s some scope to have lots of detail in a description field to help users identify the right retention period for their records, there’s not much room for nuance in your actual schedule. The more “ifs”, “ors” and “except fors” you have in the schedule the more complex your retention rules will have to be. Complexity costs. And frankly even your users will get confused by a schedule with too many caveats. Save these up for the implementation plan – it will be valuable intelligence for dealing with those legacy issues.
And the plan is the thing that will make your retention schedule real!
So that’s the final entry of the series. I hope you have found it useful. If you want to know more about what implementation plans should look like or about retention in general, do get in touch using the contact form above or email info@metataxis.com.