SharePoint. Planning your environment

Image: Man writing plans on glass wall
By Neil Wells-West on

SharePoint. Planning your environment.

SharePoint has been available in various forms since Microsoft launched the first version “SharePoint Portal Server” in 2001. Since that time, the product has undergone radical changes and iterations. It has evolved over the subsequent years through a significant number of on-premises versions culminating in the ‘modern’ SharePoint Online version, which can be obtained through any of the following ways:

  • Purchased as a ‘standalone’ SharePoint Online Plan 1 (Basic features)
  • Purchased as a ‘standalone’ SharePoint Online Plan 2 (Enterprise features)
  • Included as part of any of the ‘enterprise’ Office 365 subscription plans (E1, E3, E5)

Regardless of how your organisation has purchased SharePoint, you will either be a ‘legacy’ SharePoint environment (e.g. your organisation is already using an earlier version of SharePoint such as MOSS 2007, SP2010 etc.) or you will be a new SharePoint environment (potentially looking to use SharePoint for the first time).

Image: SharePoint logo and clipboard graphic

Planning your deployment

One of the key (if not THE key) aspects that has negatively impacted SharePoint deployments in the past is a lack of planning. This factor alone has resulted in numerous failed deployments. A poorly planned SharePoint environment can easily become a sprawling mess and end up replicating the chaos often seen with unmanaged file server storage. Carrying out a series of planning activities for your SharePoint deployment is vital and is a golden opportunity to address any issues, constraints or failings with existing legacy deployments.

In a brand new deployment it’s probably the one chance you will have to get things right from the start. It will enable you to carry out your deployment in a way that ensures future-proofing, optimisation and flexibility and which will result in intuitiveness and usability for your end users. It’s important to note that ‘planning’ is NOT ‘design’. The goal of planning is to agree an implementation approach and an operational framework that will support your SharePoint requirements going forwards. It is likely that a subsequent series of design activities will be required in addition to planning to agree the functionality and solutions that you will actually deploy in your SharePoint environment.

A properly planned and well thought-out deployment will enable you to deliver those solutions consistently and securely in your SharePoint environment.
Thinking up front about how your SharePoint deployment will be managed is also an essential part of planning so that when you start to use the environment all the prerequisite planning and requirements for management are already in place.

Image: SharePoint logo and steps graphic

So how do you go about this?

A well planned SharePoint deployment should consider (as a minimum) the following key areas:

  • Review your current environment (audit your legacy SharePoint / file servers etc.)
  • Define a baseline proposed SharePoint information architecture (determine where your content needs to be located)
  • Conduct use case analysis (understand who needs to do what and when)
  • Build proofs of concept (validate your assumptions)
  • Plan for user adoption (help your users engage with SharePoint)

SharePoint environment review

It is often surprising to find out how little is known about the existing environment within many organisations. Taking the time to conduct a basic review of the legacy SharePoint environment, file server drives, document management systems, CMS and any other applications used to create or manage unstructured content should be a first step.

Image: Office scene

The goal of this initial review activity is get a good handle on the scale, scope and complexity of the existing environment so you can begin to categorise and prioritise the various aspects and gain an insight into how the organisation is using its current systems and information. This will normally require assistance from IT staff as well as business users and data owners from a number of different areas of the organisation. A task to audit and collate the information and existing repositories (at a high level only at this stage) should be assigned to the appropriate users and this should then be reviewed and documented for reference.

Define a baseline proposed SharePoint Information Architecture

In order to begin to map this out it will be necessary for you to think about the various locations where content may be stored, and using the information gathered previously during your review of the current environment, conduct an activity to baseline the proposed new environment.

Image: SharePoint architecture

The following list indicates the typical areas that your baseline information architecture should address:

  • Personal collaboration (e.g. ad-hoc, one to one information sharing)
  • Team collaboration (e.g. ad-hoc team information sharing, cross-department collaboration)
  • Project collaboration (e.g. project-focused collaboration, sharing information for the purposes of achieving a set of goals with a finite timescale)
  • Document management (e.g. team documents, company documents, document life cycle management, approvals, publishing, review)
  • Corporate communications (e.g. one to many, Intranet, marketing, campaigns, initiatives)
  • Enterprise communications (e.g. discussions, topic groups, posts, comments, feedback, focus groups, areas of interest, company notices)
  • Business solutions (e.g. forms, business processes, workflow, discrete solutions, department or team applications)
  • External sharing (e.g. partner and supplier information sharing, secure external collaboration, file sharing with nominated external parties)

