I've spent the past several years as a business systems analyst on multiple SharePoint projects for clients across numerous industries. A wide range of functionality is made available to users simply by installing SharePoint. Understanding what the platform can deliver right out of the box will really help an analyst during enterprise analysis, solution assessment and validation, elicitation, and requirements analysis activities. However, gaining that subject matter knowledge can be real a challenge.

Over time, analysts often find themselves on projects utilizing vastly different technologies that they have never been exposed to before. Because of this trend, there is no doubt in my mind that the most valuable tool in the analyst's toolbox is the technology-agnostic analysis methodologies they leverage. On that note, the CapTech Business Analysis Center of Excellence is deeply-rooted in the framework and best practices of the IIBA and its guide to the Business Analysis Body of Knowledge (BABOK).

Without further ado, here are a few tips that I believe all analysts on SharePoint projects (especially their first project) can benefit from:

  1. Learn some of the Platform's Strengths & Weaknesses
    • Strength Examples
      • Document & Content Management
        • MS Office Integration; Workflow; Managed Metadata; Version Histories…
      • External Application Integration
        • App Model (SP2013); BDC/BCS; Sophisticated Development APIs; Lightweight Web Services/JavaScript; External Content Types
      • Social Features
        • Profiles; MySite; Likes/Tagging; Groups; AD/LDAP Repository Integration…
      • Business Intelligence
        • KPI Dashboards; Excel Services; Reporting Services…
      • Search
        • Search Scopes; Refinements; Contextual Search…
    • Weakness Examples
      • Lots of Features
        • Learning curve for new users
        • Expectations that SharePoint can do anything/everything right out of the box are not always met
      • Security Limitations
        • Impersonation not built in
        • Can be burdensome if not carefully planned
        • Typically, you do not want to store PII in a SharePoint list
      • Custom Workflows
        • Difficult to implement using Visual Studio
        • Third party tools can leave a large footprint on the environment
      • SharePoint Designer is Typically Not Production Safe
        • Hard to control access to SP Designer
        • If you do not let your developers develop on prod, do not allow your business users to develop on prod
      • Bulk Content Management
        • Cannot mass-approve/publish content
        • Datasheet is a little quirky and has several compatibility issues
  2. Get a Basic Understanding of SharePoint Information Architecture
    • Learn the differences between web applications, site collections, sites, and pages
    • Get a basic understanding of how content types and site columns can be used, extended, and where they should be applied
    • Learn about Lists, Libraries, and Views
    • Learn how to use several of the out of the box web parts
    • Become familiar with some of the basic SharePoint and FAST search capabilities
    • Learn the basics of SharePoint content/site security (Groups, Audiences, Permission Levels, and Inheritance)
    • Explore some of the navigation settings and site configuration options
    • The analyst does not have to be a SharePoint subject matter expert, but they will benefit from a high-level understanding of some of the platform's out of box capabilities
  3. Specify the What, Not the How
    • SharePoint requirements should be written just like any other requirements
    • Focus on the functionality, behaviors, and qualities that need to be delivered or adhered to
    • Be mindful of the potential impacts of using keywords/phrases that specify how functionality will be delivered using SharePoint (web part, page, column, view, layout, …)
      • I prefer to use these types of keywords/phrases in assumptions when they need to be stated
    • Restrain yourself from writing requirements that lead developers down implementation paths that you are more familiar with
  4. Learn to Quickly Identify Custom Functionality Requests During Requirements Elicitation
    • Time and resources can be saved during analysis activities
    • Helps with prioritization
    • Requires more knowledge of SharePoint platform
  5. Prototype Out of Box Solutions
    • Great way to train your business stakeholders on how to use SharePoint
    • May result in simplified solutions if prototypes are fully functional
    • Quickly gain approval on design and functionality decisions
    • Great for SCRUM/Agile projects
  6. Leverage Your Architect(s)/Implementation SME(s)
    • Architects are responsible for confirming technical feasibility
    • Architects determine the implementation approach for approved/validated requirements
    • Architects must verify all requirements before they can be validated and approved by the business stakeholders

Using these tips will help you to be more successful on your next Sharepoint engagement, and hopefully guide you away from some common pitfalls.