SharePoint Governance--Scope Phase

Si applica a: SharePoint Server 2010

Ultima modifica dell'argomento: 2010-06-15

The following is an excerpt from the book "SharePoint® Deployment and Governance Using COBIT® 4.1: A Practical Approach," which can be purchased at www.isaca.org book store.

The scope phase is highlighted in figure 5.

Guiding principle: Do not “build it and they will come.”

Too often, we have seen technical teams offer a SharePoint “solution” without identifying what business problems it will solve. This is usually done under the guise of providing a shared service model. Do not deploy a SharePoint solution that only needs to find a problem to be successful.

Overview

A SharePoint deployment should be focused on solving real, concrete problems, improving productivity or enabling new ways to help the business thrive. To ensure this, the scope phase of this SharePoint governance framework starts with establishing a steering committee of business and technology leaders who can set broad goals for the SharePoint deployment.

Once formed, the steering committee solicits communication and reviews feedback from the business to define the business goals and objectives that will be met by the SharePoint deployment and the business units that will participate in the rollout. Next, key business and technical resources are identified. The scope phase concludes by setting the initial information architecture and site map of SharePoint.

Key activities in the scope phase include:

• Creating a steering committee led by the business and enabled by technologists

• Identifying key strategic objectives the business will attain by deploying SharePoint

• Identifying business units and champions to guide deployment

• Aligning objectives and goals with SharePoint capabilities

• Setting priorities

• Developing a preliminary information architecture, including a site map

The remainder of this chapter explores how CobiT® processes can be applied to the SharePoint governance during the scope phase. This section includes key activities and deliverables that should be completed during the scope phase of this SharePoint governance framework.

PO1 Define a Strategic IT Plan

The effort begins with creating a steering committee to define what is planned to accomplish and prioritizing objectives. Our recommended implementation of the PO1 Define a strategic IT plan activities is shown in figure 6.

PO1.A Create a steering committee to guide deployment—Scoping should begin with the creation of a steering committee. This team will provide overall strategic guidance for the SharePoint deployment. Business, technology and geographically diverse representation on the team is ideal. Membership should be temporary and voluntary. Tactical direction of IT is included within the membership. (Note: Each SharePoint site will have its own local administrator, typically the site administrator, who will manage SharePoint locally and escalate issues up to the steering committee as necessary.) Sample agendas for the first three meetings of the steering committees can be found in appendix A.

Steering Committee—Some Thoughts

The steering committee should be thought of as the command-and-control center of the SharePoint initiative. Some of the tasks listed in this governance guide are quite technical and specific to SharePoint while others are more general in nature. The steering committee should appoint subcommittees to assume responsibility for many of the technical aspects of the SharePoint deployment and operation. It is unrealistic to think that members of the steering committee will be able to manage all aspects of the guidelines presented. Governing SharePoint will take a considerable effort. In the end, the steering committee will be responsible for the successful deployment and operation, but it will need to delegate and trust specialists to succeed.

Author’s Mindbite—The steering committee is like launch control.

Most readers have watched a National Aeronautics and Space Administration (NASA) rocket launch. Each system is managed by a group and, as launch approaches, a series of preflight activities is followed with each group reporting to the launch director. The scene a few moments before launch sounds something like, “Electrical?” “Electrical ready for launch.” “Propulsion?” “Propulsion ready for launch.” “Guidance?” “Guidance ready for launch.” and so on.

It is much the same for a SharePoint launch and operation. All business and information technology teams should coordinate their efforts with the steering committee as preparation for launch and operation occurs. All of the players involved perform a choreographed set of steps outlined in this text under the steering committee’s guidance. These steps ensure that preparations are complete and SharePoint is operating as planned to meet the objectives and goals set forth by the business.

Steering Committee—Leadership