The people involved in this exercise should ideally have some expertise or experience in guiding and defining an information architecture along with facilitation, communication and SharePoint skills. An important point to note is that this exercise isn’t about asking your organisation what SharePoint features they require, its much deeper and requires an approach for work modelling and building consensus regarding requirements. An initial baseline information architecture plan should then be created and and distributed for further feedback and refinement among your SharePoint deployment stakeholders.

For more information and considerations around information architecture please see the following related Silversands blogs:
Information Architecture. Part 1: What is it? Why you need it?
IA Part 2: Information architecture for SharePoint & Office 365?

Conduct use case analysis

A well-planned SharePoint deployment needs to support the ways your organisation works with information. This doesn’t mean you will need to understand all the aspects and nuances of every business process within the organisation but it will be necessary to gain insight into a set of typical use case scenarios that reflect some broad business processes.

Image: What's the use case flow chart

Build proofs of concepts

Having reviewed a range of suitable use cases for consideration, it’s then a good idea to map them out in a simple way with their relevant stakeholders and carry out an activity to build out these use cases using the SharePoint functionality as far as possible.

Image: Proof of concept wheel

This should be done as a series of proofs of concept or “PoC” as it provides valuable insight into what the end user experience will be regarding the SharePoint user interfaces and how the related business processes would be supported by the relevant capabilities and features available. This will also give you the opportunity to confirm and validate the use cases in terms of their requirements as well as their impact to your organisation.

Proofs of concept that explore such activities as the following could be considered:

  • Uploading documents
  • Reviewing previous versions of documents
  • Collaboration between users across different departments/teams
  • Co-authoring documents
  • Using metadata to organise large volumes of information (instead of folders)
  • Using search to find documents
  • Opening and saving documents from with Microsoft Office directly in SharePoint

There are probably an infinite selection of proofs of concept you could explore, however the main thing is that they are necessary as they will provide you with a way to shape, refine and adapt SharePoint for your needs as required. Building and testing proofs of concept can also be used to go back and refine / update your information architecture as it will likely highlight changes or different aspects that may need to be considered and included in subsequent planning activities.

SharePoint adoption. Plan in advance

The single most important part of planning for an effective SharePoint deployment is user adoption, however this activity is often only considered as an afterthought (or worse, overlooked completely). In order for your SharePoint deployment to produce the kind of transformational working it is likely being implemented for, it is therefore necessary to consider user adoption not simply as a one-off task but as an ongoing program of activity. This can make the single biggest difference between the success or failure of your deployment.

Image: Success Failure sign

A great example when considering user adoption is to consider how different the end user experience is between using traditional file server shares and SharePoint for even simple tasks.

Consider the simple task of opening or saving a file in Microsoft Word. Using the traditional file share and Windows Explorer, the user would:

  • Browse the file share using Windows Explorer
  • Double-click to open the file
  • Microsoft Word will open automatically and display the document
  • Upon saving the user will again browse using the Windows Explorer interface (within Microsoft Word) to select the save location.

All this is relatively straightforward when using a desktop or laptop PC with a large monitor or screen and when the user is sitting at their desk connected to their internal network.

Image: Detailed nav on large monitor

However consider the same task and entirely different end user experience when trying to do the exact same thing using a mobile device with the SharePoint app:
• User opens the SharePoint app on their mobile device
• User selects the site that contains the document they want to open
• User selects ‘Files’
• User selects the relevant document library
• User selects the document (which then opens in the OneDrive App)
• The document is saved automatically (periodically)
Many organisations are moving to a mobile-first position and are deploying SharePoint to facilitate remote access to key documents from different devices and multiple remote locations.

Image: SP Mobile Nav screens

The key to the success of this radical change in end user experience is user adoption planning and needs to be considered as a core part of deployment planning. For more information and considerations around user adoption please see the following related Silversands blogs:
Understanding user adoption
Minimising the failure rate of user adoption

Want to know more?

Please feel free to use the form below to contact us if you wish to speak to one of our experts

We host regular events so please do check our schedule of current seminars, webinars and events.  We also post regular blogs on the latest updates and expert advice on Microsoft 365, Cloud and Hybrid IT, User Adoption and the Power Platform, so please do follow us.

Contact us

  • This field is for validation purposes and should be left unchanged.

We have the expertise and the experience to provide specialist solutions and drive your business forward

Get in touch

How can we help you?

Get in touch

What updates would you like?

Subscribe