Design (Planning) Phase of a SharePoint Project

Written by Denis Stadler on . Posted in SharePoint 2010

The first, and probably most important, component of a successful SharePoint 2010 deployment is a thorough knowledge of the target organization and its business goals. As a solution designer, we must gather key business information to ensure that our solution reflects the requirements and goals of the organization.

Gathering Business Requirements

So before gathering requirements we have to prepare. We are going to use the envisioning document to identify the main business objectives (or project scope item) of our solution. Each objective has to be discussed in detail with the particular team or stakeholder.

Before attending the meetings we have to be prepared. We need to define a clear discussion schedule (with time constraints), key questions, eventually questionnaires and any other resources that might be useful.

Then we are going to have a separate meeting with all the teams’ representatives and persons which are responsible for each business objective.
We have to keep in mind that the our focus should be on identifying the details of business requirements, and of course the benefits of using a SharePoint solution rather than asking leading questions or focusing on the technical features of the product. A business stake-holder is going to buy value and benefits for his business and not the technical features of a product.

During these meetings it is compulsory to capture minutes of meetings in order to have the raw data to produce the design document. The following are considered to be common functional requirements:

  • Common functionality mapping is to be done directly to business processes. We have to ensure that we understand not only the task, but also the scope of the task. For example, there may be a requirement to tag documents consistently across an entire organization. Alternatively, tags may need to be unique in divisions. We may have to deploy a corporate information architecture taxonomy that is augmented by divisionally specific taxonomies.
  • The administration of departmental or project Web sites may be a core requirement. This can affect options such as site permissions or self-service site creation, for example. Authentication and authorization are always important in design. You must ensure that security is easy to implement and robust.
  • Your design must identify the potential interaction between systems, including authentication options. You should also identify any reporting requirements for divisions in your organization. This may be an important element of BI, which may not be a term that anyone in the business uses.

Gathering Nonfunctional Requirements

The most common nonfunctional requirements are: performance, capacity, scalability, availability, security, interoperability and business continuity.
Usually these requirements are going to be discussed with the IT stakeholder of your customer.

SharePoint Logical Architecture

After the information gathering is done we have to build the SharePoint solutions’ logical architecture. Basically we have to map both business and nonfunctional requirements against the solutions’ features.
Now it’s the moment to go throughout all the SharePoint hierarchy: Server farms -> Service applications -> Applications pools -> Web applications -> Zones -> Content databases -> Site collections -> Sites -> List and libraries -> Items.

SharePoint Documentation

With this process done we have to produce some deliverables:

  • The design document
  • The UAT (User Acceptance Tests) document

The design document should contain:

  • Logical architecture design
  • Service application architecture design
  • Physical design
  • Security and authentication design
  • Metadata design
  • Application design:
    • Search
    • BI
    • Content management
  • Operations and maintenance
  • Business continuity

Anyway please take into consideration that you should create an easy readable documentation in plain English (or other language ) as long as it is possible.

I have to insist on checking the SharePoint IDP Solution Accelerator (link to the parent page here) from Microsoft because it is a good place to start. Check the entire document and use it’s annexes to gather information.

Other information about SharePoint Design can be found at the addresses below:

Both of these documents have to be reviewed with the customers’ team and signed by the project sponsor and stakeholders.

Tags: , , ,

Trackback from your site.

Denis Stadler

I'm a technology enthusiast, with more than 10 years of experience in SharePoint and Dynamics CRM projects. To find more details about, please visit the about me page.

Leave a comment

*