Writing the right requirements — Part I

By Eric Riz

November 23, 2011 — (Page 1 of 2)
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!

Pages 1 2

Share this link: https://sptechweb.com/link/36132

Writing the right requirements — Part III Getting your requirements in understandable and actionable statements is a critical step toward implementation

Writing the right requirements — Part II In this installment, Eric Riz explains how to get the most input from everyone involved in the SharePoint deployment

A lesser-known Web Part connection option Selecting data from one Web Part can automatically perform an action on the data in a connected Web Part

Add comment

Name*
Email*
Country

Compose

Writing the right requirements — Part I

By Eric Riz

Related Articles

Add comment