Category: Information Management

20 years ago today, part 8: Strap on your jetpacks

Posted by on in Information Governance, Information ManagementLeave a comment

This post is a continuation of a series of reminiscences and predictions on all things
information management, to celebrate 20 years of Metataxis. Let’s now look to the future…

Guessing what the future will hold is easy, guessing right is hard. What will IM look like twenty years from now? My first very unfashionable prediction is that whilst we will have fully AI-driven findability, metadata and folders will persist. They’ve been around for hundreds of years for good reason!

20 years ago today, part 2: The rise of hand-held devices

Posted by on in Company, Information ManagementLeave a comment

This post part of  a weekly series of reminiscences and predictions on all things information management, to celebrate 20 years of Metataxis.

The use of hand-held devices was picking up speed. The innovative Palm Pilot was the latest gadget for early adopters, once you learnt it’s quirky “shorthand” style input. There were a growing number of people using these devices (I had the lovely full-colour screen iPAQ – remember that?!). The ultimate conclusion of this trend being the now ubiquitous smartphone. A powerful computer in everyone’s pocket – we’ve come a long way.

It was 20 years ago today…

Posted by on in Company, Information Architecture, Information ManagementLeave a comment

Twenty years ago, a dot-com software development manager (me) and a publishing director (Judi Vernau) decided to form Metataxis. We both felt that this intriguing new discipline of “Information Architecture” was something that had promise for the future, and was something we could do well at given our backgrounds. 

Twenty years later we are still here with both Metataxis UK and Metataxis NZ. Along the way, Metataxis has had, and still has some fantastically talented individuals, who’ve delivered endless value to our clients in information architecture and information management. 

But enough of the self-congratulations! In a series of posts over the coming weeks, I’ll be looking back at how information management has changed over the last 20 years. I’ll even make some predictions about the next 20 years. Watch this space…

Get stuck in! A six part series on big bucket retention. Part six.

Posted by on in Information Governance, Information Management, Retention Management, Retention SchedulesLeave a comment

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:

  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

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.

Get stuck in! A six part series on big bucket retention. Part five.

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

Part five

Herding cats: Dealing with "just in case"

Herding skills

Growing up in New Zealand a television favourite of mine was a local version of A Man and his Dog which was named with typical kiwi literal-mindedness The Dog Show. When designing retention schedules I often think back to the steeliness of dogs named Zip and Jess as they stared down particularly toey sheep to nudge them into their pens. Just like the pens on A Man and his Dog, you have to gently, but firmly, guide your users towards the right retention management decisions.

The dreaded “just in case” argument

“Just in case” is the kind of phrase most records managers dread hearing from their stakeholders. There are many perfectly legitimate reasons users give for wanting to hold on to records for a certain period of time. There may be a law or regulation to be adhered to, rights that are protected, or business processes which require the records to be referred to. 

But then there is the more nebulous reasons people give for holding on to records – just in case something happens and I need them. Just in case what? Well just about anything. And that’s the problem. With enough imagination you can dream up any worst case scenario where an obscure old record saves the day.

Isolated incidents

And what is even worse is when there has been a freak occurrence where this exact thing has happened. Someone has managed to save your organisation a great deal of money or embarrassment with an email they’ve had in their mailbox for nine years.  

Take a deep breath, hold your nerve and have some of these questions ready when talking to someone who presents you with a “just in case” argument:

1. Check they understand triggers

Check first that they understand things won’t be disposed of before they’re triggered. “Just in case” may arise from a misunderstanding of triggers and a fear that you’re going to delete records out from under people while they still have a legitimate need for them.

2. Consider the personal data and data subject rights

What personal data is held in this record and can you reasonably argue this is a legitimate business need that outweighs data subject rights? Remind people that your organisation does have to meet data protection requirements which does not accept “just in case” as a reason for retention.

3. Measure the risk

Ask your stakeholders “What is the likelihood of the just in case scenario happening (again)?” and “What is the actual risk? i.e. what does it cost the organisation?”

As an example, I’ve had a stakeholder tell me that a record type had to be kept to prevent the organisation incurring costs from complaints process, only for it come out that the actual total cost was £24. What’s more the likelihood of the risky event recurring was very low. It had only happened once and this was more than six years ago.

Ask how often, how likely, and how much – applying a risk management evaluation to your retention requirements.

4. Get the full story on that “save the day” scenario

In the case where a record saved the day don’t be afraid to probe (in a neutral way) to get some more information about the full scenario. It’s quite possible you are not getting the full story. For example:

  • Did the record in question only help because it was a proxy for something else that should be retained but was too difficult to  find in a time-critical situation?
  • How long ago did this happen? Did it happen so long ago, things have moved on and it’s no longer relevant?
  • Was the person telling you this story involved enough to understand what actually happened? Could it even be an urban legend?

Helping people find more appropriate retention rules

These are just some of the ways you can begin to unpick the requirement to keep things just in case. Getting to the bottom of the underlying concerns that drive such a requirement can then help you to guide your stakeholder to more appropriate retention rules. 

It can often feel like herding cats, but with patience and understanding it’s a rewarding result once it’s done. All that’s left to do is implement. We’ll be looking at implementation in the final of this series next time. 

If you need some help talking to your stakeholders about records management, or are looking for general advice about information management, please do use the contact form on the right, or get in touch today info@metataxis.com.