Amerinet SharePoint Governance Plan
Figure 1
SharePoint Governance is: “the set of roles,
responsibilities, and processes that you put in
place in an enterprise to guide the
development and use of a solution based on
SharePoint products and Technologies.” –
Microsoft TechNet.
Adoption of SharePoint technologies can get
out of control without proper governance.
Managing SharePoint, like Project
Management, is concerned with the risks, costs,
and usefulness of the solution. We must strike a
balance between these goals, seeking a
managed path which is neither overly loose nor
overly tight. We cannot afford to exercise no
governance and have a broad adoption without
manageability, nor can we exercise heavy
governance which eliminates adoption. Here
are some of the items to consider in a
governance plan.
Figure 2
1
Below are some of the areas and items to consider when planning governance policy. Not all may need
to be actively addressed, but all should be considered for a comprehensive plan.
Project and Operational Management
Communication Plan (Who, When, What, How)
o Project communication has been established via a bi-weekly status meeting and
regular status reports to the governance team.
o Outages may be reported through the site, if available, or by calling or emailing
customer service who will notify the SharePoint Admin or Networking Support and
Marketing. The general staff will be notified via broadcast email by the Networking
Support team.
o New requests/enhancements should be submitted through the affected site in
order to forward to the appropriate contact person. If a specific site is not know or
applicable, then Marketing serves as the coordinating point of contact. Information
on requesting new sites will be published on the SharePoint Training and Support
site.
o New deployments may be communicated via broadcast emails and/or through site
announcements, usually initiated by the site collection owner or Marketing.
Identify Points of Contact
o Points of contact will remain as established for the project (see Project Roster) until
needs change. New sites will have a minimum of one preferably two site owners
which will act as points of contact for each site collection.
Deployment Process, for in-house and third-party
o Deployments requiring downtime need to be coordinated with Marketing for
content approval then the SharePoint Admin for scheduled deployment.
Change Management Process
o For the project, the project manager has been established as the change
management point of contact.
o For content-based operations, requests should go through their site collection
owner, if known. For enterprise/global changes, Marketing will act as the owner. For
implementations requiring server installation, new applications, or unknown needs,
Marketing will coordinate with the SharePoint Admin to assess impacts and needs.
Sponsorship (Satisfied by the pilot project)
Roles and Teams (Satisfied by the pilot project)
2
Site and Platform Classification (by # of users and longevity, and by type of use)
(see Figure 2)
o This pattern of classification will be used to establish operational policies as new
sites are identified. The currently planned sites have been defined as part of our
taxonomy exercises.
Define Service Level Agreements
o The SharePoint Server and environment will follow standard operating policy and
procedure for all networking systems. A 24/7 point of contact will be available for
global outages. Regular requests, sub-site outages, or performance issues will be
assessed during normal business hours. Support point of contacts will be Customer
Service for level 1 and Pittsburgh Networking Support for level 2.
Development and Configuration
Branding (Establish templates and master pages, determine what parts of templates and
sites may be modified and which may not.)
o Templates and user-modifiable areas will be developed by Marketing or designed by
Marketing and developed by IT, as the need for each arises.
Define what customization tools may be used and what actions will be allowed/not
allowed in the tools
o The SharePoint browser-web editor will be the primary means of
creating/modifying sites and features initially. SharePoint Designer may be used by
a trained web designer or developer for minor look and feel enhancements such as
applying cascading style sheets or designing and implementing custom master pages
for global sites, for visual enhancements only. Normal users will not have access to
this tool.
o Any globally-deployable development such as custom workflows, custom web parts,
or feature code customization will not be allowed at this time. Third-party web parts
or templates may be assessed/tested by the SharePoint Admin or trained web
designer. Custom development will be assessed on an as needed basis by the IT
development team, and will utilize Visual Studio and/or SharePoint Designer. No
other tools are currently authorized.
Establish guidelines for the development of site definitions and mechanisms for
coordinating ID usage.
o This will be a cooperative effort between Marketing and IT to be established as need
arises.
3
Communicate policies for site template deployment (e.g. requirements for globally
deployed templates)
o Custom templates using only default web parts and functionality may be created
and deployed by site collection owners at any time. User need to be aware that
custom templates are not directly supported by IT unless globally deployed or
unless submitted for testing and approval. Users should be educated via the
SharePoint Training site about the benefits and reasons for globally deployed
templates.
o Custom global templates using only default web parts and functionality may be
deployed by the SharePoint Admin upon request. The request should be approved
by Marketing prior to engaging the SP Admin if the template impacts the approved
Marketing content guidelines or is not included in those guidelines.
o Microsoft developed and supported templates, applications or features must be
assessed and tested by the SharePoint Admin in a test environment before being
installed to the production environment.
o Custom templates of any kind which use non-default web parts and functionality are
not currently supported. If the need for such is determined, then they must be
developed by, or at minimum submitted for testing and approval by, a qualified
SharePoint developer and deployed by the SharePoint Admin. Any custom
development must be properly documented.
Determine and document coding standards, testing and documentation standards
o These standards will be established by the SharePoint development team and will
follow industry best practice. Any custom development must be tested in a non-
production environment as well as be properly documented, including but not
limited to, an itemized description of the customization and support-related
information.
Establish guidelines for which assemblies may be installed to the Global Assembly Cache
and which may not
o This is not currently supported, but will be determined by the SharePoint
development team and communicated to the SharePoint Admin.
Infrastructure
(All initial infrastructural needs have been satisfied by the pilot project. Any future needs will be
assessed as growth occurs.)
Firewalls
Load balancing
Environments
4
Operational Concerns
Monitoring (server, site, and SP level)
o Site reporting services and logging will be enabled on both production and test
environments.
o The entire environment must be monitored for storage allocation, performance,
and usage volume by the SharePoint Admin and/or networking team.
o The entire environment must be monitored by the Marketing team for content and
feature usage, training needs identification, and taxonomy impact.
o Individual site collections must be monitored by the site collection owner(s). All site
collection owners (and above) must read the SharePoint usage policy, once it is
determined, which will specify appropriate use guidelines, quota allowances,
blocked file types, and the process for requesting exceptions. All users must read
the MySite appropriate use guidelines, once they are established.
Define responses to each type of failure that may occur
o The IT Team will define responses for potential failures as they are identified.
(See Communication Plan for notification process in case of failures.)
Define planned downtime/maintenance windows
o It is expected that regular maintenance such as Microsoft updates, patches, or
deployments requiring server downtime will be scheduled in advance and occur
approximately once a month in non-business hours by the SharePoint Admin.
o Maintenance which does not require server downtime should be planned in
advance, announced to all IT and Marketing staff, but may be performed during
business hours. Attempts should be made to perform this work during non-peak
hours in case of technical issues or performance impacts. This work would be
coordinated by the SharePoint Admin.
o Automated and regular nightly system activities will occur including backup, search
indexing, AD import/refresh, or other system activities. These activities should not
occur in the production environment during business hours due to performance
impacts. In the development or testing environments, performance impact should
be considered and other development, testing or SharePoint IT staff should be
notified prior to running.
Procedure for unplanned downtime and reporting issues, and response pattern
o Standard Operating Procedures for network system will be followed.
(See Communication Plan for notification process in case of failures.)
5
Disaster Recovery (single file, single/multi site, server recovery)
o Users may utilize the recycle bin for single file recovery. Single-file recovery for
items deleted from the recycle bin is not supported.
o Site collection owners, or above, may request a single site or site collection restore
from the SharePoint Admin.
o The SP Admin may restore sites, collections, content databases, or the entire farm
as needed. Impacts of restore processes will be considered and communicated in
advance to any impacted parties. A current backup should be run before performing
a restore in case of cross-site data contamination or data loss upon restoration. The
affected system area should be taken off-line if possible. This would not apply to
total global database failures, but would apply to global farm failures (e.g. the
content databases should be backed up).
Corporate records management requirements?
o The already established corporate records management policy will apply for all
SharePoint content.
Rules for archival of sites, including warnings and approvals
o The guidelines established in the email retention policy guidelines will be used as a
guideline for deleting or archiving workspace sites (individual one-time workspaces
such as meeting and document workspaces). Project sites will be archived a short
time (perhaps 1 month) after their implementation or project end date. Other sites
will be monitored for usage and when determined inactive (such as no activity in
over 6 months) the site owner will be contacted to determine if the site is still
needed. This policy will be reviewed and established by IT and approved by
leadership after implementation, when usage expectation can be better estimated.
Establish storage quotas by site type and process for increase requests
o The default quota assignments established by Microsoft will be utilized until a
different need can be determined. This includes no quotas on portal and team sites
and a 50MB quota limit on MySites.
Define recurring auditing reports, storage usage reports, activity-based reports for
administrators and business users
o The only currently known reports needed and available will be the site usage
reports. Additional report needs will be identified or assessed by the IT team after
implementation.
6
Education and Training
Initial Training (end user training, help desk, admin training and policy, developer and
designer training and policy)
o The training needs for the pilot project have been satisfied.
o Operational training will be performed at the time of roll-out and additional self-
training materials will be available on the SharePoint Training site.
Community Development (Forums, Face-to-face)
o A community development site will be included as part of the SharePoint Training
site collection.
o Face-to-face training may be performed by SME’s from the project group, site
collection owners as able, the Resource Center, or other members of the SharePoint
team as needed.
Renewal Training (based on periodic feature audits and new discovery)
o Upon new deployments or auditing discovery, training information will be given to
or developed by the Resource Center for staff training coordination. Any newly
developed training materials will be added to the SharePoint Training site.
Navigation, Taxonomy and Search
Site Directories (create site structures, including major groupings and linking strategy)
o We need to determine if a team sites directory will be needed in order to decide
whether team sites should be a separate application or under Division Portal areas.
We also need to determine if and how information may be shared (or published)
between any team sites and the company portal site.
o We also need to determine what, if any, additional site directories or personnel
directories need to be established.
Site categorization (home, landing portal, team site, personal site) and type (publishing,
collaboration, or personalization) (See Figure 2.)
o This categorization has been accomplished as part of our taxonomy planning
activities.
Define core content types and key fields
o There are no known content types of key fields beyond those already defined by
SharePoint by default. One possible addition might be “news releases”. No further
types have been identified yet. Additional ones may be identified after further
content development.
7
Establish content sources
o For the initial roll-out all content sources will be a manual entry effort and will not
duplicate any corporate database data or reporting, including but not limited to the
following application systems: Associate, Member Resources, CAM, CDS, Great
Plains, CIDS, Mango, PowerPlay, or Oracle ERP.
o The Pittsburgh and St. Louis intranet sites as well as the AME site will be
incorporated into and replaced by the new SharePoint intranet site. There are no
known Providence or Salt Lake intranet sites. Additional content sources may be
determined after initial implementation.
Search (determine responsibility for core relevancy settings, organizational enhancements of
the noise words file, thesaurus and keyword best bets)
o Initial deployment will include the standard default search settings. Additional
search refining, scope definitions, or added indexes may be determined based on
usage reporting or requests by the Search Team, Marketing, and/or the SharePoint
Admin.
8