Portal Site Navigation Decisions

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:

• The primary goal of deploying SharePoint (at least the initial deliverable in most cases) is to increase cross-team collaboration.
• Most companies go through at least minor organizational changes at least once every six months… and a major, high-level reorganization every 18 months.
• Most people contributing in non-essential (“Consulted” or “Interested” for those familiar with the common RACI methodology) have absolutely no idea which group actually owns a given project, despite their supposed involvement.
• The vast majority of what any employee does in a company is either project, program, or operationally focused.

So… a year later, you have a problem:

• A major reorganization has happened… the Whatsit division has been merged with the Widget division, and IT (which has been renamed to “Information Services”) will now report to Finance, leaving you with a decision about what to do with those URLs and sites… do you keep them as-is, or do you break people’s bookmarks so that your portal more directly aligns with the organizational structure?
• You’re frequently being told that employees are having difficulty locating what they’re looking for because they don’t know what organization owns a given project, program, or process. For example, is my tax information held by finance or by HR?
• Collaboration has not increased… in fact, people are focusing even more intently on their silos, as identified by the fact that both the Widget and the Thingie divisions have blogs (that no one is reading), and the Whatsit and Thingie groups are finding that a large amount of their Wikis contain duplicate (and frequently conflicting) information.

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:

• The top-most level of the site is now based on how people work and what people work on rather than what group they work with/for. This benefits collaboration because it doesn’t reinforce the idea that a project or program is owned by one particular group… it reinforces the idea that we can all help and work together without regard to our organizational structure. We’re not here to be “Employees of the Widgets Division”. We’re here to get that Widget 2.0 project done!
• The top level of the portal is now fully independent of changes in the organizational structure. Of course, different departments may come and go, and that may have ripple effects as to what projects/programs continue, but for the most part changes in the organization do not have an absolute effect on the projects/programs in place.
• The URLs are intentionally designed to be easier to understand at the portal level, and don’t necessarily match the name or title of the site. “Technology Support” actually links to the IT helpdesk (whether it’s SharePoint or not), and is independent of what IT/IS/I? is formally named.
• The Site Directory is now more heavily used, and every site in the company (Portal or team site, SharePoint or non-SP site) is now listed in the Site Directory. Columns have been added that allow sites to be easily found and organized. For example, every site can be associated with a department/division. This allows ownership to be maintained while reducing cross-departmental boundaries in the sites themselves.
• There is now ONE wiki. This may seem trivial, but it is actually very, very important. The power of wiki is in its ability to serve as a single collectively created and managed, authoritative resource for knowledge. It is tightly interlinked as new terms are found that should be clarified or documented… and generally a wiki is only truly integrated with itself. If you have 100 wikis with 5 pages each, they’re not very useful… but one wiki with 500 pages is truly powerful, useful, and authoritative.
• Each department still has its own site for information that is specific to it… internal processes… meetings that are specific to the organization (department meetings, internal announcements, etc). However, each department site is at the exact same level… flat… organizational structure is irrelevant… meaning that department sites can come, go, and change without dramatic impact to other sites. Further, since a huge amount of the project and program information that was in these departmental sites has been moved, the content in these departmental sites is dramatically reduced.

This structure also provides significant benefits for the system administrator and system maintenance, specifically with regard to content database management.

• Since projects are now each their own site collection, “active” projects can stay in “active” databases. As a project completes/closes, the supporting site collection can be either removed entirely (the contents migrated to a file share), or can be locked, backed up, and moved to a lower availability, lower capacity SQL server. For example, this SQL server might use a simple internal RAID array rather than expensive SAN-based storage. If this server experiences any kind of failure the impact is minimal since these content databases rarely change… restoring from a week-old backup is perfectly acceptable.
• The fact that site collections are used also ensures that as sites grow, they can be shuffled between different content databases with no visible impacts (though this should be done as minimally as possible).

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.