It’s not all about class
Organising your retention schedules into big buckets is not about trying to create large all-encompassing retention classes. While this is of course a really important step, there are a number of other parts to your retention schedule that you will want to simplify. Simplifying all aspects of your Schedule reduces the number of factors, which in turn reduces complexity.
When talking to your stakeholders, the following could be considered to maintain simplicity for stakeholders:
If you can, try to corral your stakeholders to agree to a small number of retention period types in your schedule. There are common regulatory time periods that can help you choose which ones you want to use. For example: Financial records are usually kept for 7 years, as is the catch all retention mechanism the Limitation Act. So, try to nudge people towards choosing 7 years as a retention period for records that need to be kept for a moderately long period of time. Try to avoid having retention periods of 6 years, 8 years, or 9 years. These will involve much more effort to implement.
If you ask a stakeholder to define when a business process is over, they can be very specific. For example: “the Quality Review of the inspection process is completed once the B488 form has had its second review by the fourth-tier quality reviewer.”
When really, a trigger such as “end of quality review” would suffice.
Specific triggers like this will make your retention schedule very complex, and extremely difficult when you try to apply this to systems. We can trust that the people doing the work would know how and when to mark something is closed. But we do not need to know the exact detail of the process to execute retention.
Having more general triggers, such as “end of programme/project” or “contract closure” can be really useful as they can be used in a number of different contexts. So, we suggest you try to have as few triggers as you can, and make them as broad as possible.