SharePoint Deployment and Governance

Governance for SharePoint is not a checklist of administrative settings or server architectures. Rather, it is a set of policies and procedures that work together to minimize risks and create a set of predictable outcomes at every stage of your SharePoint deployment. I’d like to show you a new framework for SharePoint governance described within the recently published book, SharePoint Deployment and Governance using COBIT 4.1: A Practical Approach (ISACA). Chapter 1, Chapter 2, and Chapter 3 of the book, and a final section on SharePoint in the cloud, can also be found on Microsoft TechNet. An online tool that can be used to track progress and the information associated with the governance framework outlined within this article is scheduled for release in spring 2011.

Our exploration starts with a case study of an ungoverned SharePoint deployment and the unexpected effects that can follow. I then review the Control Objectives for Information and Related Technology (COBIT) governance framework and show how it has been applied within SharePoint. Next, I provide a specific set of actions you can take to start governing your SharePoint deployment. Finally, I list some recommendations to govern SharePoint in the cloud.

What Happens Without Proper Governance Practices

Deploying SharePoint can spawn unexpected results when you don’t prepare the organization with proper governance practices. In 2008, I was leading a SharePoint consulting group for a large, national system integrator. A billion-dollar clothing manufacturer asked us to create a plan to use SharePoint 2007 to automate the creation and approval of refund checks that were created after distributors returned unsold merchandise to the company.

When we were called in, we found a check request and approval system that was a manual process using email to move Microsoft Word and Excel files among different approvers and the accounting team. This important business process resulted in millions of dollars of refund checks per quarter. Each refund request typically required five to eight weeks to process–this last point is very important to our case study.

My team was selected as the integrator of choice for this effort, which represented the manufacturing firm’s first deployment of SharePoint. The system was developed and rolled out in 12 weeks, and the time to process refund checks was cut from several weeks to just a few days. Everyone was happy. The system worked great, and the new SharePoint solution streamlined processes even more than first anticipated.

Several weeks later, my phone rang. It was the CFO, demanding a meeting immediately with the internal project sponsor and my team. "Your system just made me miss my number for the quarter! We cut too many refund checks too quickly and your system negatively impacted our cash position. Fix it, or I will rip out the whole system and go back to manual processing."

We hadn’t expected that result. We had optimized the process too much. Now we needed to get the system governed to match business requirements, so we put in place technical and process fixes to slow refund processing down and regulate how quickly refund checks were issued.

Guiding Principles

This is just one example of why you need to look at the system holistically within the context of the organization and the relationships between all components and systems affected by SharePoint. Governance of SharePoint has to be led by business and enabled by IT.

Time and again, I’ve seen organizations of all sizes trying to understand SharePoint after it has been deployed without any idea of what problem it was supposed to have solved. Setting up SharePoint and saying to the business, “Come on in,” always results in a jumble of disjointed, one-off sites, ghost towns with stale content and no visitors. This approach also increases exposure to risk because nearly everything is indexed and searchable. Also, IT is often ill-prepared for the wave of support and enhancement requests and the usage spike that we and others have called the “SharePoint Effect.” Clearly, some kind of framework that takes all of these factors into consideration is needed. That framework is commonly referred to as governance.

My real-world experience leads me to conclude that SharePoint governance should be based upon the following principles:

•     Business needs should lead technical decisions, not the other way around.

•     SharePoint requires controls and repeatable processes to ensure its orderly deployment, operation, and maintenance.

•     A team of senior business and technical users is required to set policies and procedures and to guide the ongoing deployment of SharePoint.

•     Management reviews should be built into governance policies and procedures.

•     IT resources, including staff and systems, should be leveraged and integrated into SharePoint.

•     The framework should be built upon internationally recognized governance standards.

•     The framework should be applicable at any stage of deployment or maintenance.

Such a framework is COBIT, created by the Information Systems Audit and Control Association (ISACA). Let’s look at COBIT and how it has been applied to govern SharePoint.

COBIT

COBIT provides a framework that enables IT and business owners to work toward common goals while identifying and controlling risks associated with IT initiatives. It’s a publically available framework that’s constantly revised and in its fourth version. It builds on a framework that defines four domains to govern IT systems: Plan and Organize, Acquire and Implement, Deliver and Support, and Monitor and Evaluate.

Divided among the four domains in COBIT are 34 processes, high-level directives that form the goals for each domain. For example, the Plan and Organize domain includes the following ten processes:

•     P01 Define a Strategic Plan

•     P02 Define the Information Architecture

•     P03 Determine Technological Direction

•     P04 Define the IT Processes, Organization, and Relationships

•     P05 Manage the IT Investment

•     P06 Communicate Management Aims and Direction

•     P07 Manage IT Human Resources

•     P08 Manage Quality

•     P09 Assess and Manage IT Risks

