[vc_column_text disable_pattern="true" align="left" margin_bottom="0" width="1/1" el_position="first last"]
One of the great things about SharePoint is how much control you have over the SharePoint structure. You can customize site structure, page structure, and list and library structure among other things. This amount of power is fantastic, if you know what to do with it. However, if you’re just starting out with SharePoint structure, you might not know anything about the default structure, let alone how to structure it yourself.
Fear not! PAITgroup has decided to share some insights into our own SharePoint structure. Of course we can’t share too much here to protect our privacy and the privacy of our clients. This is just a brief look at our SharePoint site hierarchy and the site collections and subsites we use the most.
It’s important to understand some of the organizational concepts of SharePoint. A top-level website is the highest web site in a SharePoint environment. It is the site provided by the web server, and you access it by typing the URL of the server without specifying a page or subsite. A top-level site can have multiple subsites. A subsite is a complete website stored in a subdirectory of the top-level site. Those subsites can have their own subsites. A top-level site and its subsites are known as a site collection. Each site collection has one top-level site and can contain subsites, and there can be multiple site collections on each Web server.
Developing your SharePoint Structure
Before you create your SharePoint environment you need to plan the structure for your site. In order to effectively do this, you should take the following steps:
• Determine who will use the site
• Determine what sort of content will be on the site
• Plan the navigational structure
• Determine who will access the sites and the site content
SharePoint is based around your organization and the people in it, so naturally your structure should be determined based on who needs to use the site and how they will use it.
Determine who will use the site
The scope of the SharePoint site will determine what sort of site you need to create. If you have an organization with many teams that don’t have a lot of overlap, then you might create a top-level site for the entire organization and then separate sites under that for each team. Or if you’re in a very small organization where the teams have a lot of overlap, you might create top-level sites for each department, with subsites specific to each project.
Determine the content of the site
When you’re creating your SharePoint environment there are different types of sites you can create. There are several sites that are known as workspace sites. These provide users with the collaboration tools necessary for collaborating over documents or resources related to meetings. These can contain lists of information like related documents, team members, and links.
There are also site templates that let you create specific sites to meet your needs. The Team Site template, for example, creates a site for teams to create, organize, and share information. It automatically includes a Document Library, and lists for Announcements, Calendar, Contacts and Links.
You can also save your own customized sites as templates, and reuse your templates to create more sites. Your templates can include content in them, or they can maintain the structure of the site without the content.
Once you know what sort of content your site is going to manage, you can make an informed decision about what type of sites you’ll need to create within your SharePoint environment.
Plan the navigational structure
The navigation structure of your environment is highly customizable, and gives you the ability to determine how sites are connected. For example, you can customize the left column navigation, or the Quick Launch, of each site. The quick launch displays on most pages in a site, depending on the page structure. You can also customize the top link bar, which is an element containing hyperlinked tabs, which displays on each page of a site.
You can link sites to other sites in the environment if you want them to be associated. For example, you might add links to all of the subsites in a site collection to the top link bar of the top-level site. You might also link your related site collections to each other, like Sales and Delivery. You can frequently base the navigational structure on the structure of your organization. Think about how your departments and teams connect, and how your projects and tasks connect, and you’ll want to connect those aspects of your SharePoint site the same way.
Determine access to the site and site content
When you’re creating your SharePoint environment you have a lot of control over not only who can view content, but who can change that content. Normally all users have the ability to view the company’s highest top-level site, the home domain. Typically all users would have permissions to add content to the site and read content, but their edit permissions might be determined by other criteria.
Permissions for any site collections and subsites are more complicated. For each subsite and site collection, you should determine which users will need access to it and what amount of access they will need. You also need to determine which users are the administrators of the main site and of the site collections and subsites. Once you know which users need access to which sites, you can get an idea for how to build the sites and how to define permissions.
It’s also important to note that you can set permissions at the list and library level too. You can grant users access to view all of the content at the site level, then you can modify their permissions to view lists individually or even documents and files individually.
PAITgroup Site Hierarchy
This is not a complete representation of our SharePoint environment, but for the sake of demonstration this is our SharePoint structure.
The Home site is the highest level site collection of our SharePoint environment. It contains general content, such as the company calendar and employee handbook. It also contains several lists and document libraries for content that is not specific to a company department, client, or project. All of the other sites we use are site collections that branch off of the root site.
The delivery site collection contains any information related to projects. This is where members of the delivery team come to update tasks, upload documents, and track clients and projects. There is a document library for all of our instructional documents (any white paper we give to clients) and a document library for templates and other delivery documents. There is a list for all of our open projects so that our team can quickly view what we’re working on. There’s also several task lists where team members can find work if they run out of things to do. The delivery site also has a calendar specifically for members of the delivery team to track project status and coordinate. Finally, and most importantly, the delivery site has subsites for each of our clients.
Each PAITgroup client has its own subsite on our delivery site. Each client subsite has several features that make it possible for us to effectively manage projects and documents. We’ve activated the Notebook feature on each subsite, and we’ve included On Ramp information (login credentials and other necessary information to work in the client environments), meeting notes, and project specific notes.
Within each client subsite we also have task lists and document libraries for each project. It’s helpful when you’re setting up project task lists to organize the task lists. There isn’t always a one size fits all way to organize a task list, but some examples would be by type of task, by person assigned to the task, or by urgency. Some of our task lists have been personalized with fields, like adding the Notes field to more clearly see what a task is about. We also find it useful to add tasks to the timeline to visually see project progress.
Our marketing site collection contains all of our documents and information related to the company web site, press releases, conferences and conventions, and other events. The marketing team uses this site collection to coordinate our promotions on Twitter, Facebook, the company website, and other public forums. Our marketing site also contains document libraries with bios of some of our team members (in case they need to submit a bio to speak at an event or make a guest post on a blog), past blog posts, magazine articles, and speeches and presentations.
The Sales site collection contains all of the information related to sales, including current client information, leads, follow ups, statements of work, partner information, and vendors. Members of our sales team use the sales site to keep track of where our current work is coming from and places where we might find new work. They also use this site to strategize and coordinate.
The Sandbox site collection is one of the most important areas of our SharePoint environment. As a SharePoint consulting firm with an in-house development team, we do a lot of customized solutions for our clients. We also do a lot of demonstrations and proofs of concept. All of that work is maintained and contained in our sandbox area, where it can’t accidentally impact our site in a negative way.
Our sandbox site collection has several subsites, including individual playground areas for our developers to experiment and try out new techniques. Each developer has full administrative control over their own playground, and has carte blanche to enable or disable site features, manipulate site definitions, and customize the site in any way they see fit.
Frequently when we’re bidding on a job or working with a new client, or if we’re in talks with a client that has no SharePoint experience, we build a demo environment to show them how they could use SharePoint to meet their business needs. Some clients are interested in custom branding and user interface, so we might create a new subsite and then build them a sample design solution. Sometimes if a potential client has given us some ideas of what their requirements are, or what they’re struggling with in their current environment, we’ll create some generic SharePoint libraries, lists, task lists, calendars, and other tools to show them what they could expect in their new environment. We also have a demo site that contains a lot of our PAITgroup custom solutions so we can show clients unique tools that they might not know exist. We also have replicas of solutions we've built for other clients, so we can show people what we've done without violating their privacy.