BPC: How to Best Gather Requirements for SharePoint Projects

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:

SharePoint Online

The cloud parts are functional components that extend your SharePoint Online environment in Microsoft 365.

Supports Classic and Modern sites for SharePoint Online/Microsoft 365

Small Business Pricing and Discounts

SharePoint

Top SharePoint Online Products

Experience greater power and savings by bundling our SharePoint apps and cloud parts.


Calendar Plus


Chart Plus


Knowledge Base


Project Management Central


Simple List Search

 

On-Premises Only

These web parts extend SharePoint beyond its out-of-the-box capabilities by tailoring it to your requirements with Bamboo Solution’s growing portfolio of SharePoint Web Parts.

SharePoint 2016, 2019, 2022 - Classic Pages Only

SharePoint

Top On-Premises Only Products

Experience greater power and savings by bundling our SharePoint apps and web parts.


Calendar Plus


Data Viewer


Password Change


Password Expiration


Password Reset

 

ur team of Microsoft 365 Technology Consultants helps you get the most out of your Microsoft technology, we have the best Microsoft 365 talent to streamline your organization.

Consulting to Streamline Your Department

M365 Plus

Managed Services

Microsoft 365

Consulting to Streamline Your Department


Human Resources


Information Technology


Marketing Campaigns


Healthcare


Sales

 

Our Consultants Have What You Need

Federal Contractors