What's involved in SharePoint scoping?

Project scoping is one of the first steps of a SharePoint project. It’s also one of the most important. SharePoint implementations have received a negative reputation and been plagued by ‘failure’ statistics. Rather than being a fault with SharePoint itself, the reason why “only 11% found their SharePoint project was a success” (AIIM report) is often due to how to project is carried out. Stakeholder endorsement, lack of governance and poor strategy are some of the most cited reasons for failure, which should all be addressed and considered before the project even begins.

The typical SharePoint project will run through four key stages. These can slightly vary from project to project or even be touched upon multiple times through agile iterations but the main steps can be outlined as:

In this article, we want to focus on the first stage: scoping and discovery.

What is scoping?

If you have engaged with a SharePoint partner, then the chances are that they will suggest a scoping workshop before starting a project. (If they haven’t, then be careful!)

Scoping or ‘discovery’ is all about getting to know your business, your current systems and finding out what you want to achieve with SharePoint. Why are you about to invest in SharePoint? What will SharePoint success look like to you?

Scoping is an important first stage in a project, but it can also be a standalone service. At the end of a scoping workshop, you should receive a document outlining all the findings, recommendations and costs to carry out the project. This can then be used to go ahead with the proposed work or can be taken away for you to act upon yourselves. This provides a great way to get a better feel for your SharePoint partner, to meet the key contacts and allow them to prove their expertise before committing to the whole project.


  • Understand your organisation and your current environment
  • Find out what you are hoping to achieve and why
  • Make sure that the most suitable deployment option is chosen
  • Establish the scope of the project

End Results:

  • Define and document high-level business requirements
  • Define and document high-level technical requirements
  • Provide recommendations and/or options on how to proceed
  • Receive a detailed and costed proposal

What’s involved?

We’re often asked what’s involved in scoping, which is why we send a scoping agenda through in advance of any scoping workshops. Each agenda will be specific to the organisation but we’ve outlined the main areas and example questions involved in SharePoint scoping workshops below.

Before the scoping workshop

Before scoping, you should have already had some high-level conversations around the project so that your SharePoint partner has a broad understanding of the requirements and expectations. These requirements and expectations will help to shape the scoping workshop.

Before the workshop, there is little that you will need to do except have an understanding of your current frustrations or challenges and have some goals in mind. Hopefully these will have already been established and then can be finalised and agreed upon during scoping.

The key thing to ensure before the scoping workshop is that all the stakeholders have been identified, as they will need to attend the scoping workshop.

This will typically include:

  • Project sponsor
  • Project lead
  • IT team stakeholders
  • Stakeholders from relevant business functions (e.g. HR or Operations)
  • Any key participants who will drive adoption (‘cheerleaders’)

During the scoping workshop

Scoping workshops are flexible and should also be relaxed and informative. It’s your chance to discuss your business, its systems and processes depth and to gain specialist expertise to help solve challenges, improve processes and overall aim to make your business more streamlined and successful. There are three main elements to the scoping, which can often overlap. These are:

  • Understanding your organisation
  • Understanding the current systems infrastructure
  • Exploring and defining specific project requirements

Understanding your organisation

This normally a short session and the objective is to understand how your organisation is structured and how information is stored, managed and shared for each team or department. Example questions can include:

  • What is the team or department composition?
  • What IT systems are used daily?

Understanding the current systems infrastructure

The objective here is to get a detailed understanding of what systems SharePoint will be replacing. For example, we look to explore the business systems that you using to:

  • Store, manage and find information
  • Communicate/disseminate information to internal staff/partners/customers
  • Manage or automate business processes (e.g. holiday requests, sick leave, induction, IT support requests)

Example questions can include:

  • What is your current system used for?
  • How much data is there?
  • What is the user base?

Exploring and defining specific project requirements

By this point there should be a good understanding of how your organisation works, together with the systems, data and associated processes that are in use. This final stage, is to ensure you’re your SharePoint solution will meet your needs and requirements, which can cover a lot of different areas. Some examples of typical questions include:

  • What is the most suitable product version?
  • What are the design requirements? (out-of-the-box, basic branding of bespoke)
  • What are the security requirements?
  • How do you want to access SharePoint?

After the scoping workshop

A few days after a scoping workshop, you should receive a document (or documents) that outline the overarching business and technical requirements, recommendations and ways to proceed as well as proposal costs and timescales.


Each SharePoint project stage is important but having a unified and documented understanding of the business, current system setup and project requirements from scoping will ensure a solid foundation for success that can be carried through the rest of the project.