I took a brief interlude in my schedule yesterday to co-present with Joel Oleson, Technical Product Manager-extraordinare, on the topic of SharePoint governance at TechReady4 in downtown Seattle. Joel is focusing a lot of attention on SharePoint manageability and governance, and since I manage enterprise deployments, it's a topic near and dear to me, as well. Aside from the technical difficulties with my microphone (user-error?), it was great to get feedback from people in the field and understand where they are seeing gaps in the offerings. On the ride back to campus, Joel and I talked at length about the questions posed, and where we could supplement the existing content.
One area that came up repeatedly was the lack of scenario-based content around instituting a governance model retroactively. What about those companies that have pushed SharePoint out the door without taking the necessary steps to analyze and document their governance model? Rolling out a new project with a plan in place is one thing, but cleaning up the mess when you've already rolled it out to your users is something entirely different.
For those at the beginning of the process, there are articles and planning tools a' plenty, such as Joel's list on creating intranet chaos, a presentation he built on manageability out on gotdotnet, and a Quest whitepaper by Doug Davis outlining the SharePoint impact on Business and IT. For those inside MS, I'd also point you to Mark Wagner's stellar governance plan template (search for him on MSW). I plan to personally use this doc going forward.
But what about those deployments already underway, where the sites are already proliferating? Some thoughts on how to proceed:
- Do your homework. Regardless of where you are in your deployment, it is always best to go back and take the necessary steps to capture your company's governance model (or, to establish one). Some thoughts on where you should start:
- Identify your executive sponsors. This is a critical piece of adoption, and making decisions around the governance model.
- Identify key stakeholders throughout the organization who are willing to provide strategic direction. It's great to find support within each business division or product group, but at the bare minimum you need to identify key business decision-makers and include them in the process.
- Outline the necessary personnel and infrastructure to properly support the system.
- Establish usage policies and best practices for SharePoint vs file shares vs other ECM platforms that may be in place. Within SharePoint, establish usage policies around MySites vs TeamSites.
- Outline your taxonomy. Again - this may be your business units, along product lines, or by major projects. Different companies have different models. This will play into your site creation policies.
- Decide on your site creation policy. Is the system wide open, (hey, that's what got you into this mess in the first place!) do you restrict people to specific parts of the taxonomy (by security group), or do you set up an online request form to be managed by a single group (such as IT)?
- Develop your look and feel. Are the out-of-the-box SharePoint templates acceptable, or do you need to create custom site templates for each division/product area/project team?
- Agree on strategy. Obviously, making changes late in the game is going to impact your existing system. Depending on the number of users and number of sites, you'll want to assess the impact of rolling out each part of your governance model. Here are a couple strategies for moving forward:
- Strategy One: All at once. Notify your users of some difficult days ahead, deploy your taxonomy and new templates, and deal with the pain as early as possible. There will be high impact - URLs will change, links will break, and data will need to be migrated, but you can focus on cleaning the sites all at once. Admittedly, this works best on a smaller deployment - one without external partners and customers.
- Strategy Two: Piecemeal. Add your taxonomy and templates for all new sites, but grandfather existing sites. Let users move their content manually on the first wave, address migrating larger/more complex sites later. Just remember to hold users to a timeline to move their sites, because you'll want to clean things up as soon as possible.
- Strategy Three: Parallel systems. The most costly of the strategies, but building out a second system in parallel has the least impact on your users. Apply your taxonomy and templates, backup sites and data on your live system and replicate to the new system, and allow users to preview their sites within the new environment. Hold users to a timeline for approving the move, or requesting changes prior to cutting over (btw - this has been our approach in MMS).
Not an all-inclusive list of recommendations, of course, but its a start. I'll amend the list as I receive feedback.
I cannot stress enough the importance of starting out your SharePoint deployment with a plan, and identified stakeholders who buy in to that plan.
