Category: Information Governance

What’s involved in a SharePoint health check?

Posted by on in Information Architecture, Information Governance, SharePoint, Uncategorized
SharePoint Health Check

Many organisations think that Office 365/SharePoint deployment and configuration is both simple and quick only to find the reality quite different once the system is used in anger.  But a well-timed health check of SharePoint can save a lot a pain and stress down the road.

When to do a health check

A health check can be done at any stage of SharePoint implementation for many different purposes. For instance a health check may be done during a pilot or pathfinder exercise to check that the project is going in the right direction. Or the health check may be used for older implementations that may be experiencing issues for the purpose of root cause analysis.

It’s not just about the technology

The technical configuration of your Office 365/SharePoint system is important, but so too is how your information is organised within your implementation. Failing to understand your information management needs is often overlooked in Office 365/SharePoint deployments which can result in expensive, unusable, or even a failed system. We recommend any health check considers ongoing information management as well as the technical management.

What a health check should cover

With that in mind we recommend a SharePoint health check should consider both standard areas of functionality as well as information governance, management and strategies. The health check should consider the following aspects though depending on how SharePoint is configured may want more attention on some areas than others.

  • High-level Office 365 configuration
  • Site collection and site architecture
  • User permissions and user access model
  • Content types and columns
  • Term sets
  • Search configuration
  • Libraries, views and folder configuration
  • Navigation and high-level user interface
  • Usability and look and feel
  • Information governance and policies
  • Training and support
  • Culture and change management

Who should do the health check

Ideally a neutral third party should conduct a health check, so they can provide an independent and impartial assessment of the system. The third party may be a person or team within your organisation that has not been heavily involved in implementation. That internal resource would need to have the skills and expertise to complete a thorough health check. Alternatively external resource with the skills and experience may be contracted to do the work. The benefit of getting a health check from a skilled professional is assurance of quality of work as well as the ability to provide results quickly and accurately.

Metataxis SharePoint health checks

Metataxis can provide independent health check of your Microsoft 365 and/or SharePoint deployment to discover potential problems before they become actual problems. The Metataxis team has the unique skills and experience to bridge the world of technology and information management, to provide a unified and thorough analysis. Metataxis has a simple health check methodology that provides quick results. This is based on the many implementations we have worked on.

  • Analyse: A Metataxis consultant conducts an audit of your Office 365/SharePoint environment.
  • Document: The consultant documents their findings to produce an organisation specific set of recommendations.
  • Review: The consultant discusses the recommendations with the organisation, refining them as required.
  • Support: Follow-up advice is available via email or phone after the delivery of the recommendations.

We can scale any health check to the requirements of your organisation and point you in the right direction to give you the right information governance, architecture and strategy to help you on your way.  Get in touch with us today to talk using the contact form on the right.

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.

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

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

Part four

Beautiful and unique snowflakes: dealing with complex requirements

The struggle against complexity

Trying to keep your retention schedule 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 schedule will be your retention schedule stakeholders. People really do complicate things. Sometimes legitimately, sometimes not so much.

Valuing subject matter expertise…

Generally your stakeholders are the best people to talk to about how long records should be kept, especially for those record types whose retention is determined by business need 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 – that 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 will explain the, to their minds, dire consequences if incorrect retention is applied to the records they produce. You can trust stakeholder direction a lot of the time, 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’s a need to tread carefully. This is a challenging conversation 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.

Dealing with complex 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’s are some common concerns or misconceptions you can head off at the pass if you’re prepared for them. Here’s 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. Lack of understanding of evidential requirements and/or personal data requirements; or even
  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 look at the dreaded “just in case” requirement that often arises when having these conversations with stakeholders. 

If you want to know more about how to develop and manage retention schedules, or have any questions about records management, use the contact form on the right, or contact us via email info@metataxis.com.

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

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

Part Three

Big Buckets: It's not just about class

Not just about class

Organising your Retention Schedule into big buckets is not just 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 you should have at the back of your mind the following things that you want to nudge into a shape of your choosing:

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 choose 7 years as a retention period for records that need to be kept for a moderately long period of time. Try to  avoid having a  retention periods of 7 years, 8 years,  or 9 years. These will involve much more effort to implement.

Triggers

If you ask a stakeholder when the 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 when and how to mark something is closed. But we don’t need to know the exact detail of the process to execute retention.

Having more general triggers, say “end of programme/project” or “contract closure” can be really useful as they can be used in a number of different contexts. So try to have as few triggers as you can, and try to make them broad

Disposal authorisers

This is by far this most challenging aspect of any schedule, identifying an appropriate and reasonable number of people to be responsible for disposal review at the end of lifecycle for records. 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 really unlikely to be the same person. This is because, say,  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.

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, keep these as simple as possible. Delete or Archive may be sufficient for most organisations.

The question of what an archive is  whole other conversation. Some organisations will deposit to a national repository such as TNA, some will have their own in-house archive. Some 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

Now. 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.

If you want to talk to us at Metataxis about retention management get in touch using the contact form on the right or email us today info@metataxis.com.