New SharePoint implementation, but have we gone wrong? Your help and advice would be welcomed!

[Deleted]

After some months of planning and preparation we finally went live with our SharePoint Online implementation recently. All is generally well, but we're already seeing some real headache issues that have emerged only days after going live.  I'd appreciate your views on some of the following approaches we took and the associated issues that have emerged from them:

SITE STRUCTURE:

We structured into site collections by business unit, eg. Technology, Ops, etc. - the problem is that we've already had a organisational reshuffle and various units have not only changed name, but have also been relocated under different business units, therefore we've had to recreate new sites under different site collections as they could not simply be moved or copied in any apparent straightforward way.

Early on in the project we were advised that organising by business unit would be a bad move as inevitably things change. How would you go about creating this sort of structure that doesn't get affected by change. I could change the navigation, but then you end up with subsites residing in old locations where people become confused as to why their site and their 'neighbours' are no longer in the same team and their URL still refers to their old department or business unit name.

IN SHORT: How have you structured your site collections & subsites?

CONTENT TYPES:

We created our own set of content types with the understanding that we'd use these for our standard company templates for generic word documents, powerpoint presentations, etc.  We're finding that if someone uploads a document to a document library (customised template library with managed content types enabled). The problem now, so it seems is that people are uploading file types that aren't in the default content types we created (Word, Excel, PowerPoint, Visio) - they've uploading PDF's, Project files, images, etc.  How should we handle this? If we add new content types in the content type hub the changes will propagate to the various site collections, but then they won't automatically be added to the list of available content types for that list - and importantly if someone has created custom columns how will these new content types have those custom columns applied?

IN SHORT: How have you used content types?

thanks!

[#2]

I prefer to keep the sites themselves flat, and use navigation to provide the 'illusion' of structure.

This guards against the inevitable re-orgs in most cases, because HR is pretty much always going to be HR, Finance is Finance, etc.

Each department / function, or in some cases, team, would get a site collection (either a 'classic' SP site collection, or an Office 365 Group (with associated SP site).

This gives you a security boundary (and keeps the list of users and groups neater) for each site collection, as well as the option of a storage quota (if you set storage management to manual at the tenant level).

For your content types, it sounds like you've created more 'file types' rather than 'content types' - e.g. Word is a file type, not a content type. Something like 'Expenses form', or 'High level design' would be a content type - perhaps with a template associated, so if you create a new High level design, it uses the template, but if you upload a high level design from elsewhere, you can select the correct content type, and it prompts for the relevant metadata, etc.

[#3]

many thanks for this reply. I guess with the content types we wanted to enforce a company standard mandatory requirement for each document which are two custom columns 'protective marking' and 'document type' ... also we wanted to encourage people to use a standard/default template for Word documents for example, using our branding etc.

We've generally got some of the traditional teams in site collections that generally will remain the same - finance, legal, technology - but there are some that are questionable and they are the ones I'm concerned about the future when another shuffle happens... perhaps these could reside in O365 groups or possibly sit in a flat structure as you describe hanging, say, from our 'root' site collection?

[#4]

Think about using Communication Sites for your publishing/broadcast content (intranet) and Groups (team sites) for your collaboration activity. All of these site collections should be "flat" - nothing hanging off of anything. If you use navigation to connect the sites, re-orgs will not matter. If you want every document to have two special columns, create a content type called [Company]-Document and use the out of the box Document as its parent. Add your two custom columns to that Content Type. You will then have to associate that content type with each of your document libraries. You can then associate a Word template with that content type - so that if a user goes to a library and says + New Word doc, they will have your template. (Most people don't do that, by the way, so there's that! I understand what you are trying to do, but from a practical perspective, my guess is that you will not get the outcome you want. An alternative approach would be to make all of your templates available in a Brand Central type site collection and then train your staff to use these templates - whether they create a document from Word or from SharePoint.)

Once you have [Company]-Document associated with all of your document libraries, ANY type of document (Word, PDF, PPT, etc.) uploaded to a library will have those two attributes. If they are required, then users will be prompted to enter them no matter what type of document they are actually uploading.

As @Rob Ellis says, you should think about using content types for a functional document like a Project Charter or an Expense Report, not for a format (type) of document like Word or PPT. Your "base" corporate document doesn't care about the format of the document (though you can associate one and only one template with it). However, your base document can include any enterprise-wide required metadata that you want to include. Note that you will not necessariliy be able to easily force the custom content type in to document libraries set up by your users but you can probably use code or training to encourage its use. I never recommend trying to force metadata into Team Sites. It tends to discourage users from storing documents there. However, on Communication Sites, with limited publishers and lots of readers, this is much easier to govern.

[#5]

An interesting approach with a centralised set of document templates is to point the content types to those centralised templates, so you get the best of both worlds.

That way, whoever manages your templates doesn't have to know about editing content types, either in specific sites, or in a content type hub.

[#6]

Totally agree. Definitely how I would do it if needed. Just trying not to over-complicate! :)

[#7]

I believe we tried this approach and it turned out that it wasn't possible to point the content types in the content type hub to a centralised template location (in a different site collection) 

[#8]

@Deleted, I wouldn't use content type hubs.  In on premises SharePoint it was just about ok in some scenarios but in Office 365 I would not go for any content type hub solutions.

To get similar functionality to the content type hub I use PnP technology to replicate the content types and columns across sites. The big advantage here is that I have full control over which sites are updated when and with what content types/columns.

[#9]

Did you try putting all the templates in the Content Tyoe Hub Site Collection? Not that I am recommending doing that, to be honest because I am still not convinced that it is going to get you your desired outcomes. I think I am trying to get you to really think about whether you need the templates at all and whether they will add value. It is so hard to get users to start a Word document from SharePoint (except in fit for purpose solutions) that you really could be over-planning and not getting the outcomes you want - and it may or not work technically or consistently. I think it is important to balance what is maybe technically possible with what is practical and truly adds business value. Some practices are more easily implemented with training (I know, hard to believe) than trying to use every technically possible feature of SharePoint.