Writing the right requirements — Part III

By Eric Riz

January 17, 2012 — (Page 1 of 2)
This is the third and final article in my series on “Writing the Right Requirements.” (Read Part I and Part II if you haven't done so already.) If you have been reading this series, you have learned about engaging the business unit, defining a user community, and creating a phased approach to your SharePoint project requirements. Thank you to those who have reached out and provided feedback on their thoughts and successes; I look forward to receiving more notes and meeting some of you at SPTechCon.

This article focuses on strategies toward effectively creating and documenting your requirements into meaningful, tangible, actionable statements. Note that I have written this from the perspective of deploying portal functionality to the business first.

A common practice in requirements sessions is to get the team together and to simply talk through how your existing portal or intranet operates, while an analyst sits in the corner and furiously attempts to capture the information. Though this approach is unstructured and takes a strong project manager to control the session, it can uncover some valuable information on the high-level needs you’ll want to build into SharePoint. The difficult part will be documenting the information in a format to appropriately leverage the information and have it be useful in the overall process.

In order to have meaningful and result-driven requirements sessions, follow these steps to success:

Plan: The adage “measure twice, cut once” is relevant when planning and executing requirements sessions. Spend time measuring the needs of business users and the strategic objectives the business wants SharePoint to provide. Create a schedule that shows when and where participants should meet, the details of the meeting, and the anticipated outcome for each session; also, be sure to invite participants well in advance to ensure their availability.

Finally, when planning your meeting, set each session up for no more than two hours. Enforcing the two-hour rule ensures that participants are fresh and remain interested in the conversation.

Discuss: Start the session by outlining your objectives and expectations to the group. Show some sample portals that have been developed in SharePoint (e-mail me for screenshots) to build excitement for what you’re about to undertake. Discuss the importance of having transparency in your communication, and that each point is a steppingstone toward a formidable SharePoint solution. Then begin by asking some high-level questions to generate thought and feedback. How will the portal change the day-to-day work completed by staff? How can you best leverage portal functionality to empower users?

Related Search Term(s): requirements

Pages 1 2

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

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

Writing the right requirements — Part I In order to define the right requirements, one must first obtain the proper frame of reference from team members

Add comment

Name*
Email*
Country

Compose

Writing the right requirements — Part III

By Eric Riz

Related Articles

Add comment