Our move to SharePoint / Social Sites 2010 Part II

In Part I of “Our move to SharePoint / Social Sites 2010” I wrote about steps 1 and 2 of our migration plan from a business perspective.  In this post I’ll cover steps 3-5.  To reiterate, here are the steps we took:

 

• Step 1 - Work with the lines of business to understand their needs. 
• Step 2 - Evaluate the current communities, review statistics, and combine, close, create where it make sense.  Set expectations with community managers on content clean up.
  • Step 2 ½ Get user feedback
• Step 3 - Write governance plan.  We were a startup and our intranet kept growing without any planned structure, roles, or responsibilities except for some internal volunteer work on the technical side.  If we put a better structure in place it should take us much longer to make a mess of things.  (We have an added challenge in that we do testing of alpha and beta code on our intranet.)
• Step 4 - Work closely with our technical resources.  They have done great work on supporting our intranet but a key to a successful E2.0 deployment is having IT and business work together.  One without the other is like peanut butter without jelly.
• Step 5 - Educate and communicate.  Have you heard the one about the cobbler’s children having no shoes?  NewsGator employees often run around barefoot when it comes to what we are doing on our own intranet.

So here we go, starting with step 3:

Write governance plan.  Like many customers I work with we had no governance around our internal instance of SharePoint or our Social Sites communities.  So it was a bit like the Wild West – some sites were popular saloons and others were deserted streets with tumbleweeds rolling through.  We put in a community / team site request process with a 1 business day SLA.  The only reason a community request is turned down is if it is a duplicate or if it violates our employee code of conduct.  For us it has greatly reduced the number of duplicates and well-intentioned but orphaned communities.  Once the community is created the requester is the community manager and there’s no big brother oversight but we do have a community curator role to nurture community managers within the organization and perform a quarterly audit for inactive communities (after 6 months of inactivity the community will get archived).  I was curious to see how our organization would take to moving from self-service community creation to community requests and frankly there has been very little resistance (I only heard one objection).  Everyone I talked to seemed to understand the trade off for a cleaner community experience and was glad for it.  There’s more to the governance plan but for us the most important piece was managing the community creation process.

Work closely with technical team.  I can’t emphasize enough how important it is for the technical side and the business side of the migration team to keep open communications during this process.  You can’t expect to simply migrate what you have and be successful.  More planning needs to occur, business decisions need to happen, and neither side can make decisions in a vacuum.  If those of us on the business side made decisions without having technical representation in on those discussions we’d decide to do impossible things.  (“If I can say it, we can do it, right?”)  If the technical folks made all of the decisions without business representation in on those discussions things might work but they might not fit business flow.  And no one would know about what had been done.  How many times have you heard “IT just throws this stuff out there and doesn’t ask us how we would use it first?”  So anyway, we made sure that tech and business worked closely to understand what we were working on in order to make the best decisions we could.  This also came into play with communicating to the end-users.

Educate and Communicate.  Let’s break this down into a few areas:

• Communications – We had been talking about the migration at a very high level in our town halls for about a month leading up to the actual migration so that people weren’t surprised.  Then the week prior to migration we ran an Ideas campaign to rename our intranet.  (Our 2007 version had simply been called Home.)  The day of the migration a message went out letting everyone know that Home would be in a read-only state overnight and that as soon as the 2010 intranet (now named Hal) was live we would send out the announcement.  The announcement email went out the next morning with a link to the new intranet, a link to the Help and Feedback community (see next section), and a link to the video snippet  “How to ask a Question about Hal” (see next section).
• Help and Feedback Community – We created a Help and Feedback community as a place for people to target microblogged questions, review documentation, see video tutorials, and review a list of previously microblogged questions and answers.  I mentioned above that in the announcement email we included a link to a short video snippet “How to ask a Question on Hal”.  Asking a question is easy but our Help and Feedback community was new as was @targeting so we wanted everyone who wanted the extra help to be able to ask questions when they had them.  We had about 5 people pressed into service to get automatic notifications whenever someone microblogged a question targeted at the Help and Feedback community.  Whoever could jump on the question first with an answer would.  It is a great way to handle support of any application rollout.  We were able to address functionality and process questions in a way that a support desk can’t (and usually they are only tasked with technical issues anyway) and after a while we started to see peer-to-peer support happening.  I highly recommend this as a great use of community.
• Educational sessions – We held two different types of sessions:  “Community Managers – What you need to know” and “What’s new on Hal”.  The community managers needed to know more detail than the typical end-user and so we talked with them about some clean-up and enhancements they could make to their communities.  For everyone in the organization we offered the “What’s New” session to highlight some of the new capabilities available to them with our new SharePoint / Social Sites 2010 intranet.  I’m known for offering cookies, wine, beer, and other food and beverage related bribes to get people to these types of sessions.  I decided to offer zip to see how many folks were genuinely interested in the new things they could do.  I had about an 80% attendance rate.  That tells me people will generally make the time to learn if you just make the sessions available to them. Afterwards a recording of the session went in the Help and Feedback community.  I plan on offering the “What’s New” session for every major release.  The people have spoken and we are finally listening.

 

Key takeaways?  Take advantage of this opportunity to do some clean up, apply governance (it doesn’t have to be heavy-handed), and make sure business and technical are working hand-in-hand.  We may have had a couple of fails here and there (my launch email was too long – most people didn’t get to the part about the “How to ask a Question about Hal” video) but in general I’m happy with the way things worked out.

There are many people just starting to work on their 2010 migration plans.  Have you completed your migration and have some lessons learned to share with the rest of us?  We’d love to hear them.

Comments

[David James]

Sharepoint is a really good to use if it is implemented correctly with the proper installation plan. This article reinforces the fact.

[Jim Stevens]

Another important fact concerning implementation is that the technical installation team understands the needs of the business in terms of the structural layout.