Tag Archive | "Best Practices"

Tags: , , ,

To folder or not to folder? That is the question.

Posted on 30 March 2009 by Andreas Vamvatsikos

Since most of us grew up in a word of DOS and Windows, our desire for folders and tree-like hierarchical structures is vast. We just make folders and subfolders to categorize information it has become … natural. Most of us do not want to let folders go, even when migrating to a new world like document management and SharePoint.

SharePoint provides the functionality to create folders within document libraries and so the most natural impulse when migrating from that dusty file server, is to just recreate the folder structure.
But to really get the most out of MOSS one must utilize metadata (custom columns). Metadata create a dynamic categorization system within document pools and allow for infinite personalization through views. Metadata use also turn search from guesswork to an intuitive task.

To be frank the folders we all use in file systems are metadata for the files they contain, just single dimensional. The “Projects” folder denotes that all documents contained in it are project related documents. Since this is not enough we rely on subfolders (client name or project type perhaps) and info in the filename (specific project name f.e.) to add more “metadata” to the document. This process that can quickly be chaotic and as the number of files grows it becomes unusable.

This can easily be alleviated by using a true metadata structure in SharePoint (two custom columns “Client” and “Type” in the ProjectFiles document library would be enough for the above example). So the document visibility is increased but also the structure can be “re-organized” (through views and filtering) without any manipulation of the documents files themselves. Teams working on the same file-set can also benefit from this approach. So the Sales department can view documents sliced per client or budget, but the IT department can view the documents per Product or Project type. Metadata is the way to keep everyone happy while at the same time avoiding multiple copies of files (and emails flying around trying to find the correct version).
Another thing against folders is that even if they are there, they cannot be used for filtering.

Just to add a technical limitation to all the business and design ones, the maximum document url length in SharePoint is 260 chars. This can be easily reached if the existing folder structure is big or really descriptive.

So it is obvious. No folders in document libraries, just metadata. Well … there is one single detail that folders have on their side, you can define access rights on them. So if you want to reduce the number of required document libraries or you have trouble dealing with access rights maybe a single layer of folders is ok. You will have to add metadata anyway probably just to get the views your users will desire (yes you can add metadata to a folder through customization, but it is not copied automatically to the documents that are placed inside it).

To conclude, in my opinion try to avoid folders at all cost unless access rights management makes them an unavoidable necessity.

Comments (0)

Tags: , , ,

Increasing your chances for a successful SharePoint project

Posted on 24 March 2009 by Andreas Vamvatsikos

There are five rules of thumb that every SharePoint Project team must keep in mind in order to have a clear chance for success.

Plan big, start small
Microsoft Office SharePoint 2007 is a platform with a vast array of capabilities and features which is a good thing … until someone tries to use them all in an single project. So plan big since MOSS gives you the background to do so, but pick a couple of business focused quick wins for your first project. Don’t try to solve all of the client’s data, search, collaboration and process problems at once, the project will just never end. Get an ally within the client team, pin-point one or two problematic areas with their document or process handling and provide a solution just for that, either as a small start-up project or even as a pilot of a broader implementation.
This makes it much easier to keep the project on time and in budget but also to get the “buy in” from the end users that you will need later, when trying to deliver solutions to more complex problems.

Educate your developers
As I already noted MOSS is a platform. As such it has a wealth of Out Of the Box features that can be utilized in any solution. It has even more features that can be downloaded through Microsoft and the Codeplex Community in the form of application templates and web parts. You can even buy components from various vendors to facilitate a solution. All of the above components and features are extremely customizable according to your solution design and the user requirements.
This is something your development team HAS to understand and embrace. It is sometimes difficult to convince a developer with .Net mentality to try and find a way to implement things in the above described “SharePoint way”. If you find the team launching Visual Studio and going through the “Dim x as …” routine something is probably wrong.
With that said, there are actually some extreme cases where coding is indeed needed but they must be treated as exactly that, extremes.

Educate your users
Starting from pre-sales, users must have a clear view of how SharePoint will benefit themselves and the company, how it is going to take some effort and stress away from them, so that they are willing to go a little out of their way (and their established habits) to use it. They have to be educated to the whole metadata and search paradigm (don’t be shy to give the Google example even if they are an MS competitor) but at the same time assure them that they will still perform most of their tasks through their beloved MS Office.
After Roll-out do not try to train everyone in everything! Prefer role-based training according to how users are expected to utilize the SharePoint implementation. Finally be prepared to communicate the positives of the implementation and get ready for a storm of questions that must be answered. Unanswered questions tend to lead to a lot of user resistance to system adoption.

Plan for business not for IT
Since IT is usually vocal, you may end up designing a business system based only on IT input, which is exactly the opposite of what you should be doing (I should know, have been guilty of this a couple of times). SharePoint was designed with business data and processes in mind and is built in a way that some of the customization and the administration can be handled by business users.
So you must set up a group of key users in the requirements phase, that can close the gap between the business needs and IT, that can describe processes, define roles and responsibilities and bring some specific “company know-how” into the project, since every business is unique in its structure, function and needs. Document the processes, templates and metadata (avoiding IT complexity and terminology) and get a consensus before proceeding to implementation. Missing process steps or messed up templates and useless metadata will lead to an unusable system.

Design for user friendliness, be prepared for change
A user friendly implementation is key to success. Try to keep as much of the offered functionality as you can within MS Office, users love the impression that nothing really changed in the way they proceed with their everyday tasks. Site Structure and navigation must be simple and – got forbid- nice looking! Spice up sites and site collections with some images or charts, don’t just pile up lists. Even in lists provide intuitive views, don’t rely on users to create them. Set up a site for social interaction within the company to lure users in increasing adoption and acceptance.
However build all that with a well thought out structure of Content Types, Site Columns List templates and Web Parts at the site collection level. This way you are going to be ready to adapt quickly
to the unavoidable change that all businesses undergo sooner or later.

Lastly remember that even if MOSS is a platform offering solutions to many business problems it does not offer solutions to ALL the business problems!

Comments (0)