Capability Checklist for Successful SharePoint

Successful deployment of SharePoint is no different than any other corporate strategy or project, only the moving pieces change. The goals remain consistency, scalability, and success by whatever measures you choose. It never fails to disappoint me to see "best practises" that restate project management principles without the salt or benefit of SharePoint experience (here's an example, though I don't recommend it). Give us the goods!

So to get it out of the way, here is every "Successful Strategies for Product X" article, presentation and book in a paragraph: You need shared vision, strong leadership as high up the food chain as possible, business-oriented goals and measures, clearly-defined scope, good communication, a crisp plan including risk mitigation and capacity to change, and effective delivery and support teams. During the build, you need to balance time, scope and available resources. Also like every other project (but perhaps not as common), an effective way to begin is to list the capabilities you need to simulate your business. Brainstorm on the common complaints or bottlenecks in your processes, and the capabilities or changes that would provide relief. You do not simply need "SharePoint," you need more effective teams, or bottom-up communication, or top-down communication, or document management, or records management, or alerting, or a corporate memory, or platform integration, or a place to collaborate with external partners, or some combination of these, or something else entirely. Declare these goals. Do a spell-check, hide the leftover red and green squigglies, and there you have it, go SharePoint!

Okay, time to get back to reality and be productive. The guidance below describes capabilities required to give good SharePoint.  Many are expanded to list the moving parts or the choices for providing the capability. Your plan is complete when every point below is accounted for.


Governance
Each of these roles can be expanded to a full team. Some roles use the general term "specialist" to refer to the architect / integrator / designer / mentor / lead role(s).

  • Senior leadership: A platform-agnostic Chief Knowledge Officer (CKO) or equivalent
  • SharePoint platform governance: standards oversight, project oversight 
  • Business process simulation, Platform integration: application specialist
  • Scalable navigation and discovery: taxonomy specialist, search specialist
  • Service level assurance: infrastructure specialist  

See also: What is governance?, Governance Resource Center for SharePoint 2007, Sample SharePoint Governance Plan, Increasing SharePoint Engagement (whitepaper)


Application Management
Project management principles are limited to initiation through delivery, when the reality is that deployment to production is Day One from everyone else's perspective.

  • Project planning: MS Project, Excel, SharePoint site
  • Team management: SharePoint site, Rally, VersionOne.
  • Team communication: Meetings, distribution lists, SharePoint site
  • Source Control: TFS, VSS, Vault
  • Bug Tracking: TFS, SharePoint
  • Reporting services: For usage tracking, search optimization, success metrics, health monitoring, capacity planning, and more. Examples include SQL Reporting Services (SSRS), MOSS BI, PerformancePoint, or homegrown 
  • Business Continuity and Support: are broken out into separate sections (below)


Business Continuity
How to keep it up, or fix it when it breaks.

  • Deployment Log: The capability is to rebuild a farm manually if ever required. This is a log per farm that includes server roles, server configuration, upgrades and application deployment history.
  • Database recovery plan: SQL mirroring and/or log shipping (http://msdn.microsoft.com/en-us/library/ms187016.aspx)
  • Server recovery plan: for each server or server role in the farm. E.g.: ghosting, backup/restore software, virtual server management
  • Server Health Monitoring and Capacity Planning: Operations Manager, intelligent load balancing, Tivoli monitoring
  • Application Health Monitoring: Operations Manager, home-grown health checks

See also: Microsoft Best Practices Analyzer for WSS 3.0 and MOSS 2007.


Environments for build, test and release
The capabilities are more important to cover than the names or numbers. Typically there are four platforms named Development, Integration, Testing and Production. The reality is that all the capabilities below are necessary, though their locations and permissions will vary.

  • Development Local (from best to worst: a farm, server, or web application per developer),
  • Development Integration (a shared development and debugging farm),
  • Development Demo (a farm always in a ready-state for early user feedback),
  • Development Sandbox (an experimental sandbox where ideas can mature into prototypes or production-ready templates),
  • Operations Integration (a clean integration environment with a change management process),
  • Operations Load Testing (as identical with Production as possible),
  • Operations User Acceptability Testing (test suitability-to-purpose),
  • Production Content Staging (optional, to take collaborative load off production),
  • Production Passive or Replicated (for failover or redundancy),
  • Production Active (the live server)


Planning

See also: Performance and Capacity Planning Resource Center (TechNet), SharePoint Monitoring Toolkit, SharePoint Security: Hard limits and recommended practices (Eli Robillard).


Application Development

  • Build Team: Central team(s) specializing in SharePoint development
  • Standard instruments for technical documentation
  • Review and sign-off process for technical documentation
  • Consistent Practices: namespace definition, VS solution structures, code syntax standards, internal naming or documentation standards, deployment packaging standards
  • Virtual machine management: Standard VM hosting strategy, standard VM images, and a plan for the patching and upgrading of the standard image(s)
  • Standard development toolset: IDE, project templates (e.g. STSDEV), CAML query analyser, object mocking, build automation (MSBuild, CruiseControl), deployment packaging, unit testing, data population, load testing, troubleshooting (e.g. SPM or SPI), assembly analysis (e.g. ILDASM or Reflector), HTTP analysis (e.g. Fiddler), logging (e.g. a ULS log provider, Log4Net, MSFT Enterprise Library)  
  • Standard development library: myCompany.SharePoint namespace library, business object classes, project templates
  • Testing: Code, Integration, Load, Suitability to Purpose
  • Review and sign-off process for development [Sample code acceptance checklist]

See also: WSS Developer's Center, SharePoint Developer Portal, Paul Andrew's (awesome) SharePoint developer training resources, How to build a SharePoint Dev Box (Eli Robillard).


Support
You've gone live, the URLs are published, a project pipeline is in place,  now what?

  • Communication Plan: The best way to avoid confusion is to tell everyone, by role: what is going on, how it affects them, and what they need to do to get on board.
  • Hosting Team: A team dedicated to SharePoint infrastructure, with a PM to manage the project pipeline, and one or more people assigned to each project whose role it is to facilitate onboarding  
  • Application Support Team: Central team(s) to maintain the code-base
  • User Support Team: Central team(s) to provide end-user support
  • Peer support for Workers, Champions, Developers, Support, Network Operations: Team Sites, Role-oriented knowledge sharing sites (e.g. learning tools, best practices, Q&A facilities)
  • Training Curricula: a combination of books, online courseware, and either an internal training team or a consistent training partner
  • Recognize success. There is no need to award vacations to your biggest contributors, any stroking of collaborative egos will do.

 
Other Resources


No Comments