What roles are required for a SharePoint Project

When starting a new project that uses SharePoint, whether this be on premise or online it is important to use a variety of different people who excel in different roles. A project may not require all of the roles or even each of the roles being utilised for the duration of the project.

Architect / Solution Architect

I see the complete picture – lets tie it all together to provide the complete solution

The architect role may vary depending on the type of project. The architect may plan a SharePoint farm if on premise, utilise Azure with O365 or even tie the SharePoint solution into a wider eco system.

Fundamentally the architect will create a high level design that the other team members can elaborate on.

Business Analyst

I make sure we understand what needs doing!

This person that maps a business requirement to SharePoint functionality. SharePoint can do many things, but it can’t do everything. It is key at the start of a project to get a BA to look at the high level requirements and make sure that SharePoint is a suitable solution.

This means that the BA should be SharePoint savvy. They should understand the key parts of SharePoint and what SharePoint does well and not so well. A BA doesn’t need to understand the granular detail of what features to activate, the PowerShell commands or even have discussions with a developer. However, they should be able to take a requirement from a business user and map this to a SharePoint function.


I want to store documents in a central location so that my team and I can co-author.

A good BA would look at this requirement and quickly understand that this would most likely require a SharePoint document library. The BA would also then be able to bring out the granular detail of the metadata required, permissions and search requirements.

In summary, a BA gets the requirements and moulds them into SharePoint requirements.

Consultant / SME

I know SharePoint like the back of my hand! Content types, search and PowerShell!

A good consultant will be able to configure SharePoint to meet the majority of the functionality. They will normally be able to do the majority of the work or know what type of professional is required.

The consultant should be able to turn their hand to the surrounding technologies that SharePoint ties in to. Consultants should be able to look at PowerShell, Power BI, PowerApps and even Flow.


I make the magic happen – little bit of VS Code and SPFX please!

Developers can extend what SharePoint does to meet the business requirements. SharePoint has gone through many different evolutions of development over the years. From server-side code back in SharePoint 2007 to more modern and industry recognised web technologies utilising the SharePoint Framework or rest APIs.


I make sure all the stuff works – no point in delivering a broken solution!

Testing is a key part to any project. With SharePoint this can sometimes be an interesting as there is fine line between testing normal SharePoint functionality and custom functionality. There isn’t a need to test if a view can be created as we know that this is possible. But testing that the view has been created correctly and to the requirements could be a valid test.

Project Manager / Scrum Master

I make sure everything is done on time and the customer is happy!

Making sure that everything is delivered on time and to cost is defiantly one of the hardest parts of any software project. Depending on the delivery method of the project a scrum master or project manager may be required. Either way, this team member should be making sure that elements of the project are delivered on time and in a logical order.

Business Change / Adoption Consultant

I make sure users understand the solution and how to use SharePoint going forward!

Informing the business of the complete solution is key. Any IT system that is implemented must be rolled out to the users. With SharePoint this is key due to how extensible it is. If users have the know how on creating views

This isn’t a definitive list of all the roles that are required for all SharePoint projects but these roles would certainly be a good starting point. What roles do you find most important for SharePoint projects/