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

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

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…

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.

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.