The steering committee members will not individually complete every activity in this guideline. However, just like the mission team at NASA, the steering committee is responsible for setting the SharePoint deployment goals and ensuring that all systems are “go” to meet them.The steering committee should have a strong leader who can break deadlocks and provide direction when discussions become tense or emotional. We call this style of leadership a “benevolent dictatorship.” Discussion should be animated and forthcoming, but a strong leader is needed to resolve disagreements and keep the committee on task.

Steering Committee—Mission Statement

The following is a suggested mission statement for the steering committee:

The steering committee will provide a unified, centrally governed approach to the SharePoint environment. This team has the overriding authority for all architectural, design and development decisions, including all policies and procedures created for the SharePoint environment. It will strongly influence foundational and framework-related issues, as well as decisions regarding security and retention considerations for the deployment.

Steering Committee—Scope

The following areas will be considered by the steering committee for inclusion in the governance plan:

• Internal/external users, internal/external data sources and inputs/outputs

• Personal, team, departmental, divisional, corporate, global considerations

• Parent/child corporations, subsidiaries and affiliates

• Technologies, processes, logistics and finances

• Document retention policies

• Cultural, political, religious, social, economic, and gender forces and influences

• Security and access control of the SharePoint environment, both internal and external

• Legal and cultural issues concerning content of the SharePoint system to address information rights management, copyright and other legal issues, privacy issues, and offensive or inflammatory material

Suggested Steering—Committee Team

The table in figure 7 lists an example of a steering committee for a public agency.

Steering Committee—Communication

A communication plan from the steering committee to the enterprise as a whole is an important responsibility of the team. The steering committee should maintain a web site with minutes, announcements, membership, instructions on how to join, calendar, forms to report bugs and issues, forms to request enhancements and new initiatives, and instructions on how to get support. The web site should include information on usage policies and restrictions. Additional activities will speak to this point in greater detail throughout this publication.

PO1.B Identify strategic goals—Once the steering committee has been formed, scoping begins with the identification of big goals that guide SharePoint deployment across the enterprise. Examples include:

• Better communication

• Document management

• Improved compliance

• Improved auditing capabilities

While these examples include broad enterprise goals, we have also seen SharePoint launched to address a specific problem within a department. The activities defined in this governance framework are equally important for focused outcomes and should also be followed, as shown in figure 8.

The scope of the SharePoint deployment may grow quickly once users in other areas learn how it is being used. If this happens, it is advisable to review and follow the steps outlined in the enhancement phase of this publication.

PO1.C Identify business units participating in the project—The business units that seek to be included in the deployment must be reviewed and screened for inclusion by the steering committee, as shown in figure 9. Business units can be nominated by the steering committee or may apply to the steering committee directly.

PO1.D Identify strategic needs and map to SharePoint functionality—High-level strategic needs should be collected via use case scenarios for each request. Each use case should be identified with a unique ID tag for simplified tracking. These use cases should be reviewed by technical staff to determine whether the business needs can be met with the technical capability of SharePoint.

A list of items that appear to be difficult or costly should be noted for each use case. A report of findings should be presented to the steering committee and a subcommittee should be created to evaluate the technical reviews.

Finally, a summary of findings and recommendations should be made to the entire steering committee for each use case. The steering committee should then create a list of functionality for each department that is considered in scope, as shown in figure 10.

PO1.E Identify key business owners for each initiative—Each business initiative approved by the steering committee will have a business owner associated with it. This business owner will assist with requirements development, champion the initiative with the steering committee and help with the deployment as needed, as shown in figure 11.

PO1.F Set priorities—Each business initiative will be ranked by the steering committee and set within the queue of work. The steering committee will be responsible for maintaining and monitoring a master schedule showing initiatives that have been approved and reviewing the initiatives on at least a quarterly basis. Key considerations when setting priorities include:

• Level of effort

• Dependencies on other SharePoint initiatives in process

• Infrastructure requirements

• Third-party product dependency

• Staff availability

• Business readiness

• Training availability

PO2 Define the Information Architecture

