Clearly, one of the great things about SharePoint is how easy it is to use. With a minimum of training (and the proper permission set), users can build team sites, Document Libraries, folders, whatever they think they need.
Unfortunately, one of the worst things about SharePoint is also how easy it is to use. At least once or twice a week I hear about another organization that has implemented SharePoint and is suddenly experiencing what has come to be known as ‘SharePoint Sprawl’. SharePoint Sprawl is what happens when 
SharePoint is installed at an organization before the organization puts controls in place to prevent users from randomly creating SharePoint sites and Document Libraries without considering what they will contain and how their content will be managed.
SharePoint Sprawl is especially dangerous to Records Managers. One day your organization will install SharePoint and you’ll go home only to come in the next day to find SharePoint sites created all over the place with documents (and potential records) scattered in almost every direction. And all this with complete disregard for taxonomy, metadata and retention considerations.
If your organization is planning to standup SharePoint it is incumbent on you to make yourself part of the implementation team as early as possible and insist that the organization develop a logical set of controls that prevents SharePoint Sprawl from ever happening. One of the best things you can do is duplicate what one of my customers did. This company had a very active and efficient Records Management team and they made sure that they were involved in every step of the SharePoint implementation. They developed a policy that allowed almost anyone in the company to request a SharePoint site for just about any reason, but the request had to be routed through the Records Management team before the SharePoint Administrator would actually create the site. The Records Management team checked every site request to ensure that documents were in the right locations, had the proper metadata and, if the site produced records, rules were in place to get those records properly declared and classified into the Records Center. (In a touch of irony, the company created a very good SharePoint workflow that automated the entire SharePoint site request process.)
Again, if your organization is considering a SharePoint implementation, I encourage you to do what you can to prevent SharePoint sprawl at the earliest possible stage.
August 19, 2009 at 5:25 pm
Kudos for instituting the process. I agree that it is key to preventing sprawl. However, it seems that such a process may deflate SP’s value. Did the process detract from “quick and easy collaboration” of SP? How quickly could that RM team complete a request?
August 31, 2009 at 12:23 pm
Chuck,
Sorry for the delay in getting back to you on this.
The site request process was created using some basic SharePoint workflow features. Requesting a new site was a very simple process that could be executed by almost anyone in the organization.
If the process detracted from SharePoint’s ease of use, it wasn’t by much. And if time was lost in the early stages of deployment, it was most certainly saved in the later stages because we weren’t forced to scramble to regain control of a implementation that had grown to a point that it was completely unmanageable.
Don
August 31, 2009 at 1:54 pm
Thanks!
Do you recall what the “Turn around time” was for the rm team to fulfill a request?
September 2, 2009 at 1:53 pm
After the initial rush of site requests (which lasted the first couple of months of deployment), we saw a steep drop in demand for new sites. This was entirely expected.
I left the project soon after that, but I understand that site request turn around can be very quick now. Typically a matter of a day or two. Even faster if there’s an urgent need. (And by that I mean the request came from somebody high up on the corporate ladder. ;o)