Have you ever wondered why SharePoint requirements are so difficult to create when engaging a business or project team? When an individual creates a wish list for a product or service, the list is typically short, sweet and to the point. However, when a team gets together, and people begin to discuss their collective needs, the same list becomes exhaustive and difficult to navigate.
At the end of that effort, the Project Manager is left with a convoluted mess of both needs and wants, while the end product still seems months (or longer) away from the pending reality that is the implementation and effective use of SharePoint.
As Project Manager, the first question to ask when defining SharePoint requirements is what initial functionality is needed to increase efficiencies. The Project Manager must explain to his or her project team and end users that SharePoint is not just a “thing” or “system”; rather, it is a collection of products, and it must be viewed by the business in the same way it views Microsoft Office.
Simply stating that the business “needs” document management is the same as saying the business needs Microsoft Word, a simple statement with a huge impact. What is the maturity of the business? What systems are currently in use? How is information being stored? How will you retrain end users?
In any requirements effort, it’s important to provide an appropriate amount of consulting, training and explanation in order to equip the business with the SharePoint knowledge to make the necessary requirements decisions. Henry Ford famously said, “If I had asked people what they wanted, they would have said a faster horse.” Before cars became a universal form of transportation, horses were the accepted method—it was the frame of reference people could articulate. To put that into the SharePoint context, if you don’t see the vision of SharePoint and understand what its capabilities are, how can you define your requirements?
Here are some steps to get your SharePoint requirements written right!
Engage the Entire Business: Start your project by holding a “town hall meeting” to generate some excitement about what SharePoint is all about and how it will move the company toward its long-term vision and strategy. Show some examples of where SharePoint has been deployed, and talk through how the implementation has changed that business for the better. This will plant the seed in the minds of business users as to how SharePoint can help, as well as draw ideas and thoughts that could lead to requirements.
Define Phase 1: The best way for companies to prepare requirements is to start with a core group of business participants who have been selected because of their knowledge and understanding of the corporate strategy and position. From their perspective, draw out high-level objectives that SharePoint will accomplish, whether that’s streamlining or converting document management, integrating BI, leveraging search, or increasing productivity and collaborating through the use of MySites.
Create a User Community: With the direction for the project now set, begin creating a user community that will be responsible for drawing out the requirements further. When creating the community, include participants who are new to the company as well as those who have been with the company for years. Hold a kick-off meeting to introduce the concepts and direction for the project, including the objectives for your requirements sessions.
Know Your Questions: Before holding your first requirements session, create a list of qualitative and quantitative questions that you’re going to pose to your users. Simply sitting down and asking what they want will surely end in frustration and failure for everyone. Defining the core processes and workflows that the business operates on will allow people to conceptualize what they do and how they can change or modify those steps in SharePoint.
Eric