Once the initial scope of the business needs has been identified, the information architecture should be defined. The information architecture includes the type of site (including the degree of exposure to the rest of the SharePoint system, as well as security requirements), owners, roles and publishing life-cycle requirements, as shown in figure 12.

PO2.A Identify scope and site types in deployment—Once the scope of initiatives has been defined for the current phase, a site map should be developed that identifies each site and its relationship to the entire farm. The site map is a critical step in defining the functionality and scope of the SharePoint initiative. This effort should be managed by the steering committee. The site map will be consulted regularly as requests for enhancements and changes are made.Governance should be tightly controlled in areas where there is substantial public exposure in terms of readership (whether internal or external) or potential litigation issues. In areas with limited readership or public exposure, governance may be less controlled and allow for a more decentralized empowerment of end users. Farm administrators will generally defer to direction from the business for features and content-related issues. A typical site map is illustrated in figure 13.

Sites are generally classified using two dimensions: exposure and functionality. Exposure is defined as how manyusers can see the site, while functionality includes what can be done with the site. Site exposure (who can see it)dictates many of the requirements.

Sites generally fall into one of the following broad categories:

• Public landing page—These are pages that anchor entry into SharePoint. All content is generally public and accessible to all users on the site. This means great care must be taken to produce policies and procedures that govern who can post content and how content is posted. Content on this site has the highest need for controls around review and approval prior to publication. An inappropriate content posting at this level will produce the greatest risk to the enterprise and the greatest impact to the business. Each SharePoint farm typically has only one landing page, although there could be many if the farm serves multiple populations (a public Internet site and an intranet site on the same farm, for example). Access to site management and content editing and posting should be extremely limited, and regular auditing and approval of access and content posting are critical.

• Public product line, location or divisional site—These are pages that are public anchors for product lines, locations or divisions. These are also very public sites and therefore have a very high requirement for control, review and approval of content prior to publication. There are usually many of these per farm.

• Public departmental, topic or product sites—These are public sites that are focused on specific departments or products. While control is still very important, fewer people will see these pages than either the landing or product line pages. It is likely that many users may make these “favorites” in their browsers so these sites also have a very high need for control, review and approval prior to content publication. There are usually many of these per farm.

• Private departmental, topic or product private sites—These are sites that have a limited number of named users or workgroups of users who can access the site. Control is less important in these sites since the audience that can see the content is much more limited than the audience for public sites. There is a medium level of control required for these sites.

• Wikis and blogs (web logs)—SharePoint 2010 includes rich capabilities for sites built around wikis and blogs. The audience for this type of site varies widely from sites targeted at small groups of users to sites that are available to the enterprise as a whole. Conceptually, these sites facilitate bidirectional knowledge sharing and the aggregation of additional information around a particular topic. Active participation using threaded discussions and content submission directly to the site is likely to be easy to do and highly encouraged.

• Private project sites—These are very private sites, with access limited to a few users working on a specific project or initiative. These are “workbench” areas that are rarely seen by anyone outside the immediate group working within the site. Since access is typically very limited, control is usually relaxed, with light supervision and virtually no need to approve content posting. Nearly everyone with access to these sites should be able to add content as needed.

• MySites—MySites are usually used for social networking or resource skills inventories. Although there is a temptation to have relaxed controls, these sites should be reviewed regularly and a formal content publishing policy and review cycle are probably worth considering since these sites are readily available to a wide audience. MySites require medium review and secure editing capability.

Author’s Mindbite—Content control and Janet Jackson?

The 2004 US football Super Bowl halftime show with Justin Timberlake and Janet Jackson was seen by millions and discussed by even more. This halftime show included Janet’s infamous “wardrobe malfunction,” which was broadcast live to millions of viewers and caused great debate and 200,000 complaints to the Federal Communcations Commission (FCC). The CBS television network was fined US $550,000 and the MTV television network was banned from ever producing another Super Bowl halftime show. This relates to the amount of control placed on the content posted on the most public sites. The more people who see the site, the greater the exposure to risk and sanctions when inappropriate content—a wardrobe malfunction—is posted.

