Getting started as a business analyst on a SharePoint Project can be challenging because SharePoint has so many features and functionalities. Users will provide their software wish list to the you without considering the items that will bring the highest business value to the company.
Here are four quick tips for gathering requirements for SharePoint projects:
-
Identify who will be affected by the success or failure of the SharePoint solution:
This stakeholder will give you a clear vision for the SharePoint solution. Understanding the vision, will allow you to ask the right questions and mitigate requests from business users that are not considering the vision. This stakeholder will also prove to be valuable when tackling ways to promote user adoption.
-
Get a complete understanding of the business problem and the reason for change:
Knowing this will allow you to write thorough user stories, which will provide your Development team with great insight about the business user. In addition, Quality Assurance will be able to identify critical user scenarios when building test cases.
-
Avoid the words “Content Type” and “Metadata” in the requirements gathering session:
These terms tend to confuse business users and you spend more time providing the definition, than gathering requirements. Instead, refer to the business user’s documents in their language. Create a glossary or data dictionary for their documents, if you need to. This will help you to easily identify with their documents and understand important details about the documents that are critical to document search and upload.
-
Identify line of business system integration sooner rather than later:
In many cases, companies like to leverage SharePoint’s ability to interface with other software applications. Knowing this early in the project, allows you to involve the line of business system’s Subject Matter Expert during the requirements gathering sessions. By doing this, you will be able to quickly identify gaps and/or system constraints.
I hope these tips are helpful; they’ve certainly proven to be the most successful approach for me as a SharePoint Business Analyst in making sure the requirements gathered are not only holistic and easy to understand by both the business and the technology team, but that they are also gathered in a concise and timely fashion.