•     P10 Manage Projects

Each process has a set of suggested activities called control objectives that either mitigate risk or contain specific guidance or activities designed to help meet each facet of that process. For example, process P02, Define the Information Architecture, has the following four control objectives:

•     P02.1 Enterprise information architecture model

•     P02.2 Enterprise data dictionary and data syntax rules

•     P02.3 Data classification scheme

•     P02.4 Integrity management

COBIT gives you a comprehensive checklist of procedures and objectives to think about at every stage of your SharePoint deployment. It satisfies all requirements of the principles above.

Applying COBIT in the Real World

After attempting to apply COBIT “out-of-the-box” to a few SharePoint deployments, I decided that its processes needed to be rearranged outside of their domains and placed within phases that more closely mirrored the lifecycle of a SharePoint deployment. In SharePoint Deployment and Governance using COBIT 4.1: A Practical Approach, all 34 COBIT processes are spread across phases of an iterative software development lifecycle as shown in Figure 1. We tailored control objectives to meet the specific needs of a SharePoint deployment for each of the 34 processes. Consider the four control objectives that are defined for the DS1 Define and Manage Service Levels process, which is listed in the Plan for Launch phase in Table 1):

A.   Develop or review service level framework

B.   Define services and service level agreements for SharePoint

C.   Define searching requirements, including scope and result set

D.   Define index requirements and schedule

As you drill into each of the control objectives, specific actionable items are listed in a prescriptive fashion to guide your governance effort. For example, examine how the objectives for DS1-D Define Index Requirements and Schedule have been tailored for SharePoint:

The Steering Committee is responsible for setting the schedule when indexing occurs. The SharePoint index service can do a full or incremental crawl of the specified content stores. The Steering Committee is also responsible for setting how often a full crawl is performed rather than an incremental crawl.

These control objectives are a starting point rather than a comprehensive list of every possible objective for that CobiT process. There can be many more items that are specific to your environment.

A matrix pulls it all together, listing the maturity of all control objectives within each deployment phase and procedure (a small part of the matrix is shown in Figure 2). The cells that are darkened indicate the tool listed at the top of the column can be used to meet the control objective. Finally, each of the darkened cells has a maturity model behind it (see Figure 3), creating a scorecard with a calculated value of meeting the objective to the organization.

Implementation: Getting Started

The framework and all the procedures and control objectives are explained in the book, so don’t worry if this article seems a bit much at your first reading. More importantly, let’s look at how we can use the framework to start governing SharePoint.

Step One: Meet with Key IT and Project Management Staff

The governance process begins with a meeting of key IT resources participating in the SharePoint initiative. This meeting should be conducted in a workshop setting that can span multiple sessions. The following items provide a general guide to what should be accomplished with IT staff in this meeting, prior to meeting with key business stakeholders:

1.   A SharePoint governance champion should be identified to guide the initial governance activities outlined within this section. This will often be a member of the IT staff or an outside consultant. The governance champion will be responsible for all of the activities leading up to a self-sustaining SharePoint governance framework and steering committee.

2.   The governance champion should begin the governance initiative by identifying all of the relevant staff associated with SharePoint and their roles. These individuals are likely to be later assigned to infrastructure, support and development teams, or to the steering committee in alignment with the objectives of COBIT 4.1.

3.   If SharePoint has been deployed, a survey should be created of current SharePoint sites, including a site map. Also, any documentation associated with the current deployment should be reviewed. This is similar to COBIT 4.1 process PO2, Define the Information Architecture.

4.   Significant risks to adopting governance for SharePoint should be identified, which might include

•     Inadequate executive sponsorship and direction

•     Unwillingness of IT to align or support business needs

•     Inability of the governing body to make decisions

•     Internal staff or third parties not following the policies and procedures set by the governing body

•     IT staff lacking discipline to follow policies and procedures

•     SharePoint being deployed widely across the organization, and current users being resistant to governance because they do not understand the risks or costs of the current ungoverned approach

•     The business demanding service levels not possible within the allocated budget or technology

•     The business demanding system features and functionality not possible within the allocated budget or technology

5.   If SharePoint is currently deployed, the current content stored in SharePoint should be reviewed. The comprehensive list should include who uses the content and what document retention schedules are in place.

6.   A list of business initiatives that have been requested by business and that are considered “in scope” by the IT department for the SharePoint deployment should be created. If SharePoint has already been deployed, the list should contain initiatives that are desired and should include key stakeholders associated with each initiative.

7.   An operational review should be conducted. A representative sample includes the following:

•     Backup requirements—A review of backup and recovery requirements and practices should be conducted for any existing or planned SharePoint initiatives. This activity begins building information required to meet control process DS4, Ensure Continuous Service.