PO2.B Identify owners—All sites must have at least one owner who can edit and update content and, in some cases, the structure of the site. Site owners should be centrally managed and cataloged for security reasons. A site inventory grid is shown in figure 14.Typical site owners of each type of site include the following:

• Public landing page—Farm administrators and selected marketing and communications staff

• Public divisional farm—Selected marketing and divisional staff

• Public department and topic sites—Selected department staff

• Private department sites—Selected department staff

• Private project—Selected project staff

PO2.C Identify roles—Roles are closely aligned with permissions in SharePoint. Users should be associated with roles for each site they can access. Tools should be employed to allow centralized monitoring and maintenance of users and roles by site. Typical roles of users include the following:

• Farm administrator—Responsible for configuration, administration and maintenance of the farm

• Site owners—Typically can add or delete any content and layout as well as assign security for a site

• Contributor—Can usually add, update or delete content but not change the functionality or the layout

• Reader—Has read-only access to a page or site

A site role grid is shown in figure 15.

Typical permissions can be set at the following levels:

• Farm

• Site or page

• Web Part (list)

• List item (or file)

This means that files can be excluded or “filtered” at the document level so certain users cannot see them. Permissions are also honored by the search service, such that search returns can be filtered as well. Roles can have permissions set at a very granular level. It is imperative that a tool be employed to manage, set and revoke permissions at the global level from the SharePoint central administration console. A list of recommended tools to automate creating lists of users for each role for each site can be found in appendix B.

PO2.D Develop a process for site requests, approval and creation with auditing, including content types and permissions—A process should be created, and supporting documentation developed, for requesting, approving, and creating or decommissioning sites. The process should also include a description of required content types, required permissions and SharePoint groups required to support the site. The process should start with a request from a user, which should be routed to the proposed site owner. The application should be reviewed, with approval or rejection determined by the steering committee.

SharePoint 2010 delivers new capabilities that should be considered during the site request or modification process:

• The ability to add data validation rules for properties at the item level and list level. For example, rules can be built that disallow an end date that precedes a start date. Properties can now be specified to be unique as well. These rules should be captured during this activity.

• Content types are now available at the farm, not just at the site collection level. Content types that are managed at the farm level can be extended at the site collection level by inheriting from the farm-level content type. The use of content types that inherit at the farm level should be encouraged to promote simplified searching and an additional value to the business.

• Users can now set unique document IDs that follow a document wherever it is stored in SharePoint document libraries. The use of unique IDs should be used to avoid broken hyperlinks if a document is moved.

• Users can now designate that a file stored in SharePoint is an official file that can be locked and any changes to the file disallowed. This practice should be considered if SharePoint is acting as a system of record for files.

• SharePoint 2010 can now support up to 50 million items per list. This added capability can have performance consequences related to search capabilities. Any sites with large lists should be carefully planned. Items to include in planning are what properties can be searched upon and how many results are to be returned in the query result set. An additional option is the ability to throttle the system to allow large result sets to be available only during certain time periods of the day. These decisions need to be considered in conjunction with the business and clearly communicated to the user community or the help desk will become flooded with assistance calls, inquiring why the search is not returning expected results.

Not all sites will require approval by the steering committee. Generally, the less controlled the site, the lower the need for formal review and approval. Simple, private team sites will generally not require approval to create or decommission. The creation and tracking of auditing entries showing who approved each process and when it was approved are important for regulators to assess compliance control. These logs should be maintained and reviewed regularly.

Tools are available to automate the request, creation and deletion of sites via a workflow. Sharepoint Designer offers power capabilities to create sites and set permissions. Additional third-party tools to facilitate site creation via a workflow can be found in appendix B. A sample workflow built by Nintex® Workflow 2007 is included in figure 16.