SharePoint is a business collaboration platform that provides a canvas of features and capabilities to help paint every company’s vision of improved work efficiency. However, many companies have come to the realization that implementing SharePoint successfully is fraught with challenges. Ironically, SharePoint is a communication and collaboration tool; however, common barriers to effective communication can contribute to the challenges of successfully designing, implementing, and maintaining a SharePoint environment.
As a SharePoint business analyst I want to establish common understanding between the development team and the final business consumers so that the solutions we provide add real value to our customers. This article is written to help shine light on how to overcome barriers in SharePoint design.
Part 1: Overcoming SharePoint Jargon during Discovery and Design
More often than not, the consumers of SharePoint are not SharePoint savvy. Quite frankly, it is not their primary function to be SharePoint savvy. SharePoint is meant to be a tool to help them with their primary job, not vice versa. As a result, they are often unfamiliar with SharePoint features, capabilities, and technical terms. Even if a business user is familiar with a SharePoint concept, it is not fully understood. Furthermore, the scope of their SharePoint understanding is limited and riddled with assumptions and preconceived notions that may or may not be true. In fact, as a business analyst we should expect that they will want to be on a need-to-know basis when it comes to SharePoint.
Therefore, it is more productive, to avoid SharePoint jargon when gathering business requirements from business users.
However, it is difficult not to talk about something when it is the focus of the conversation or the target tool that will be used to address a business need. It is difficult for the business to communicate what they want and need when they do not know the menu of features of capabilities at their disposal. How does one not talk about SharePoint when designing SharePoint solutions?
Provide a “non-SharePoint” Menu of SharePoint Capabilities
Business Analyst: “What do you want SharePoint to do for you?”
Business User: “I don’t know what I want, until you tell me what my options are.”
Business Analyst: “There options are vast. SharePoint is a platform technology that aligns to business needs and wants. If you tell me a business need or want, I can tell if and how we can use SharePoint to solve your problems.”
Business User: “My business problems are vast. I don’t know what problems SharePoint can help me solve until you tell me what business problems can be solved using SharePoint.”
If you have work for any length of time as a SharePoint business analyst or even a salesperson you are no stranger to the above conversation. When you find yourself in this conundrum the instinctive response is to offer technical feature lists, technical demos, or even training. These approaches do have applications; however, I would like to offer an alternative solution. Stop trying to get the business to speak SharePoint. Even after you present business users with the introduction to SharePoint they asked for, you did not answer the correct question. You provided them with information about “what SharePoint can do”. The question they really want answered is “what can SharePoint do for me”.
To truly get business users to open up and start communicating needs and wants that can be mapped into SharePoint solutions, I recommend offering a non-SharePoint menu of SharePoint capabilities. In other words, provide a list of user stories which are not technology specific, but could be solved using SharePoint. You have the translation key that maps to the core SharePoint features and functionality to relay back to the development team. However, you can more effectively communicate “how” these features and capabilities add value in a business context to lay the foundation for more productive discovery and planning sessions.
As an Agile SharePoint business analyst, the goal is to define user stories on a project-by-project basis to serve short-term goals of project success. However, this information transcends project boundaries and is a useful tool to build and refine this menu to continuously improve communicate with your business users during discovery and planning sessions.
Example User Story “Menu Item” Translation
Document Version Control
Conducting a SharePoint Discovery and Planning Session
Now that you have established your user story menu that maps to SharePoint features and capabilities you are ready to have more effective conversation with your business users. A business user should be able to browse this user story list and communicate back to you which scenarios resonated with them and, in turn, which are the most painful to them.
Original Conversation Starter: “What do you want SharePoint to do for you?”
New Conversation Starters:
- Did you relate to any of the user stories in the list provided?
- If you had to prioritize the list, which would bring you the most value?
- Now that we have this list prioritized, started from the top down
- Tell me about how this user story relates to you
- How would your life improve if we could fix this problem?
The key is to remove and to continue to keep all SharePoint jargon from the conversation. You may have ideas about how SharePoint can be used to solve their problems. You may be tempted to offer SharePoint solution options during the discussion. DON’T! The objective of a discovery and planning session is NOT solution design. The objective of a discovery and planning session is to gather the needs and the want of the business and define acceptance criteria in a business context. As soon as you place the focus on SharePoint, your knowledge of SharePoint, etc. you are no longer focusing the conversation in the appropriate place, which is allowing the business to express their needs and wants. Your job is to be a conversation facilitator to keep the conversation focused on the business user and their needs, not to highlight SharePoint capabilities or solution concepts at this point. You’ll be surprised what you can learn and how effective you can be when you take this approach.
The success criteria of a discovery session includes:
- The business users, not you, did most of the talking during this session.
- You gathered information that encapsulates the business need(s) that you can take back to the development team for solution design.
Now you can talk SharePoint jargon. Why? Because when you are in the Solution Design phase your audience in the technical delivery team, not the business user. SharePoint is the language of the delivery team. Share the story of the business. Map SharePoint features and SharePoint capabilities. Design custom application development solution approaches. Design proof of concepts to demonstrate SharePoint capabilities in the context that is meaningful ways to the business. Start building walking skeleton solutions in the Agile delivery framework to pass through a feedback and solution refinement cycle. At this point, you are equipped with the information to create a SharePoint roadmap for your customer.
Just remember, when you present your solution designs make sure to properly the SharePoint jargon foundation with your business user. Eventually they have to learn SharePoint terms. This is the appropriate time. However, we are presenting the SharePoint jargon on a need-to-know basis to mindful and respectful to our target audience.