Tag: records management

How to implement retention schedules

Posted by on in Records Management, Retention Management, Retention Schedules

Where the rubber hits the road: Implementation

In her latest blog series, Siobhan King, Senior Consultant at Metataxis, addresses the value of big bucket data retention and how to ensure complex records management requirements are accommodated.

Here’s part 6 – the final blog in the series, where she looks at how to successfully implement your retention schedules into the organisation.

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, and this will outline the 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 the records held in your systems.

Document the practicalities

It’s inevitable when talking to stakeholders that they will flag up concerns about the implementation of records retention policies 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 to improve processes, so that new records can be managed appropriately, and legacy records 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 to both newly created records going forward as well as older 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.

big bucket data

Leverage simple systems rules

This is just one element of planning for retention schedules implementation. There are numerous practical considerations that can be taken in order 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:

  1. Financial management – 7 years from end of financial year then delete
  2. Annual strategic planning – 7 years from end of financial year then delete

These two classes stem from different functions but require the same retention treatment. This means that a retention rule may be created in systems that states: “delete content 7 years from end of financial year”. It will do the job for both classes and if disposal is done in line with the retention schedule (meaning metadata also 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 for your retention schedules

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 be. Complexity costs. And your users will get confused by a schedule with too many caveats. Save these 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 would like to learn more about practical data retention and records management, simply contact us.

How to avoid complex retention requirements

Posted by on in Information Management, Records Management, Retention Management, Retention Schedules

The struggle against complexity

Trying to keep your retention schedules simple is an ongoing battle against the forces of complexity. And one of the major things that will hinder your plans to simplify your retention requirements will be your retention schedule stakeholders. People really do like to complicate things. Sometimes legitimately, sometimes not so much.

In her latest blog series, Siobhan King, Senior Consultant at Metataxis, reveals ways to ensure complex records management and retention requirements are accommodated.

Here’s part 4:

Valuing subject matter expertise…

Generally, your stakeholders are the best people to talk to regarding how long records should be kept, especially for those record types whose retention is determined by business needs over legal or regulatory requirements. Stakeholders are a great source of information about how the business works and what records are produced. But their insights shouldn’t be taken as law when it comes to the retention schedule. Stakeholders are not records managers and do not have the expertise to classify and manage records – this is where we add value. 

…and records management

When consulting with your organisation on the retention schedule, you will encounter users who are keen to press upon you the vital importance of their records. They are likely to explain the dire consequences that will occur if incorrect retention is applied to the records they produce. You can trust stakeholder direction a lot of the time, as they will often identify those exceptional record types that need to be kept longer because their early destruction will significantly impact the organisation. But occasionally, people make distinctions that don’t really matter from a retention management perspective.

Challenging conversations about values

When responding to the above concerns, there is, of course, a need to tread carefully. These can be challenging conversations to have. No one will respond well to the argument that they are not beautiful and unique snowflakes. Everyone needs to know that their contribution to an organisation is important. But the difference is that the retention value you place on the outputs of the activity is not a reflection of the value of the activity to the organisation.

challenging retention requirements

Dealing with complex retention requests

For some, simply acknowledging the complexity of business functions and activities is enough. This can be done verbally or incorporated into documentation. Appropriate places to capture this knowledge might be Retention Schedule class descriptions, Information Asset Registers, user guides or retention implementation plans. 

Some things you can counteract, some you have to accept. There are some common concerns or misconceptions you can head off at the pass if you’re prepared for them. Here is a list of some common issues I have encountered:

  1. Over-retention of records arising from poor internal processes which need to be amended
  2. Concerns about technical or practical application of retention, for example where records have insufficient metadata
  3. An over-estimation of the importance of their function and the records they produce within the organisation as a whole
  4. A lack of understanding of evidential requirements and/or personal data requirements
  5. Belief that retention will prevent uncommon or unlikely events which would cause problems for the organisation 

A matter of perspective

The small differences that people see in their work are important to ensure the job is done well. However, it’s not always important from a retention perspective, your job is to weight user expectations within the broader context for the organisation so you can create a simpler retention schedule.

Next time, we’ll look at the dreaded “just in case” requirement that often arises when having these conversations with stakeholders. 

Retention management can be challenging. Here at Metataxis, we’ve helped many organisations address these challenges. If you would like to learn more about practical data retention and records management, simply contact us.

Retention schedules made simple

Posted by on in Information Management, Retention Management, Retention Schedules

Simplifying retention schedules for your big bucket data

In her latest blog series, Siobhan King, Senior Consultant at Metataxis, addresses the value of big bucket data retention and shares some ideas how to simplify your retention schedules to minimise complexities across your organisation.

Here’s part 3:

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:

Retention periods

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.

Triggers

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.

Disposal authorisers

Identifying an appropriate and reasonable number of people to be responsible for disposal review at the end of lifecycle for records is by far this most challenging aspect of any data retention schedule.

The challenge arises from needing someone with a sufficiently senior role to make a decision, while being operational enough to understand the content of the records to be disposed of.

Unless your organisation is really small, this is unlikely to be the same person. This is because, for example, the head of HR is concerned with governance and strategy and not likely to know the operational ins and outs of say, recruitment campaigns and applicants.

retention schedules disposal authorisers

Traditionally, this has meant that there is some form of delegation of decision making to the subject matter experts. Or conversely, some sign off of decisions are made by the head of department. This is a frustratingly difficult aspect of a retention schedule to simplify. Setting up workflows to incorporate a lot of people is really difficult and costly, so it is important to try to keep the number of authorisers low – even though this is challenging.

Disposal actions

As with the above, we recommend keeping these as simple as possible. Delete or archive may be sufficient for most organisations.

The question “what is an archive?” is a whole other conversation. Some organisations will deposit data to a national repository such as TNA, some will have their own in-house archive. Others will have records that have long-term value and need to be kept permanently even if the organisation does not have an archive.

Minimisation leads to simplification

When your retention periods, triggers, actions and authorisers are simplified, something beautiful happens. With a smaller number of factors in play, it makes it much easier to lump record types into much larger retention classes. This makes big bucket retention that much more possible! 

So don’t just go straight for classes when simplifying your Schedule. Think about minimising all the moving parts as well. It will make things much easier in the long run.

Next time, I will talk about dealing with the complexity that people will inevitably want to introduce to your schedule and how to deal with “snowflake” requests.

Retention management can be challenging. Here at Metataxis, we’ve helped many organisations address these challenges. If you would like to learn more about practical data retention and records management, simply contact us.

Demystifying data retention

Posted by on in Information Management, Retention Management

Simplifying data retention for your stakeholders

In her latest blog series, Siobhan King, Senior Consultant at Metataxis, addresses the value of big bucket data retention and shares some top tips how to make it easier for your colleagues to understand.

Here’s part 2:

A lesson in transparency

Early in my career, a project manager who I worked with on a retention project said she found me to be “mercurial” when it came to advising stakeholders on retention. Flattering as it was to be referred to as “the oracle” on data retention, I was rather mortified to learn I was seen as something akin to a cold and unpredictable power dispensing mystical advice.

Over the next few months I introduced greater transparency to my approach, explaining why I was making the recommendations I made. Three months later, the same colleague proudly told me she could always pick what sort of advice I would give users and even felt confident giving advice on retention herself. Result!

Demystifying retention is really important to our colleagues and stakeholders. Demystifying how we arrive at the retention periods we advise for our users is probably one of the biggest things you can do to make retention much more approachable.

Here are some tips to make your process for retention management much easier for colleagues to understand:

Explain the different drivers for retention

Explain to your colleagues that retention schedules are shaped both by what the law requires and what the business requires. This may be disappointing news to some stakeholders who would prefer a hard and fast answer on how long things should be kept encoded in law. But business value is the biggest conversation to have with stakeholders. If people understand the basic principle of assigning a business value up front, the rest of the conversation will got a lot easier.

Talk to stakeholders about their business processes

One of stakeholders’ top concerns regarding retention management is that retention rules mean records will be deleted before the end of a business process. Projects are a classic example of this. Stakeholders might see a retention period of, say 6 years, and fear that records related to projects that run for decades will be deleted before the project has ended. This is the perfect opportunity to put stakeholders straight about retention triggers and the need to identify when the business process ends. This can be followed up with a discussion about how long records are needed after the business process ends.

Balance organisational interests with data subject rights

If stakeholders are managing personal data, they may already be aware that they need to manage this in line with GDPR.  This stakeholder group is probably the most frustrated to learn that the GDPR doesn’t tell us exactly how long we can keep personal data, but uses slightly evasive legal terms like “legitimate purpose” and “reasonable” which can be somewhat subjective. 

Sometimes, you may have to tell stakeholders that the period of time they propose to keep personal data is unreasonable e.g. 20 years for former customers. It may be unreasonable because they can’t point to a legitimate business reason to keep things that long, because it’s a real outlier in terms of industry practice, or because if you asked the person on the street what they thought of the retention practices they might find it unacceptable.

Conversely, sometimes you need to reassure a stakeholder that it is perfectly acceptable to retain certain types of personal data for a long time because it protects the rights of the organisation, and more importantly, it protects the rights of the data subjects themselves (for example, records which provide proof of ownership, benefits conferred or qualifications conferred).

Data retention can be challenging. Here at Metataxis, we’ve helped many organisations address these challenges. If you would like to learn more about practical data retention and records management, simply contact us.

Big bucket data retention

Posted by on in Information Management, Retention Management

Like it or lump it. Classification for big bucket data retention

In her latest blog series, Siobhan King, Senior Consultant at Metataxis, addresses the value of big bucket data retention and how to ensure complex records management requirements are accommodated.

Here’s part 1:

The difference between splitters and lumpers

Two people look up at the sky and see a plane: The first person points up and says: “Look! It’s a jet plane”. The second person responds: “Well actually, it’s a Boeing 737-900ER.”

Both are correct.
The first person is someone who defines things in broad categories, a lumper.
The second person is someone who defines things in smaller categories, a splitter.

Referring to people as ‘splitters’ or ‘lumpers’ is common in biological sciences, particularly evolutionary science where the classification of species depends on the importance placed on minor differences between individual animals. In the fossil record, this has led to some traps for splitters, who have created numerous hominid classifications where we might be looking at differences in size, age, gender, and health within a single species. Whereas lumpers are criticised for accepting too many variations and therefore lumping different species within one category, as in the case of Homo habilis.

Classification for records management

This kind of problem in classification is not, however, just the preserve of the sciences. It is something most records managers must consider when devising a retention schedule. Especially if they are aiming for “big bucket retention” for their schedule. On the face of it, you might think that big bucket retention would lend itself well to those who are better at lumping categories of records together. But creating meaningful large categories requires a good understanding of the details that dictate which small differences are significant and which ones are not.

Learning to be lumpers

Records management as a profession tends to attract people who like detail. You’d think this means our work requires us to be splitters. But the nature of our work increasingly requires us to be lumpers, as the scale of records management means we cannot practically apply retention rules and business classifications at such a granular level. This does mean that we, as a profession, tend to create schedules that are more complex. The very ambition of having a simple, big bucket schedule in our complex working environment is a bold one.

Compromise between simplicity and complexity

In the end, it’s a constant process of compromise between the need for simplification and the need to ensure more complex records management requirements are accommodated.

Lumping records into “big buckets” does not mean we ignore the detail. In fact, the detail must be understood to help us determine which records can be classed separately, and which can be safely lumped together.

This all sounds very challenging to do correctly, especially once you start to involve stakeholder who always make things complicated!  To provide some advice, I’ve reflected on the years of experience writing and implementing retention schedules and I hope you’ll find these posts a much more practical approach to the real-world issues you will encounter while creating or re-creating your retention schedule.

Of course, if you have any questions about practical retention and records management, simply contact us.