Piloting Office 365 and SharePoint
1. Site StructureIt may seem like an easy solution to create a new Site Collection when trying to pilot SharePoint, but it is critical to ensure that the project is built somewhere it can continue to work with future systems. SharePoint functionality does not always work across Site Collections. If your future plan for SharePoint is to provide workspaces for all departments, as well as a fully fledged Intranet for internal communication & knowledge sharing, then you should have a clear indication of where it will sit within your full Site Structure. Essentially you are working on a small piece of a larger puzzle, before fully mapping what the completed puzzle will look like – so it is easy to create a pilot project that then becomes disconnected with the rest of your implementation. We would advise creating a Sub Site under the main Site Collection, as opposed to adding lists & libraries into the top level site which should be reserved for “Intranet” content. When analysing the SharePoint project, you may also see fit to create empty Sub Sites as placeholders to avoid having to move/replicate the site when more functionality is added. As an example we recently worked with a Borough Council who required an Asset Management System to be built in SharePoint as a Pilot Project. The assets in question were Property and Real Estate. The organisational structure defined that the Asset Team reported to the Property Team, who then reported to the Project Planning Team. This provided us with the following structure: For the pilot, this was created as a site structure, giving a sensible home for the work that was being done.
2. Managed MetadataMetadata is information about information. In SharePoint; metadata can be used to improve filters, search and automated processes. Managed metadata consists of tags that are defined by administrators and grouped in hierarchical sets within the Site Collection Term Store. These tags can be embedded within lists and libraries, through the creation of Managed Metadata columns. It is beneficial to create terms within the Term Store that can be added to in future projects. As an example, most pilot projects involve some form of document management that requires a column to control document types e.g. Contract, Policy, Report, Minutes. Creating reusable terms at this stage reduces the workload within future systems and ensures that new document types are continually inherited by the Pilot Project.
3. Content TypesContent Types are reusable groups of Site Columns. These allow common sets of metadata to be shared amongst multiple lists and libraries. Content Types can also contain document templates, so each new document uses the same template. The critical element of Content Types is to ensure that inheritance is defined, to allow for a scalable solution. Moving back to our earlier Asset Management example, we may create the following content types;
- Intranet Core Document: this Content Type will inherit directly from the SharePoint Document, and will go on to store all Site Columns that are required for all documentation within the Site Collection.
- Asset Core Document: this Content Type will inherit its Site Columns from Intranet Core Document with the addition of metadata that is unique to the Assets project
- Asset <Document Type> Documents: these content types will all inherit from Asset Core Document but will be in place to handle document templates, and any unique metadata for that particular type of document e.g. Lease Agreement may need metadata to define the Termination Date.