Microsoft SharePoint Best Practices: Governance and Adoption Planning Organizations that have watched their unstructured content proliferate over the past decade are eager for tools to manage that content. For many organizations, Microsoft Office SharePoint Server (MOSS) is the tool of choice: a way for both large and small businesses to solve everyday content management problems for everyday users. MOSS has much to offer: ease of installation, ease of use, flexibility, and robust scalability not to mention the potential for high user adoption. There s a caveat, however. While MOSS does present the promise of content management for the masses, deploying it effectively and with a long-term, sustainable efficiency requires an enterprise strategy. We ve seen many organizations roll the product out to individual departments, then struggle to consistently leverage the growing multitude of SharePoint sites and content. Without proper governance in place, it s an approach that only perpetuates the existing information silos within an organization. So if your organization is strategically planning to go with SharePoint as a part of its approach to managing information, what should you be doing to take this long-term approach? Doculabs has worked with a wide range of organizations as they bring SharePoint into their technology environments. In this white paper, we provide a set of best practices for MOSS implementations designed to help you leverage the product s considerable enterprise capabilities, while not putting additional burdens on your IT group. Let s face it: the goal is greater adoption of content management but not at the expense of greater overhead for the organization. Find out what you need to do to get the greatest value from your SharePoint investment. 2007 Doculabs, 200 West Monroe Street, Suite 2050, Chicago, IL 60606, (312) 433-7793, info@doculabs.com. Reproduction in whole or in part without written permission is prohibited. Doculabs is a registered trademark. All other vendor and product names are assumed to be trade and service marks of their respective companies.
2 Doculabs White Paper Introduction Doculabs surveyed the registrants of the 2007 ECM Solutions Seminar on how their organizations are deploying MOSS 2007. Some of the key findings: More than 70 percent of organizations have or plan to have installations of some version of Microsoft SharePoint. A majority of the organizations surveyed already own a variety of ECM systems. Fewer than 10 percent of organizations surveyed have a working plan in place for how SharePoint will be deployed in conjunction with their other existing ECM systems. Most organizations that have deployed SharePoint treat it like a core part of their infrastructure analogous to email, network infrastructure, storage, and backup and recovery. This white paper is intended for organizations that have deployed or are planning to deploy SharePoint as part of their approach to managing unstructured information. For guidance on how to leverage the content management capabilities of both MOSS 2007 and advanced ECM solutions as part of a multivendor strategy, see Doculabs white paper, The Co-existence of Microsoft SharePoint and Advanced ECM Platforms: What You Need to Know, at www.doculabs.com. As the volume of unstructured content on enterprise file shares continues to grow, users are becoming desperate in their demands for simple, easy-to-use document services what we know as basic, content-related functionality. For many organizations, Microsoft Office SharePoint Server 2007 (MOSS) is the answer: an easy way to deploy content management to every desktop. The numbers are impressive. Those enterprises with traditional deployments of enterprise content management (ECM) solutions typically achieved desktop penetration of less than 10 percent; for those investing in MOSS, however, we expect MOSS to reach a desktop penetration of more than 50 percent. It s easy to see why. MOSS is simple to install; it can be used virtually out of the box. It provides nearly limitless flexibility all delivered with a user-friendly interface that feels just like Microsoft Office to end users. And unlike earlier versions of the SharePoint product, MOSS provides document management, e- forms, and basic workflow. While it s not a substitute for more specialized ECM systems (particularly for larger or more complex organizations), MOSS can certainly provide considerable value to many organizations and for a lot less time and money. There s a problem, however. MOSS provides no out-of-the-box governance mechanisms to manage the proliferation of SharePoint sites and the result is that the benefits just mentioned can easily become liabilities. Once MOSS is installed and users have been given access, the ease of use, flexibility, and high user adoption can lead to an uncontrolled, unsupervised growth of sites across the organization. We ve seen it happen before, with network file shares, Microsoft Exchange public folders, and Lotus Notes all implementations that promoted localization and decentralization. In the absence of proper governance, the outcome is likely to be the same: insular silos of information, each managed with its own file structure and navigation, and inaccessible to other users throughout the organization. What is proper governance for a SharePoint deployment? How can you roll out MOSS to address the content management needs of your users, taking advantage of the usability and flexibility of the SharePoint product, while also providing the policies, procedures, and guidelines that will ensure enterprise availability of your information assets? And how can you plan for SharePoint adoption and meet the demand for content services, while reducing the time and effort required by IT? Doculabs has developed this white paper to address the needs of organizations that are planning to use SharePoint as part of their strategy for managing their unstructured information. In this white paper, we provide an overview of the best practices you should take into consideration as you deploy MOSS whether as an upgrade from previous versions of Microsoft s SharePoint products (such as Windows SharePoint Server), or as a completely new, greenfield technology implementation.
Microsoft SharePoint Best Practices: Governance and Adoption Planning 3 Which SharePoint are you talking about? Unless otherwise indicated, Doculabs uses the terms SharePoint and MOSS interchangeably throughout this white paper to refer only to Microsoft Office SharePoint Server 2007 Enterprise Edition. However, we use the term SharePoint products to refer to more generally to all versions of SharePoint: 1. SharePoint Team Services 2. SharePoint Server 3. SharePoint Portal Server 4. Windows SharePoint Services (WSS) 5. Microsoft Office SharePoint Server 2007 (MOSS) Standard Edition 6. Microsoft Office SharePoint Server 2007 (MOSS) Standard Enterprise Edition SharePoint Team Services is an older product line that has evolved into WSS. SharePoint Server and SharePoint Portal Server are older product lines that have been rolled into MOSS. WSS is available as a free add-on to Windows Server, and can be best thought of as MOSS Lite. It has much of the basic functionality of MOSS, but also has some critical limitations that should be weighed heavily against the cost of upgrading to the full functionality of MOSS. MOSS is available for purchase as part of the Microsoft Office Server suite. Although both the Standard and Enterprise editions offer benefits over WSS, the functionality provided by the Enterprise edition is substantially greater than that of the Standard edition.
4 Doculabs White Paper Governance Define a governance framework for MOSS that provides for ongoing management and maintenance of the implementations. Regulations, Compliance, and Governance Regulations are external constraints on an organization, such as SOX, HIPAA, or SAS-70. Compliance is an entity within an organization responsible for adherence to regulations. Governance refers to the processes that Compliance uses to help the wider organization adhere to regulations and involves three core activities: 1. Creating policies, procedures, and guidelines 2. Monitoring adherence to policies, procedures, and guidelines 3. Correcting deviation from policies, procedures, and guidelines We all know how easy it is to install MOSS and begin creating SharePoint sites, with the rich, out-of-the-box functionality the product provides through its templates and wizards. So it may come as a surprise to some organizations that a truly successful enterprise deployment of MOSS requires as much governance as more specialized enterprise content management (ECM) or business process management (BPM) applications do. When it comes to these other enterprise applications, we tend to regard governance as absolutely necessary largely because of the size of the investment in the technology. Then there is also the complexity of installing, configuring, and operating an enterprise ECM or BPM application. In comparison, the initial cost of MOSS is low, and it s possible to install, configure, and operate the product with little forethought and, in our experience, that s exactly the way most organizations have been going about it. What they don t take into consideration is that the cost of an ungoverned MOSS implementation will quickly rise. As the number of sites expands, the number of users grows, and as the volume of unmonitored content and transactional data that gets stored in SharePoint increases, MOSS becomes increasingly costly to maintain, whether in terms of network and infrastructure, help desk support, or monitoring its use to ensure compliance with regulatory requirements. Doculabs Opinion In terms of MOSS, the two factors that impact governance most strongly are: Functional capabilities: what MOSS will be used for in the organization (for example, basic or advanced repository, team collaboration site, e-forms, workflow). An organization looking to implement MOSS as a basic repository to replace their shared drives and Exchange public folders faces less complex governance challenges than one looking to use MOSS to manage collaboration on business records or to deliver e-forms to customers. Regulatory environment: the sources and types of regulation the organization is subject to (for example, federal, state, or industry; SOX, HIPAA, Export Compliance, SAS 70, ISO 9000). An organization that must comply with regulations such as HIPAA or Export Compliance faces more complex governance challenges than organizations that operate independent of such constraints.
Microsoft SharePoint Best Practices: Governance and Adoption Planning 5 The figure below shows the ways that regulatory environment and MOSS functionality intersect, with recommendations for what to consider in each case. For example, for highly regulated organizations seeking to deploy a wide range of SharePoint functionality, Doculabs recommends heavy IT and compliance involvement, longer cycles for both QA and user acceptance training, and risk assessment; an organization in a less regulated industry deploying minimal SharePoint need perform only basic risk assessment prior to deployment. Project Risk Figure 1: Project Risk Profiles tied to Functional Capabilities and Regulatory Environment
6 Doculabs White Paper Policies, Procedures, and Guidelines Develop specific policies, procedures, and guidelines for MOSS usage. Successful policies and procedures must balance what ought to be done, with what can reasonably be done. Having detailed, wellcrafted policies and procedures that cannot be adhered to because they are impractical can expose an organization to as much risk as having no policies and procedures at all. It s critical, therefore, to factor in the constraints within your organization when planning and implementing policies and procedures to make sure that what is mandated can actually be adhered to. Don t assume that because you have a Records Management department, or because you have an enterprise ECM system in place, that all the policies and procedures will be appropriate for MOSS. Existing policies and procedures are a valuable starting point (and Doculabs highly recommends that you leverage them), but your organization should build upon them to address the particular requirements of MOSS. We ve just discussed the need for governance mechanisms in SharePoint deployments, to manage the growth of sites and prevent the creation of information silos across the organization. But if you want to leverage the benefits of MOSS while avoiding its liabilities, it s also important to put MOSSspecific policies, procedures, and guidelines in place and enforce them effectively. Users need to know how information is to be created, used, and retained within MOSS and what information should (and should not) be kept there. Policies and procedures for the management of information in MOSS is an area where planning and thoughtful execution is critical. Organizations that haven t made this effort upfront are beginning to notice productivity losses as their users are unable to retrieve key content, and some will likely face potential fines and legal action for improper lifecycle management of their content. Doculabs Opinion In order to develop effective policies and procedures related to managing the lifecycle of your information (whether with MOSS or any other system) you need to consider the following characteristics of your different types of content: Longevity: How long does (or should) a given piece of content exist in the organization? Business record: Is the piece of content an official business record? Accessibility: How accessible does the information have to be? Is immediate access critical, or is offline storage with a next-day retrieval time acceptable? The answers to these questions are the basis for creating policies and procedures both for managing a given piece of content within one or more content management systems and for controlling how users will access or work with that content. The idea is to implement policies and procedures for MOSS that encourage the proper storage of information so that it can easily be retrieved in the future and so that information you are required to retain is maintained and accessible for the appropriate retention period (and no longer). Ultimately, an organization that invests time and energy in creating and enforcing MOSS policies and procedures tied to the information lifecycle has a good foundation for eventually developing an automated information management system that can tag content as vital business records, automatically move content from expensive near-line storage to offline storage (based on age or usage), and perform automated document disposition or archival based on records management rules, among other things. So how do you get started developing policies and procedures for effectively managing the information lifecycle in MOSS?
Microsoft SharePoint Best Practices: Governance and Adoption Planning 7 Step 1: Take an inventory of the major categories and types of content that will eventually be created, updated, or otherwise managed by or through MOSS. Step 2: Define what specific information is expected to reside in or be managed through MOSS both now and in the future. Also identify the external, non- MOSS systems that will likely interact with MOSS. This interaction could simply consist of the generation of reports stored in MOSS, or rules-based migration of content from MOSS to an ECM repository, or it could be full, user interfacelevel integration within a portal interface, for instance. With these two steps done, you are ready to tackle the creation of policies and procedures that reflect the content inventory and content rules you defined in Steps 1 and 2. The figure below shows a simple example of the type of classification that can be done once you ve completed the inventory of content categories and types. In this case, the various content types were classified in three categories: ad-hoc content, process-driven content, and critical business records. Note that each of these categories is not exclusive; information can exist in more than one category. As a result, the categories must be given precedence. In this case, the most stringent conditions the rules associated with critical business records will be applied first to any content that may also belong to other categories. Next, the conditions for process-driven content management will be applied, followed by the rules for ad-hoc content. The top band of the figure, Content Lifespan, shows one type of condition that may be applied to content in each category. In this case, the figure shows when content is to be migrated from MOSS to another ECM after a defined amount of time has elapsed. In the case of ad-hoc content, the information may reside 90 days or more in MOSS before it is transitioned (if it is moved at all). In the case of critical business records, the content is transitioned within 30 days the date it s created or updated. This approach can be applied to create a workable information lifecycle management framework that functions with MOSS. Figure 2: The Role of MOSS in the Content Lifecycle
8 Doculabs White Paper Information Organization Make the development of a taxonomy an integral part of planning and executing a MOSS implementation. A taxonomy is A classification scheme groups related things together to aid search and retrieval A semantic dictionary uses a fixed vocabulary obvious to users; provides common terminology to aid communication A knowledge map with a structure that represents the topical domains it covers Some mission-critical uses for taxonomies: Organize content and aid navigation on web sites, intranets, shared drives, portals Support discovery efforts by applying consistent index structures to paper file rooms, file cabinets, shared drives, Microsoft SharePoint databases, document management systems Facilitate collaboration among staff in a single work group or across an entire global enterprise For more information on what it takes to create and implement a taxonomy, see our white paper, Ten Questions on Taxonomy, at www.doculabs.com. In many organizations, ECM systems remain departmental. The result is information silos self-contained departmental repositories that prevent crossdepartmental sharing of information. Unfortunately, the way that MOSS is being implemented in many organizations today presents the very real danger that even more of these information silos will be created. Thus, to be successful with MOSS, a taxonomy is required. A taxonomy allows you to address where and how content is stored in advance. Unlike a search tool, which attempts to locate information after the fact, a well-thought-out enterprise taxonomy provides a structure that helps your users put things in the right place the first time, greatly easing subsequent retrieval and allowing your organization to make optimal use of MOSS (and any other tool you may deploy to manage content). The problem is that in many cases, efforts to improve information organization on MOSS when undertaken at all are too late: a taxonomy should have been developed ahead of time. Doculabs Opinion Information organization is a fundamental part of a MOSS implementation that, like infrastructure or security, cannot be neglected without having a substantial negative impact on the final deployment. The most critical information organization need for any MOSS implementation, no matter the size of the organization or total number of users, is in using taxonomy to design the enterprise site hierarchy. Site hierarchy is a consideration in every MOSS implementation, because MOSS imposes almost no constraints on how users can structure their site collections. Other than deciding whether sites will inherit site settings from their parents, users are free to create whatever groupings of site collections they feel will meet their needs. What we ve seen at many organizations is that, in the absence of centralized planning, the MOSS enterprise site hierarchy grows asymmetrically across the organization, as each department or workgroup makes different decisions about how to organize its site collections. The result from an enterprise perspective is a cumbersome mess of repositories that s impossible to navigate, let alone impose key enterprise functions such as governance, capacity management, compliance enforcement, and litigation discovery. It s déjà vu all over again: the same problem so many of us had with departmental shared drives or the proliferation of Lotus databases.
Microsoft SharePoint Best Practices: Governance and Adoption Planning 9 When you roll out MOSS, you need to define standards for 1) the location of the top-level site, and 2) the placement of site collection groupings. The figure below shows the range of possibilities open to you even if you simply choose to use your current org structure as the basis for your MOSS site hierarchy. Depending on your organization, it might make sense to define the top-level site at the enterprise or business unit level and then work downward to functional departments. However you choose to define them, though, such standards help to ensure that the structure of your MOSS sites does not develop independently of your organizational chart (which can lead to an unmanageable tangle of unrelated site collections) or in blind adherence to it (which can lead to a collection of sites that is well organized, but that nonetheless fails to meet user needs). What s needed instead is an enterprise taxonomy view of your organization, which provides a representation of enterprise work and work products that allows you to evaluate the suitability of using your current reporting structure for the basis of your MOSS site hierarchy, and that also provides alternatives if you determine that a different structure is needed. Figure 3: MOSS Enterprise Site Hierarchy Considerations mapped to Organization Structure
10 Doculabs White Paper Solution Packages Reduce time and effort to get organizational units up and running by identifying common solution packages for deployment. Chargeback models for SharePoint deployments Users perceptions of how they are being charged for services strongly influence usage patterns and behavior. Depending on how your organization wants to govern user behavior, consider some combination of the following chargeback models for your SharePoint implementation: Capacity model: This model charges departments by how much data they store in SharePoint and has the effect of discouraging kitchen-sink MOSS repositories. Features/functionality model: This model charges departments by the level of SharePoint capabilities they are provided (e.g. document management, e-forms, workflow) and encourages need-to-have vs. nice-tohave tradeoffs to simplify MOSS rollouts (see Best Practice 4 in this white paper). Per-user model: This model charges by the number of users in a department and discourages blanket access, thereby simplifying site management. Access/security level model: This model charges by the level and/or range of access rights that is granted within a department s SharePoint deployment, discouraging excessive administrative privileges and simplifying governance and enforcement. We talk to IT people in a wide variety of organizations, and most of them are facing an onslaught of requests in their project queues: requests for the development or provisioning of web sites, collaborative spaces, and business applications. In most organizations, the reality is that resources and funding are not sufficient to even begin addressing the number and breadth of these project requests. Within many IT shops, the methods and approaches traditionally used to deliver IT projects are no longer adequate to meet the demand. One of the strengths of the MOSS product is its template functionality, which allows users to build SharePoint sites with very little effort, using a site template as a starting point. From an enterprise perspective, this template functionality allows you to deploy predefined solution packages i.e. fully-developed site templates designed to meet specific sets of user needs, with as little customization as possible. Everything from look and feel, to navigation and folder structure, to security groups and access levels can be established in the template and provided to users, right out of the box. So how do you go about developing MOSS solution packages? Doculabs Opinion The primary factor to consider is the characteristics of the requests that IT is receiving. Today, many IT shops face requests that range in complexity from simple requests such as adding security rights for a user to view a MOSS site, all the way up to requests to build complete applications with integrations to enterprise resource planning (ERP) systems and legacy systems. To define effective solution packages, you need to understand what the majority of your users will want from MOSS. And it s critical to consider users in the broadest terms: not just general business users, but the IT users who will be supporting MOSS, as well as the governance users (compliance, legal, and records managers) who will be monitoring its compliance to corporate policies, procedures, and guidelines (see the Governance section of this white paper). For example, it s not enough to determine that business users want team collaboration sites and then go about designing a set of team collaboration templates that meet their needs. The perspectives of IT and the governance function also need to be considered in any MOSS project. Any team collaboration solution packages that satisfy business users should also make it easy for users to comply with enterprise standards around documents, internal communications, and information security; otherwise, those solution packages won t meet the needs of governance. Then there are your organization s established service levels for performance, storage, and help desk support (among others) that IT must adhere to. The team collaboration packages must be able to be supported at these levels; otherwise, they don t meet the needs of IT.
Microsoft SharePoint Best Practices: Governance and Adoption Planning 11 Solution packaging can be rolled out with varying degrees of sophistication, from simply making two or three basic templates available on demand, all the way up to designing a portfolio of template types that provide a wide range of functionality linked to a chargeback model (see sidebar on preceding page for some chargeback models for MOSS). But regardless of how complex the solution packaging program is, defining solution packaging requires the following steps: 1. Select the business activities to be supported by MOSS. 2. Gather requirements for these business activities and develop corresponding usage scenarios. 3. Review the usage scenarios and map them to MOSS capabilities to determine the ratio of out-of-the-box functionality to additional functionality that will be required for each. 4. Group the usage pattern scenarios requiring the same types and levels of functionality together to create a set of solution packages. The figure below shows a list of sample solution packages, categorized into two tiers. Note that each tier can then be associated with chargeback costs, based on the service levels and the user/client support levels required at each tier. So if your organization needs to incorporate solution packages into its chargeback model, you would then take the above process a couple of steps further: 5. Develop tiers of MOSS functionality (i.e. bundles of solution packages) and the levels of security/access to be associated with each tier. 6. Determine the relative costs of supporting each tier (hours, third-party licensing, etc.) and develop a pricing schedule accordingly. Tier 2 Tier 1 Figure 4: Sample Tiers of MOSS Solution Packages
12 Doculabs White Paper Automated Provisioning Provide a mechanism for controlled self-provisioning of MOSS sites by users. Some Unintended Consequences of a Successful Provisioning Program Once provisioning is made easier and (in some cases) more automated, solution package deployment will begin to take on a life of its own, sometimes with consequences that you didn t anticipate and never intended, such as: Spikes in email traffic of unpredictable magnitude as a result of MOSS-related automated notifications Increased system calls to Active Directory to support MOSS security, access, and data requirements Increase in the complexity of your capacity planning, as the mix of MOSS services (Microsoft Exchange, Excel, Office, SQL) that s required to continue to meet user needs is unknown at any given time There are some obvious and significant advantages to using provisioning options, but keep in mind that there are also some disadvantages and those disadvantages tend to be less obvious, but no less significant. As with most MOSS best practices, implementing successful provisioning models means striking the appropriate balance for your own organization. Service-based models for IT development and deployment offer a far more agile approach to how IT departments provision and deploy technology. An organization can leverage these ideas very effectively with MOSS, which drastically reduces the level of custom development needed to roll out sites (and therefore the amount of IT services required) and also increases the likelihood that MOSS can be implemented rapidly and cost-effectively throughout the organization. Once you ve defined a set of solution packages, you may find that some packages require less IT involvement than others to implement. Designing a multi-tier provisioning model is a way to standardize the delivery of solution packages based on complexity so that simpler packages can be provided with little (or no) IT involvement. A provisioning model also reduces the amount of ad hoc deployments, i.e. deployments undertaken entirely by business units without IT s knowledge. So what might be the tiers of a multi-tier provisioning model? 1. The simplest requests could be handled by users themselves through a selfprovisioning program that lets users request solution packages (by filling out an online request form, for example), and then provides those packages with no human intervention. Examples of good candidates for self-service requests would be adding simple security rights for users in a particular MOSS site, or the provisioning of a temporary MOSS collaboration site. 2. More complex requests can be delivered through a rapid provisioning model, which would require the assistance of an IT specialist. This approach makes sense for configuration-driven (as opposed to development-focused) solutions, such as basic document repositories or informal team collaboration sites. 3. The most complex requests, however, would still require either an assisted provisioning model (for formal team collaboration sites or managed document repositories) or, in the most extreme cases (custom applications), traditional software development project to address. Department Control (Ad Hoc) Accelerated Provisioning Self-provisioning Rapid Provisioning Assisted Provisioning The figure to the right plots this accelerated provisioning model on a continuum of IT vs. department control. IT Control (Traditional SDLC Process)
Microsoft SharePoint Best Practices: Governance and Adoption Planning 13 Doculabs Opinion MOSS is an ideal candidate for a multi-tiered provisioning model. By its very nature, MOSS has a large footprint and user base within most organizations, and will be well served by the development and offering of provisioning options. But don t go happily provisioning your MOSS applications just yet. While some MOSS functionality, like setting up an internal departmental SharePoint, can be made available to self-provisioning immediately, you should make sure your organization has defined the policies, procedures, guidelines, and support before making such an offering available to users. The danger is that without these in place, IT, compliance, and the business will have less visibility into the information that s being managed, increasing the likelihood that business-critical information will be stored in silos the same situation you probably started with and had been hoping to eliminate. In fact, most organizations would do well to take a stepped approach to managing a MOSS provisioning program. The figure below shows how a provisioning model can be combined with a set of package solutions to create a robust service delivery program for MOSS. Figure 5: Sample MOSS Service Delivery Program Model Although the specifics of a multi-tiered provisioning model will differ from organization to organization, the basic benefits outlined here remain: lower costs, shorter deployment timelines, and less drain on the business and IT not to mention a more easily governed and managed MOSS program.
14 Doculabs White Paper Doculabs Final Word What happens if you don t involve IT, the business, and governance in the planning, implementation, and maintenance of MOSS? Some examples: IT-focused implementations: Storage, performance, and infrastructure concerns take precedence over business needs and regulatory requirements. Policies such as deletion of sites inactive for 90 days, users prohibited from creating folders, and site storage limits of 256MB are typical of IT-focused deployments. Business-focused implementations: Convenience and ease of use trump IT and regulatory requirements. Expect to see wide variance in site structure e.g. some departments have one site per employee, while others have one site per project, per process, or per customer, and sometimes all of these variations in use within a single department. We recommend abstracting the typical concerns of IT, the business units, and governance so that (1) they are not tied to a particular department and (2) they span departments, thereby encouraging cross-functional cooperation. For assistance in putting together a workable MOSS governance structure that aligns with your culture and meets your organization s needs, contact Doculabs at www.doculabs.com. For guidance on how to leverage the content management capabilities of both MOSS 2007 and advanced ECM solutions as part of a multi-vendor strategy, see Doculabs white paper, The Co-existence of Microsoft SharePoint and Advanced ECM Platforms: What You Need to Know, also at our web site: www.doculabs.com. MOSS presents an opportunity for an organization to get its unstructured content under enterprise control an easy-to-install, easy-to-use way of bringing content management to all users, throughout the enterprise. And the chances are your organization is taking advantage of the opportunity. But as easy to install as SharePoint is, there are questions you should be asking as you make it available to your users, particularly if the product has already made its way into your organization in grassroots implementations. The bottom line is that, despite its grassroots nature, your current SharePoint implementations are probably supporting critical business activities and therefore they warrant some corporate control. It should be clear by now that an ungoverned MOSS implementation poses too many risks to be ignored. To minimize this exposure, take the time to carefully assess the scope of your SharePoint deployment and evaluate how the security groups are being structured. Also understand how the product is being used, and for what types of content. And make sure you involve not just IT in the planning and implementation of MOSS, but also the business units and representatives of the governance function of your organization (compliance, legal, records management). Doculabs has worked with many organizations as they bring SharePoint into their technology environments, helping them develop and put in place the proper controls and the policies and procedures. We ve found that this grassroots usage of SharePoint that we ve been talking about in this white paper can also be a valuable asset for a MOSS implementation. Unlike employees who ve never used content management products of any kind, your grassroots SharePoint users do not need to be convinced to adopt they ve already done so. They have experience on the ground in how SharePoint products can be used to meet day-to-day business needs, and they probably have some ideas and suggestions for how to take SharePoint to the next level. Finally, they can help socialize MOSS to the wider organization, both during and after the implementation, and help make enterprise content management part of your organization s culture. The SharePoint platform meets a wide range of business needs. Make sure that when you roll it out, it s with the proper controls along with an enterprise strategy that ensures long-term, sustainable efficiency.
About Doculabs Doculabs is a consulting firm that helps organizations develop sound technology strategies for content- and process-related applications. Our engagements focus on helping clients leverage their existing enterprise content management (ECM) investments on a broader enterprise basis through objective analysis and in-depth market knowledge. This approach is based on our fundamental belief that in order to protect a client s long-term interest, technology advisors should not be implementers. 200 West Monroe Street Suite 2050 Chicago, IL 60606 (312) 433-7793 www.doculabs.com E-mail Doculabs at: info@doculabs.com Doculabs helps clients deliver on their technology objectives through consulting engagements that address ECM opportunities such as strategic planning, center of excellence creation, taxonomy development, and maturity assessments. Through more than a thousand engagements for organizations facing technology-, compliance-, and process-related challenges, our proven approach has provided our clients the information and advice they need to make confident and well-informed decisions. Hundreds of leading organizations within the Fortune 1000 and in federal, state, and municipal government have turned to Doculabs for assistance with their content management strategies, including strategies to help them derive the maximum value from their MOSS deployments. For more information about Doculabs, visit our web site at www.doculabs.com or call (312) 433-7793.