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.