poorly applied, sites blossom
scatter like petals”
Congratulations to Jim Adcock, who came up with this gem as his winning entry in the AIIM haiku contest. It was my laugh of the day! It also prompted this article.
I was recently involved in a SharePoint implementation at a large software company. I was on the governance board for the overall implementation, and also managed a large site collection. Managing site proliferation is critical to keep SharePoint from getting rapidly out of control. There were several ways in which my company successfully addressed that concern.
- Stakeholder involvement in the planning stages: The IT project managers identified administrators from each of the major departments during the early planning, kept us informed of progress and plans, sought our input on priorities and issues, and got us working together on site organization and governance decisions. The site collection administrators for R&D, the group I was in, met together on our own to discuss organizing our site collections so that they had common content groupings and common elements, ensuring that users moving from one product group to another would have a familiar experience.
- Pilot activity with selected groups prior to implementation: This raised a lot of questions and concerns, identified training needs, and prepared the site collection administrators for challenges they would face in the production environment. Site collection administrators worked with groups expressing SharePoint interest or with unique use cases to pilot team and project sites that would showcase the abilities of SharePoint to other groups.
- Communication to internal groups: Both IT and Internal Communications issued communications to the entire company prior to production, and worked with the site collection administrators on specific communications and guidelines to our own departments. The President and CEO personally endorsed SharePoint, used it himself, and did a series of video messages about it. That was very critical to SharePoint adoption.
- Phased rollout of functionality: We made a conscious decision to focus on personal sites (My Site) first, to get people used to SharePoint in small doses. Team sites were next, then project sites and other types of sites. The NewsGator plug-in for social collaboration was a popular feature that we rolled out after most site collections were off to a good start.
- Administrative controls: Site owners could create new pages, but only site collection administrators could create new sites. When sites were requested, we ensured that they were not duplicates of other sites. In some cases we recommended that a new site be set up as a sub-site of another, broader site, or that two sites be combined. In some cases we recommended that the content be covered as a page within a site, rather than as a sub-site. These efforts helped to keep the number of sites manageable, without introducing barriers to content production and update.
- Governance board: Each department had a representative on the governance board, which prioritized new functionality and development priorities. This enabled us to communicate with our teams and get their input on what they needed for their sites, and make sure their voices were heard. It also ensured that we had a plan and executed that plan in an orderly manner.
The one area where we could have done better is training, both for end users and for site collection administrators. We were using beta SharePoint 2010 for the pilot, and went into production just after SharePoint 2010 went to production. There was no training available from Microsoft, and internal plans to have training available at implementation were not realized. This led to some frustration from early adopters. Despite that, I found this to be one of the smoothest implementations of a new IT platform that I’ve ever been involved in.