SharePoint is like water. It can be anything and something and nothing. People want to box it one way, and other people want to box it another way, which is fine, except that nobody's on the same page.

—Dux Raymond Sy

Why do requirements and SharePoint implementations fail? According to Dux Raymond Sy, the answer is lack of relevant communication.

Speaking at the Best Practices Conference today on How to Best Gather Requirements for SharePoint Projects, Dux emphasized that communication is key in order for requirements to succeed.

"Why are requirements so difficult? They're not sissy work," he asked. The trick, he said, is understanding the word: Requirements are something wanted or needed. They're capabilities that are needed to solve a problem. They are formally written and documented; they identify constraints on a system, service, product or process. They are capabilities that are needed to solve a problem.

To begin developing the requirement, look at it from three angles:

1.    Business requirements: What is the business focus for this requirement? The organization's focus?
2.    User requirements: What's the user's focus?
3.    System requirements: What is the system focus? What are the hardware requirements, operating system requirements and so on?

Take what you've gleaned from the angles, Dux stated, and use that to define your business needs—this is a must.  

For example: Information workers spend 45 minutes each day searching for information. In a team of 20 people, that's 900 minutes lost each day. So what if search productivity can be increased by 15%? That's gaining back 7 minutes from the 45 minutes lost.

Then map those needs to SharePoint requirements, and be specific.

Business requirement: SharePoint shall increase user productivity by 15%.
User requirement: Users can retrieve search results within 5 seconds of submitting a search request that can support a max of 10,000 simultaneous search requests.
System requirement: The SharePoint server shall have at least 2 WFEs and a dedicated SQL Server that has at least dual processors.

A well-defined business need and a clearly mapped SharePoint requirement create a trail, Dux noted. If someone asks why IT is setting up two WFEs, you can point to the requirements for the explanation.

There are four key components to developing requirements, he shared:

1.    Eliciting requirements
2.    Analyzing requirements
3.    Validating requirements
4.    Documenting requirements

Requirements elicitation involves finding out what the stakeholders and users need, determining requirements sources, and deciding how to gather information. In other words, get your hands dirty—talk, observe, research.

Then make sense out of the information by analyzing the requirements. Profile the users and understand and determine what the real requirements are.

Validate the requirements by allowing the users to prioritize the requirements. Help them understand the true cost, resources, time and skills sets needed to succeed—and that they can't have it all. The scope needs to be limited and specific. Pick one process that you can solve, Dux stated, "and they'll get that this is a business platform."

Once you've confirmed the requirements, get them on paper by documenting the requirements. Dux points out that a requirements document doesn't have to be 20 pages, but it does need to include the requirements statement, process diagrams and a traceability matrix.

A requirements document should have specific content in a good structure, he said. "Specific content has to be measurable. You can't just say, 'It's very fast.'" Start with a subject, then the capability, then the criterion: SharePoint <subject> shall increase user productivity <capability> by 15% <criterion>.

In conclusion, Dux emphasized that every internal SharePoint implementation should be treated as a project, no matter how small. "Otherwise, no one takes responsibility," he said, and the implementation is unsuccessful.

For more on the Best Practices Conference, check out the agenda or follow the conference on Twitter using the #bpc10 hashtag. For more about Dux, visit his Web site or follow him on Twitter. To see his presentation on video, visit his slideshare.net page.

Check out our full coverage of the Best Practices Conference 2010:

• Dux Raymond Sy on 'SharePoint as a Gov 2.0 Platform'
• 'Enabling Social Media through Metadata' in SharePoint 2010 with Christian Buckley
• Mark Eichenberger on 'Making Social Networks Successful in SharePoint 2010'
• Managers' Quick Guide to SharePoint Server 2010
• Mark Miller Explains 'How to Build a Community in SharePoint'
• 'SharePoint 2010: An Administrative Odyssey' with Lori Gowin
• Building Solutions That Users Get
• 'Making SharePoint 2010 My Sites Work for Your Organization' with Michael Doyle
• Best Practices in Leveraging Microsoft Project 2010 With SharePoint 2010 for Project Management
• Building SharePoint Applications with InfoPath and SharePoint Designer with Darvish Shadravan
• SharePoint 2010 Workflow with David Mann
• Cathy Dew Answers the Question, 'SharePoint Branding – Where Do You Even Begin?'
• How to Best Gather Requirements for SharePoint Projects
• SharePoint End User Adoption with Kay McClure
• BPC Keynote: 'What the Masters Think About SharePoint 2010,' Facilitated by Spence Harbar
• Greetings from the Best Practices Conference! (AKA, Bill English Sets the Tone with His Introductory Remarks)
• The Coolest SharePoint T-shirt of the Year So Far
• Live Blogging Archives