Equal only to branding, your SharePoint portal navigation structure has one of the biggest impacts on the usability of your site. Done correctly, it reflects how people in your organization work (and how you would like them to work), the importance of different aspects of the business/organization, and can very often force you to make decisions that affect the functionality of your environment as well. Unfortunately, because of these things, it is also very, very political. The more powerful an individual is in your organization, the more prominently they feel they should be represented in the portal… and because they are powerful people they frequently get their way. The result is a navigation structure that does more for your organizational chart than it does for the people using the portal.
So you have to get SOMETHING up, and you have basically every CxO calling you wanting their site to be at the top of the portal… so you end up with something similar to the following:
On the surface, this isn’t exactly horrible… and it will likely work well for you initially… but lets consider some perspectives:
So… a year later, you have a problem:
The problem here is that we are incredibly focused on our organizational structures as our map of how to get things done… but in a world where we’re intentionally trying to work as if those boundaries didn’t exist, building our collaboration space based on them is counterproductive. Instead, we need to focus on how people are working (and how we want them to work), what they’re working on, and what they need to work on and/or eliminating the things that are preventing them from working. Finally, from a SharePoint Farm Administration perspective, we need to find a way to reduce the number of changes to the high-level structure of the environment, and we need to try and maintain the overall performance of the system. Finally, remember that although it is easy and tempting to make URLs match site names, this is not a requirement… and is frequently a less than perfect suggestion.
After working with numerous customers, I’ve come to a general purpose structure that at best can provide a direct model to work off of… and at a worst demonstrates an example of how to create a SharePoint site hierarchy that can flex and bend with the ever changing corporation:
This model presents several significant changes, most intended to refocus the portal and the employees on collaboration:
This structure also provides significant benefits for the system administrator and system maintenance, specifically with regard to content database management.
Of course, there’s nothing we can to do stop sites from needing to be created, moved, and deleted… URLs will always change at some level… but the lower you can make those changes, the easier the site is to use for your users… and planning for what might happen, if you take the right steps, is a lot easier than trying to fix what did happen after the fact. Planning is key… including planning for what you don’t know, or what you do know is likely to change.
I have to say I looked high and low on the internet for guidance on sharepoint hierarchy and I have to say your post has helped me tremendously. Thanks for such a great post.
Your post is very useful and I would like to follow your design. It is 2014 and I am using SP2013. If possible, I would like to see a revision for the same topic giving that social features (blog, newsfeed, skydrive pro) is introduced. Thanks!