We are a local authority in the UK and will shortly be moving from SP 2010 and file shares and replacing them with an O365 and SP environment and would appreciate any advice on how best to draw up our Information Architecture, specifically a sharepoint file plan.
I think there are three things in your message. First, how to create the information architecture. I’ve got a course up in Pluralsight’s library titled The Art and Practice of Information Architecture that might be helpful. It’s at The Art and Practice of Information Architecture
Pluralsight remove preview
The Art and Practice of Information Architecture
This course covers techniques and tools for the development of a coherent information architecture, including the development of taxonomies and implementation of navigation. View this on Pluralsight >
If you don’t have a subscription you can sign up for a trial and get access to it.
The second question is the creation of a file plan for SharePoint, here I think there are two parts. The first part is just creating a file plan — which is based on the business requirements. There I don’t have much help. The other side is how to implement that in SharePoint, for that I finished a course for AIIM last year titled Implementing Information Management on SharePoint and Office 365
Aiim remove preview
Implementing Information Management on SharePoint and Office 365
In this interactive training course, you will learn best practices for managing information in Microsoft SharePoint and Office 365.
View this on Aiim >
It covers setting up information management on the platform — including records management.
I’m happy to answer any questions that you have.
Thor Projects LLC
As far as theIA, at a macro level, there are 2 parts:
. IA for Document Management (DM) – which needs to be based around how your business areas think about and use content. I advise clients starting this journey that the first, and highest level, decision point is whether to base the IA for DM around their org chart/dep’t hierarchy or to create a function-based structure which is cross-departmental and ‘flat-er’. Note that using a function-based IA has many, many long term benefits (low change frequency, highly aligned to the reality of how things happen, etc.), however, it also invokes the greatest change management, training, and governance overhead because it is different than how we all have been trained over many years to think about our organizations. Work with your business communities and map out how each of them ACTUALLY use and think about content and you should be on your way to better productivity and user adoption!
. IA for Records Management (RM) – which has to be focused around the 2 prime concerns for RM – retention and compliance. This IA relates to the portion of your question about file plan (a typically RM-centric term). This needs to be based around the groupings of your content that you need to retain for compliance purposes and business retention. Thinking of this in technology agnostic terms, this does not have to be the same as your DM IA. That said, due to limitations in how SP out of the boxinstantiates IA through the mixture of your logical hierarchy of site collections, sites, pages, libraries/lists, content types, and metadata, the more you are able to align your IA for DM to your IA for RM the easier your overall task will be. However, there are a number of 3rd party addons for SP/SPO that change this dynamic such as Collabware, AvePoint, Gimmal, etc. that provide a separation between RM and DM not present in out of the box SP/SPO. If you really want to do RM well, I highly recommend looking into acquiring one of these solutions.
Need to add one other candidate to the “SharePoint Extension” list: RecordPoint.
The courses mentioned are a great place to start.
I would recommend you build usable taxonomy when and where possible then encourage a culture of tagging content. Advocate for using tags rather than folder structures. This is one of the best arguments I’ve seen against folders in SharePoint – 12 reasons folders in SharePoint are a bad idea |
SharePoint Maven remove preview
12 reasons folders in SharePoint are a bad idea | SharePoint Maven
I got an overwhelming response to my ” Stay away from folders in SharePoint ” article. While I am still working on the follow-up post on how to go completely “folder-less” using meta-data, I decided to list some compelling reasons on why folders in SharePoint should be avoided.
View this on SharePoint Maven >
Try to help people stop thinking about where (where do/did I put it) and think in terms of what (what is this document, what am I looking for). I use a spreadsheet metaphor to communicate how metadata can be used to sort and filter a list.
Finally, learn all you can about creating search results pages with faceted search and search verticals. And, get a good understanding of ‘content types’ and their use in SharePoint.
I take a rather different approach to the folders vs. metadata discussion because of the features in SharePoint and the usability issues associated with metadata based file management.
First, Gartner et all have acknowledged that most of the movement is in enterprise file synchronization and sharing. Sync necessarily means that you’re storing in folders. Windows 10 Fall Creators Update + OneDrive allows users to synchronize libraries to their local machines without additional storage considerations (since the files are stubs until needed). The user experience is substantially better with files — even allowing for the single hierarchy problem.
Second, security all-but-requires folders. SharePoint libraries are limited to 50K access control list entries which means it’s impractical to secure individual documents — even if you do so using groups.
I’m going to pause here to say that I know from a technical perspective metadata based storage and retrieval is better. That’s not my point. My point is what you can implement and maintain.
Given the need to allow for folders, I then use features like default column metadata values, property promotion (including Word Quick Parts), and other techniques to “trick” the user into providing the metadata. In other words, I make the metadata entry/capture transparent to them. It’s not another out-of-band thing they have to do. The Implementing Information Management on SharePoint and Office 365 course covers these techniques to make it easier to get the metadata that is needed.
Of course, with the metadata present search based views with refiners can be created which allow you to quickly navigate the file you’re looking for using metadata.
Though I respect Greg at SharePoint Maven, in more than a few places the article you point to is misleading or incorrect. For instance, moving a file from one folder to another doesn’t change the access URL if you’re using the SharePoint Document ID feature and getting the access URL that way. The URL length limitation is only an issue with older Office clients. So while the discussion is appropriate, not all of the data provided there is accurate.
Thor Projects LLC
I second Ted’s suggestion to check out SharePoint Maven. I have found many useful tutorials and tips there. It is an excellent resource for anyone using SharePoint.
Thank you Ted for that article…I remember seeing that one!
I loved it, because although correct, I think it also unintentionally points clearly to the problems you will have with SharePoint (folders or not) when attempting to execute a great Content and Records Managment (ECRM) strategy that brings value and solves business problems.
URL Length Limitations, File URL change, security administration nightmares, user search nightmares, etc. etc…a lot of this is NOT an issue with non-SharePoint ECRM systems. So make sure you know what your goals are…I would suggest now might be a good time to look at options.
p.s. yes, yes, ECM is dead. but I use the acronym here for simplicity 😉
IQ Business Group, Inc.
It’s easy to self-learn (by taking courses) or get advice from experts. From my experience, I would take a methodical approach, something that is repeatable and can be validated.
I would take Lorne’s approach first (the IA for RM and IA for DM though I would prefer to call it “IA for CM” or Content Management to include not just documents but different file types like video, images, software files, etc.). This allows us to take a technology agnostic approach rather than get bogged down immediately by SharePoint (or any other ECM tool) as a solution along its capabilities and limitations. I also call this the BA (Business Analyst) approach where you go through the BA process of gathering requirements from stakeholders, etc. rather than jumping on a solution before requirements are gathered (even if SharePoint already exists in the organization).
To increase the probability of success, ECM initiatives should be handled in consultation with a BA and/or Project Manager (if there’s a budget) with the Document or Records Manager (or similar roles in the organization) as one of the Stakeholders or Subject Matter Experts. IN BA/PM practice, we call this RASCI Model. An experienced BA or PM follows industry practices that are repeatable and validated by their professional certifying groups which can guarantee success of such undertakings.
In my experience, I worked for an O&G company that took this to a higher level with the creation of Centers of Excellence (ECM, BA, etc.). We did benefit from learnings from AIIM, ARMA, PMI, etc. but we also look at how we can adapt these to the company and learn from our own experience.
Speaking of repeatable process, I will take the above approach related to a merger happening soon.