•     Backup practices—If SharePoint has been deployed, a review of backup practices for existing SharePoint deployments should be conducted. This activity also builds information required to meet DS4.1.

•     Review of cost allocation—This activity includes an overview of how costs for SharePoint are or will be allocated to system users.

•     Review of how change requests are managed—This activity encompasses change request management including how requests are logged and how they are evaluated.

•     Review of security—This activity includes a review of security requirements and how these are implemented or planned to be implemented.

•     Review of training—This activity encompasses a review of training materials and training plans that are currently in place and planned.

•     Review of Help desk processes—This activity includes a review of the Help desk capabilities and processes currently in place.

After the workshop, the following activities should be completed with IT leadership. These should be done prior to a final follow-up meeting with the entire IT team:

Findings and risk assessment review. A review of the collected data should be summarized into a written report that identifies the maturity of the current SharePoint governance process and outlines the risks currently facing the organization. This report should be reviewed with the IT team to validate findings and agree upon readiness and the desired next steps to implement SharePoint governance.

Decision to proceed with governance initiative. A frank discussion should be held with the IT leadership team to assess the organization’s readiness to proceed with implementing governance for SharePoint. Any key impediments identified in the workshop should be evaluated and mitigated or compensated for prior to embarking upon the governance initiative. If the impediments are deemed significant enough to stop the governance framework, a plan should be devised to overcome each item prior to beginning.

Preliminary scorecard. If the decision to proceed with the governance initiative is approved, a preliminary effort to complete a scorecard (see Figure 3) should be undertaken. The scorecard should track governance progress and highlight areas requiring additional attention. A preliminary survey should be conducted to assess the current state of governance using the maturity model control scorecard.

Plan. A scope and timeline indicating which portions of the COBIT 4.1 framework will be adopted, including approach and timing, should be developed. This plan should be shared with the business units participating in the governance initiative to get their buy-in and input.

Tools. A review of tools required to govern SharePoint should be compiled.

Budget and plan. A preliminary budget and plan should be developed so that funds and resources required for the effort can be allocated.

After these activities have been completed, and if there are no significant impediments remaining, the organization is ready to begin the governance process in earnest.

Step Two: Meet with Key Business Stakeholders

After the initial meeting with IT staff outlined in step one, key business stakeholders should be invited to a workshop to review findings and create the management team for the SharePoint governance initiative. Items to review should include key findings, such as business impact, and associated risks and costs of the current or proposed SharePoint deployment and plan. The activities involved in this step include:

Hold a workshop. Key business stakeholders and IT staff should be invited to the workshop by the SharePoint governance champion to review the findings outlined in step one. Candidates selected as key business stakeholders should be reviewed and added to a pool of prospects for the SharePoint governance steering committee. This begins to build the list of candidates required to satisfy one of the objectives of process PO1 Define a Strategic IT Plan.

Create a steering committee. After the candidates for the steering committee have been identified, the SharePoint governance champion should review the candidates and form a list of steering committee members. These candidates should be notified and given the opportunity to accept or decline an invitation to join the steering committee, and a meeting should be set.

Hold the initial steering committee meetings. After the team has been identified, initial meetings should be held to lead the governance initiative. Suggested sample agendas for the first three meetings can be found in the appendix of SharePoint Deployment and Governance using COBIT 4.1: A Practical Approach.

Step Three and Beyond

After a functioning steering committee is in place, attention can be focused on satisfying the requirements of the processes and controls needed to govern SharePoint properly. The steering committee should review the scope of the governance initiative and reaffirm its commitment to these goals.

SharePoint in the Cloud and in Hosted Environments

Governance is just as important for cloud-based and hosted SharePoint as it is for on-premises deployments. You need to consider the following:

•     The system will be operated by and cared for by staff you will likely never meet.

•     The provider will probably require concessions on your part if you are working in a multi-tenant environment. Specifically, it will limit what you can and cannot run in their environment. Particular care should be given to throttling considerations and the use of any server-side code that’s outside of the sandbox in SharePoint 2010, as it will likely not be allowed.

•     Back-up processes and service level agreements (SLAs) are generally standardized and not subject to a lot of negotiation without a substantial fee increase.

•     Particular attention should be given to monitoring capabilities. Cloud and hosted solutions will usually have strict service level arrangements that should be monitored closely as part of your governance planning. Provisions to access the data center and system statistics and logs should be included in your contracts.

These are just a few considerations that are outlined within the book. All of these considerations will have substantial impacts on the functionality and technological direction of the system and should be considered in your governance planning.

Maximum Benefit, Minimum Risk

A strong governance framework and adherence to it will help you realize maximum benefit for your SharePoint deployment while minimizing risk to the organization. COBIT 4.1 from ISACA offers the best governance framework currently available. Molding it to fit your SharePoint needs will help you successfully deploy and manage SharePoint whether on-premises or in the cloud.