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
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.
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)
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
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)
How to keep it up, or fix it when it breaks.
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)
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
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)
See also: Performance and Capacity Planning Resource Center (TechNet), SharePoint Monitoring Toolkit, SharePoint Security: Hard limits and recommended practices (Eli Robillard).
- Build Team: Central team(s) specializing in SharePoint development
- Standard instruments for technical documentation
- Review and sign-off process for technical documentation
Practices: namespace definition, VS solution structures, code syntax
standards, internal naming or documentation standards, deployment
- 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).
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.
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
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.