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?
#!
Environment: In order to create practical requirements statements, create the right environment for creative thought. As the PM or team lead, hold your session in a boardroom or conference room with ample wall space; have lots of sharpies and Post-it Notes on hand. Next, divide the room into sections identified as Business Requirements, Stakeholder Requirements, Functional Requirements and Non-Functional Requirements. By preparing the room as such, you’ll have created a structured approach to the creation of each requirement. Participants now must qualify each of their needs into a specific category where it is most relevant.

Structure: Invite participants to use one Post-it per requirement, and ask them to use as many words as possible to describe their need. This eliminates non-descriptive answers like “effective” and “user-friendly,” both of which have multiple uses and meanings depending on the author and the person responsible for interpreting the requirement.

Interact and Share: When you feel you have an appropriate number of Post-its on the walls (there is no maximum), begin reading through the requirements aloud. By reading them, you are building buy-in and adoption as your participants hear each requirement. After reading 10 aloud, ask if anyone in the room has a comment about what they have heard. Focus on eliminating a minimum of 20% of the requirements due to overlap or lack of necessity; remember that not all requirements are going to be aligned to the project’s focus.

Document: With the walls full of Post-its, being documenting the requirements in your tool of choice, such as Excel (though my personal recommendation is to create lists in SharePoint with the appropriate Content Types; use the Business, Stakeholder, Functional and Non-Functional headings described above). Then perform and complete your analysis on the ideas shared and requirements gathered. Remember that not each requirement is going to be possible for implementation. Some may be unnecessary while others may be best suited for another phase or project entirely.

Regardless of the documentation format you choose, circulate the information and ensure that stakeholders and end users alike have had an opportunity to review. In the past, I have seen surveys created to measure stakeholder feedback, which was a well-received method of feedback. Once you have feedback and you have categorized your requirements into the appropriate categories, you are ready to begin finalizing your list and moving forward to begin scoping the development effort.

Eric is the EVP of Systems Integration for Concatenate, a software firm focused on maximizing SharePoint through product innovation and systems integration based in Toronto. You can reach Eric by e-mail at ericr@concatenateinc.com or on Twitter at @rizinsights. Read his other SharePoint thoughts on his blog at www.ericriz.com.