- Podcast
- Research
- Search
- Security
- Technology
- Video
- AIM
- Alfresco
- Collaboration
- ECM
- ESX
- Hyper-V
- IE8
- Internet Explorer
- Iomega
- Linux
- MIX08
- Microsoft
- NAS
- Nokia
- REV
- S60
- SaaS
- Sharepoint
- Silverlight
- Sony Ericsson
- VMware
- Windows Live
- YouTube
- Advertising
- Backup
- Beta Test
- Blogs
- Convergence
- Display
- Enterprise
- Humans
- Instant Messaging
- Multimedia
- Networking
- Open Source
- Phishing
Leveraging SharePoint as a Document Management System
Common Pitfalls
With the basics out of the way, here are a few common pitfalls when implementing SharePoint document libraries—and ways you can avoid them.Pitfall #1—Copy the Network Drive
Many network administrators see their network drives as a large, unmanageable dumping ground for end-user documents. Users feel comfortable putting documents on network drives because they're backed up, and the shared space makes it easy to share stored documents with others. When users run out of space on one drive, they simply switch to another.
SharePoint is sometimes seen as the quick and easy alternative. It comes with promises of full-fledged document management features, an acceptable price point, and easy-to-follow installation instructions. When you add in document retention policies and workflows, making the decision to switch seems easy. But simply purchasing a tool does not necessarily solve your problem; just as buying a hammer at the hardware store does not mount a picture on the wall. Solving a problem requires proper application of the tool and a specific process. The same goes with moving your organization from using network drives to SharePoint.
Before transferring all your documents from your network drives to SharePoint, plan out your approach. Network drives inherently lead to a deep folder hierarchy, with no metadata. Do you really need to move all the old documents that nobody uses anymore? How would you catalog them? What metadata should be applied? How will users find the right information quickly? How much room should you allocate? Do you need to save old versions of all documents? Do you need all the versions or just the last four?
The general recommendation is that you leverage SharePoint specifically for documents that require some kind of collaboration. SharePoint's search features let you index content on a network drive, so you can use the index and search features to allow users to search for older documents that only need to be read, not modified.
Folders are a touchy subject. Unintuitively, you should not leverage folders to catalog information. It's better to rely on metadata, filtering, and views to allow users to find information on their terms instead of having to memorize some path through sub-folders. For example, if you are maintaining department budgets for each year, you can set up a folder structure that forces users to select a year first, and then a department. But suppose you want to see all the years you created budgets for the IT department? By adding two user-defined metadata columns, Department and Year, you can leverage SharePoint views and filters to slice and dice your documents in different ways.
However, folders are still a necessary part of SharePoint document libraries, because they help avoid some performance issues that appear when dealing with large volumes of documents.
Pitfall #2—Document Sprawl
Because SharePoint is relatively easy to administer compared to other document management systems, power users in various departments across organizations tend to set up their own sites and maintain them independently. This leads to document libraries that are configured with a variety of metadata, libraries that were useful for a specific project but now abandoned, and a lack of security.
To avoid this messy and potentially dangerous (security) situation, a proper governance structure is required. SharePoint governance is a topic that has matured over time and now has best practices around it. Centralized teams are responsible for new site approval, ensuring consistency, and providing oversight, training, and guidance. The SharePoint governance team can define standard sets of metadata, base workflows applicable across different departments, standard content types, and both centralized and decentralized security models. The centralized model defines the users and groups that have access to the various sites, while the de-centralized model provides selected users with the ability to give other users access to specific documents or libraries.
To avoid sprawl, document libraries should be monitored regularly, and unused or obsolete content should be archived.
Pitfall #3—Metadata Overload
Larger organizations that are accustomed to implementing standardized processes and procedures may end up taking SharePoint governance to an extreme, creating document libraries with so many required columns that adding a document becomes a time-consuming chore. This inhibits adoption or leads to people not using the product.
As you define the metadata that applies to document libraries, consider how realistic it is to ask for this information. If you're asking users to select a choice from a dropdown, will they sometimes want to select multiple values? Will they have a hard time choosing between two options? Will their choices cause the system to catalog the information incorrectly?
As a document matures from draft mode to published version, metadata may become necessary. Should all the metadata be added by the author, or should some be added by the person reviewing the document later in a workflow? It's often better to capture less metadata and have increased adoption than to over-engineer your document libraries.
Additional Considerations
When you are ready to adopt SharePoint as your platform of choice for document management, or if you are using SharePoint to ease collaboration while leveraging another platform for formal document management, consider the following. Before installing the product, make sure that you go through an IT planning exercise as you would for any other product implementation. What kind of hardware will you need to support your team? Will you deploy to a pilot group first, or to the entire organization at once?
In addition to the IT planning, make sure you understand your end user needs. Will they need only the basic features included in Windows SharePoint Services (WSS), or will they require some of the Microsoft Office SharePoint Server (MOSS) features? Are these additional features worth the additional investment?
Finally, after you go live, make sure that you have a SharePoint governance plan in place that outlines how you will manage the processes and policies involved with SharePoint. Continue to connect with your end users as their needs will evolve over time and their familiarity with SharePoint improves and the business needs grow.
TAGS:
policy, SharePoint, document management
Most Popular Stories
- 1 Building SharePoint Suggestion Boxes and Soliciting Anonymous Feedback
- 2 Solve Item-Level Permission Performance Problems in SharePoint
- 3 Redirect a Custom Page in SharePoint 2010
- 4 Using the Event Handler in SharePoint 2010
- 5 InfoPath 2010 Online Forms and the SharePoint Records Center
- 6 Working with jQuery and the SP.UI Namespace on SharePoint 2010
- 7 Create an Image Rotator in SharePoint Using jQuery

Intel Parallel Studio enables C++ developers to verify applications and find latent memory errors that cause crashes and lockups. Download the step-by-step evaluation guide, and see for yourself.