Have you encountered anything similar to the following scenario yet?

1. A few individuals, typically someone in IT, learns about how SharePoint can be used to solve communications and document management problems.
2. Windows SharePoint Services (WSS) is installed and the IT department(s) begin to use it for various purposes; communications, projects, etc.
3. The success becomes the talk of many meeting; commonly heard "Put it in SharePoint" or "Why would you put anywhere other than SharePoint".
4. The momentum moves throughout select areas of practice and departments with little regard as to why it is or is not being adopted.
5. Management gives the green light to deploy the solution or announce its availability to the company.
6. Mandates are put in place to now use SharePoint instead of file shares (because many believe that is all it is), sites are to be used for every project (IT or not), etc.
7. Everything is going along quite well.  You have various levels of SharePoint knowledge so your education and support needs grow but you are happy with the adoption rate.

I call this common scenario the Viral Nature of SharePoint; don't underestimate it, or it will bite you!  Installing SharePoint and rolling-out sites is too easy.  So easy in fact the next step in this scenario is usually failure.  Your SharePoint solution has been deployed for a year or so, you have hundreds if not thousands of sites; common complaints now include:

1. Inability to find information.
2. Not understanding why there are 20 sites for a single area of practice or department.
3. Not understanding why they have access to some sites but not others; especially those with names they feel they should have access to.
4. Search returning so too many results to find any relevant information.
5. Search return many results of the same information (big red flag).

Your users are now very frustrated because they have so much time and effort invested in SharePoint, but find the value it adds to their everyday life diminishing.  You will have to take action quickly, cautiously and expect a great deal of communications to turn this type of situation around.  Once you have spoiled the taste a user has for a solution, getting them back to feed is very difficult.

How do you Resolve This or Reduce The Risk of it Happening in the First Place?

1. Educate, educate, educate.
2. Define and create a publicly available set of Community sites; one for each area of practice.
3. Find and educate individuals that will advocate, administer and moderate communities.
4. Install an improved search and navigation tools.

Educate

Inform your users about the risks of just creating sites without a plan.  Rolling-out SharePoint to an organization, regardless of the size, must be handled in the same manner as any other project.  The creation of sites follows the same rules, just on a smaller scale.

Make sure you have categorized the various types of users; i.e. end users (80% of your employees in most organizations), moderators, assistant administrators, administrators, trainers and so on.  Make sure you plan on and deliver the appropriate training to those users.  For example, don't expect your average user to understand how to appropriately manage site security.  In these circumstances, that type of user should never need administration training or have the security rights to create sites.

If your company is unprepared to train the various levels and types of users, look into what is available today.  There are a number of companies; i.e. SharePoint Experts, MindSharp, Barracuda, etc. that specialize in training and can move through your organization very quickly.  Believe me, the monies you spend today on training will be saved down the road in support or the cost of failure!

Communities - Areas of Practice

From the SharePoint site perspective, I use the term community or area of practice and sites when I am educating users.  Many users find it very difficult to understand the differences between a site, team site, workspace, document workspace, social workspace, meeting workspace and all of the other names that have come about.  If you choose to not use the term community, try and come up with one or two terms that you use consistently.  Communities are root level sites that everyone in the company has access to, provide a means by which everyone across organizational boundaries can communicate about a topic.  Common communities might be; Software Development, Human Resources, Compliance, Sales and Marketing, etc.  Communities can, and will, have sub-sites.  In many cases these sub-sites will have restricted access and provide a place for a specific team to collaborate about a specific topic.  The big difference here is, these sites are "children" of the related parent community.  In addition, you can document information about the audience and access requirements in a list that contains links to these sub-sites.

Advocate, Administer and Moderate

You will need a technically savvy group of individuals to administer and moderate your communities.  As I indicated above, believing your average user will be able to appropriately implement the security for a site is aggressive.  Selecting these individuals and educating them early in the process reduces the risk of failure and certainly improves the adoption rate.

Install an Improved Navigation and Search Tools

One major downside of WSS is the search.  Currently, when a search is performed, only content from the current site is returned.  As your communities grow, there will come a need to seek out 3rd party or develop advanced search utilities for your users.  There are a few products on the market today that provide the ability to search the current and all child sub-sites.  In addition, you will have a set of users that prefer to point-and-click to locate information.  This is also referred to as information discovery.  To be efficient, I would recommend a site/sub-site map display.  Once again, there are 3rd party tools available today; for example there are a number of tree view Web Parts available.

Summary

The use of communities does have the ability to reduce the number of root level sites and provide a means by which to group similar sites.  If you can avoid the inevitable fact that you too will eventually have too many root level sites to manage, you may consider this or a similar type of structure.  Plan and educate your users of the risks involved if no structure, guidelines and procedures are in place.  The bottom line is; put some forethought into it long before you hand the keys to your castle over to all employees!

There is a related topic that requires one, if not may, articles; which is duplicate information.  This is related because it will happen as a result of too many users not clearly understanding how to use a solution such as SharePoint.  If your current SharePoint implementation has hundreds of sites, you can be guaranteed you have duplicate data problems now!  Without the appropriate processes, controls and standards in place, you will end up with duplicate structured and unstructured data in SharePoint instead of file shares, local drives, e-mail boxes, etc.  I will write more about duplicate data issues and some ways we are overcoming them today at a later time.