I recently saw that Ben Curry (of Mindsharp and the SharePoint Best Practices Conference) has a list of the Top 10 Administrative Bad Practices for SharePoint. I definitely agree with his choices.
The SharePoint Practice team at my company has been keeping our own list of Worst Practices for SharePoint, and I'd like to take this opportunity to expand on Ben's list and add a few that we have seen over the years.
Please note - this appears to be a list of recommendations; IT IS NOT.
1. Give all your power users and content owners Full Control.
When you can't decide which level of rights to give to your content owners (for example, those individuals who will need to create new metadata categories and build new lists and libraries as well as contribute content to a site), you can be confident that Full Control will give them all the rights they need, but there is a better way. Manage Hierarchy is often an acceptable level of security, which will let those power users do more than contribute, but not do irreversible damage to the site.
2. Don't use metadata to categorize documents or databases; just create a new folder, list or library every time you need a category.
While there are often reasons to create new lists and libraries to segregate content, and there can even be good reasons to use folders within a list or library, this shouldn't be your default content management model. This Worst Practice is related to Number Three:
3. Don't use metadata to categorize documents; just put all the information in the filename field.
Companies with document naming conventions are often used to long filenames that give a lot of information about the document. By using metadata instead, SharePoint (and similar content management systems) can free you from the need to keep all the information in the filename, and provide greater power for filtering and finding documents.
4. Use your old legacy servers for your new SharePoint implementation.
You're not sure if SharePoint is the right product for you, so you'd like to give it a test-drive without making a big investment in hardware. Unfortunately, what we've seen many times is that running SharePoint on underpowered servers and forcing it to share space with other legacy applications may not give you an accurate test-drive of the product, and in fact could cost a significant amount in terms of time spent troubleshooting.
5. Don't set up any test user accounts.
When you're building out SharePoint, you're most likely logged in with the powerful permissions of a farm administrator, site collection administrator, or site collection owner with Full Control. As you prepare for launch, moving around the site and testing functionality, you can see and do everything you need to. Your end-users with Read and/or Contribute rights may have a very different experience - and you don't want to hear this from them on the day of launch. Create, at the very least, one end-user test account, so that you can log in and out as needed to test your site. Ideally you would create one for every location, department, or high-level user role, especially if you're using features like Audience Targeting, so you can really see what your different user groups see.
6. Use a folder or document library called “Old.”
Like a lighter held aloft at a concert, this practice keeps the spirit of the file share alive in your new SharePoint implementation. Folders with names like "Old," "DO NOT USE," "Don't Need," and "Blurry Photos" can be a comforting structure for the end-user who's missing that big old P drive on the network. In a system where content can easily be surfaced by Search rather than by browsing, however, it may not be apparent to the searcher that the likely-looking filename they've turned up is sitting in the "_delete" folder.
For your long-weekend enjoyment, check out some more Worst Practices in the physical world at the "There I Fixed It" site.
Comments