Defining Requirements for SharePoint Deployments
A chief advantage of Microsoft SharePoint is its flexibility, but that also can make drafting requirements for a first deployment a bit overwhelming.
For that reason, documenting internal requirements and writing a request for proposals for a first SharePoint implementation should follow the KISS principle: Keep it simple, stupid. SharePoint requirements are further complicated because Windows SharePoint Services (WSS) and Microsoft Office SharePoint Server (MOSS) are both applications and an architecture.
As an application, SharePoint has document management, portal, search, business intelligence, workflow and records management features that can be implemented straight out of the box.
As an architecture, SharePoint can be used for building applications that take advantage of these foundational features. It can be customized. It can be re-skinned. It can be integrated with anything, if you have the time and the budget. Plus, numerous third-party add-on components quickly extend SharePoint’s off-the-shelf functionality.
Incremental Rollout
“When people first experience SharePoint, they see all the different functionality the platform and the architecture offer. They want to turn it all on at once,” says Evan Callender, a senior architect with West Monroe Partners, a provider of business and technology solutions with offices in Chicago; Columbus, Ohio; Dallas; Montreal; New York; Seattle; and Toronto. “We think the first set of requirements should be kept intentionally simple. Rolling out SharePoint incrementally is an easier way to start: Begin with an out-of-the-box deployment, then move into more advanced features as users get used to the system.”
As a start, Callender recommends building a SharePoint sandbox for the development team, beginning with a few out-of-the-box features, then adding more complex functionality as the development team becomes comfortable with configuration and change management processes.
Build a Proof-of-Concept
Once a development sandbox is up and running, the next step is to get SharePoint in front of users as soon as possible in a pilot or proof-of-concept environment.
“This can just as easily be done by putting Web Parts on a page in SharePoint and actually letting the user play around with it a little,” says Callender. “If you are planning on using as much out-of-the-box functionality as possible in order to maximize value, this can show users the true functionality and let them start thinking about how their processes and needs fit in. If addressing document management and moving documents from file shares or other systems to SharePoint, this is a good time to do a content review and archive unused or old documents.”
Solve Immediate Problems
When writing requirements, focus on fixing the immediate problems, says Dux Raymond Sy, managing partner of Innovative-e and author of SharePoint for Project Management.
Dux gives the example of a human resources department where employees show up on their first day of work and must wait a day for a desk and computer.
“The HR team will acknowledge that the execution of the onboarding process is broken” because of poor technology, Dux says. “They know this process inside out and most likely would agree that it’s not executed well since most of the information is being handled via e-mail and stored in a network share. With this pain point in mind, we can then define the specific requirements and can certainly map it to an appropriate SharePoint solution [such as custom lists and workflows] that can address this challenge.”
Trim Requirements to the Bare Bones
Joel Oleson, SharePoint blogger and senior product manager for Quest Software, isn’t afraid to push back when collecting requirements for SharePoint.
“At first, users are going to want to change the look and feel of site settings, or change the buttons, look of the breadcrumb or silly things that are very difficult to do,” he says. “Again, don’t be afraid to set expectations and push back. Some changes are trivial, and some would put supportability at risk”
Oleson describes SharePoint planning as an 80/20 process. “If you are drafting requirements, you’ll find that SharePoint can do 80 percent of them out of the box, and quite well. The other 20 percent is a decision of buy versus build,” he says. “But don’t forget there is actually a third choice: Skipping that requirement is often the best choice because SharePoint development is a serious commitment. You are committing to supporting that customization or those development assets throughout the lifecycle of the web application. That burden is often shared not only by the development team, but also by the support and operations team.”
Others disagree about allowing users to try out SharePoint early in the requirements definition phase. B.J. Pohl, vice president of development for Waterfield Technologies, a subsidiary of Affinity Financial in Irvine, Calif., emphasizes that if “the process is not properly understood and/or documented, then the focus should be on the business requirements, not the technology. The technology can be a distraction to the larger goals of the project in many cases.”
Build the Right Team
End-user involvement is crucial to understanding the business problems that you are trying to solve. One-on-one interviews or group discovery sessions between end users, analysts, project managers and developers are helpful for drawing out requirements.
“In writing the RFP, you want to have technical people involved from a development side, so the requirements listed are clear, correct and detailed enough for a response,” recommends Callender. “The analyst should be involved from a business-needs definition and ensuring that their processes and requirements are expressed correctly. Finally, the project manager should have an overall understanding of the RFP, even some understanding of what the project looks like in order for there to be some budget number that is targeted.”
Plan for Training
Mike Watson, senior product manager with Quest Software, thinks planning should be included as part of the initial requirements phase.
“Users typically don’t understand how to effectively leverage SharePoint. Ensure that all users receive training, and that trainers provide practical examples of how SharePoint can improve current business processes,” says Watson.
The more the business learns about SharePoint, the more valuable it becomes to the business.
For that reason, Quest’s Oleson suggests SharePoint deployments be planned as a platform with a road map. Write the RFP as simply as possible, starting with a few features, and pilot the environment to gain experience with it.
“Many first SharePoint RFPs are over-engineered, and too many assumptions are made too early in the process,” Callender says. “With your first SharePoint deployment, starting simple is important because it is difficult to get people to change the way they work. If you change too fast, people will continue to rely on e-mail and file shares. SharePoint is a game-changer, but like any game-changer it must be introduced only as fast as your end users are capable of accepting it.”
