I just read that Groove is being renamed as SharePoint Workspace 2010.  For those of you who are not familiar with Groove or its history, I’ll take you back to the early 80’s. 

Ray Ozzie is the visionary behind Groove and currently the Chief Software Architect at Microsoft (a role he took over from Bill Gates).  At University of Illinois (as many know, home to the NCSA  which created Mozilla, the first web browser on which Internet Explorer is based) Ozzie worked early iterations of some of today’s knowledge management,  collaboration and social media applications (discussion forums, message boards, e – learning, e-mail, chat rooms, instant messaging, remote screen sharing, and multi-player games.

He also worked with some of the pioneers in personal computing and products like Visicalc, one of the first spreadsheet programs that ushered in the age of personal productivity.

Ozzie worked for a time at Lotus Development and went out to form a new venture called Iris Associates which developed a collaboration tool called Notes.  Lotus acquired rights to Notes with Iris remaining a separate entity but doing all of the research and development behind the product.

For many years Lotus Notes defined the field of collaboration and knowledge management.  It was an immensely successful product and was even the de facto standard for corporate email for a time.

After the acquisition of Lotus by IBM, Ozzie stayed for a time but eventually moved on to found Groove Networks in 1997.  I recall my initial reaction was that Groove was very “Notes like” but with even more decentralized control and less administrative overhead.  It was a peer to peer application that allowed for data to be replicated on multiple devices.  Applications were being created by a community of developers that allowed for rapid deployment of tools for a variety of collaboration tasks – discussions, contacts, calendars, file management, brainstorming, sharing/managing pictures and images, group note taking, group sketching an even group browsing (sounds like Webex to me…)

A rep from Groove came to our offices to do a briefing and I was not sure how Groove fit in or how a consulting firm like ours would build services around it.  It was early in its development and the market was not well developed.  Ozzie had created something really amazing - a self provisioning application that allowed for extremely granular data exchange and synchronization and a large library of extensible applications. 

Groove really allowed for anyone to start collaborating with advanced knowledge sharing applications in almost no time with little administrative or technical overhead.

It was interesting that IBM was not interested in Groove and that Microsoft ended up acquiring the company.  Groove was a next generation architecture and IBM had the Lotus Notes and Domino legacy environment that they wanted to move to IBM Websphere.  (IBM Websphere was touted as a “small business” platform to replace Notes, but the product was clearly for the enterprise.  IBM reps were smoking something when they came up with that one.)

So Microsoft ended up with Groove.  And Groove became embedded in Office 2007.  (I had seen it there and thought “how strange”)

Groove can be launched as a set of shared workspaces.  Essentially you launch Groove and then invite others to use the workspace you have created.  Then documents you add, applications, images, etc are automatically replicated. 

Now, the plan is for Groove to be the collaboration suite for SharePoint in 2010.  This suggests a number of practices that need to be considered as organizations go full speed down the collaboration path.

Learn from history – because it is technically easy to deploy does not mean a deployment should not be planned.

The greatest strength of collaboration tools was that they were easy to deploy, could be provisioned by users, required no IT planning or involvement. 

The greatest weakness of collaboration tools was that they were easy to deploy, could be provisioned by users, required no IT planning or involvement.

Ahh, you noticed that this strength is also a weakness?  That is because tools like Notes quickly went out of control and created a sprawling mess of information.  An information Shanty Town – with no standards, managed infrastructure, rules for content stewardship or ownership. 

Don’t make this mistake.  Collaboration should not be all chaos and without governance.  It can be freewheeling and encourage creativity, but that  does not mean there are no rules.  If you let things go, it will be very difficult to bring under control.

Here are some considerations for deploying collaboration tools (broadly speaking) and SharePoint in particular:

1.  Plan the deployment

Decide on program objectives, target audiences,  target processes and success measures.  Rather than treat this topic exhaustively, I will refer to our upcoming Webinar Series on SharePoint.  I will be discussing creating a SharePoint strategy in the first session of this series on June 4th.  

2.  Choose the correct tool for the correct process

SharePoint provides a great deal of functionality- content management, document management, portal functionality, business process management, business intelligence integration, search and of course collaboration.  If you are enabling collaboration, don’t use the collaboration configuration to manage corporate libraries.  Collaboration is inherently more chaotic, content management more controlled.  Design the process and configure the tool appropriately.

3.  Create a comprehensive site architecture and taxonomy

Of course this is our sweet spot and we think this is the most important aspect of any technology deployment.  What this means is it’s not a good idea to “put it out there” and see what happens (which of course is the main theme of this entire post).  Unfortunately this is what many organizations are doing because it is easiest for the organization.  This is a situation where someone says “we need SharePoint” and someone in IT says “OK, we can do that”.  But there are few resources devoted, there is no business owner and standing up a SharePoint server unencumbered by user requirements does streamline the development process.  (Please note facetious tone.  This  is not a recommended practice)

4. Plan search as a core application

Search is an application, not a utility.  We need to think  of search as “information access”, not simply the generic search box.  This means exploiting taxonomies in faceted search, developing search scopes and custom search configurations, federated search and investigating third party add-ons as appropriate to your process. 

Fully integrating Groove into SharePoint will bring collaboration to a new level, with new tools, new mechanisms for deployment and more powerful support for a variety of processes.  Powerful tools will always have some level of complexity – the key to a successful deployment is to hide that complexity from the user by surfacing what they need to support their tasks.  And this requires thinking through and  planning for appropriate functionality

Testing and validating a taxonomy can go many ways.  With a little luck and some hard work, usually it goes pretty well, you watch users click through the structure, find the right terms, and you go home feeling like everything’s in its right place. 

There are always the nightmare scenarios, the tester who can’t find anything and randomly clicks through the taxonomy as though they were sight seeing on a Sunday drive in the country, the tester who looks in the same category for everything… don’t ask me why but it’s always accessories, the tester who freely admits volunteering for this session to escape an insane co worker, if only for 45 minutes…  But I digress.

This last testing experience was by far and away the most rewarding I have ever done. Not because the taxonomy was perfect…it wasn’t.  Not because the testers were brilliant enough to intuit our mistakes… they weren’t, but because almost everyone left the sessions excited about taxonomy in general, and thought it would make their life, at least the part that had to do with information management, better.

I know, its sounds crazy, you don’t expect a positive response when you tell someone that from now on when they create a document they are going to have to use this elaborate structure in front of them to tag it…but they were. Everything from ”Its about time”  to ” this is going to make finding things later a lot easier”.  Now certainly a large part of this positive reaction had to do with the fact that the overall structure and vocabulary of the taxonomy really resonated with them, but an even bigger part of this positive reaction had to do with the sense of participation in the overall project the testers felt when truly engaged and asked for feedback. 

What I am really trying to get at here is that taxonomy testing can be about more than just getting confirmation that you are great taxonomist, that people can find what they are looking for and that you will in fact most likely work again. 

Socialization of a taxonomy project through user testing can help to build project momentum and a sense of ownership of the taxonomy well before you ever actually force someone to tag a document with it.  So test early and test often, and try to ensure that when eventual users walk out of the room they feel they have contributed something meaningful to the taxonomy development process.

It may be a stretch to think your taxonomy project will be the subject of water cooler conversation for weeks to come, but if you can get your testers excited enough about taxonomy to market it for you then you are one step closer to a succesful project. 

 Let your users be your evangelists

One of the things that we get called in to help with is the set of governance policies and processes that are necessary to make taxonomy projects a success.

There are number of things that need to happen for organizations to be effective in this area:

1. Sponsorship: Someone with power and authority needs to understand the value of taxonomy and nomenclature governance

This person can help settle turf disputes and conflicting organizational requirements. The key is that they are truly engaged and really get it, rather than delegating authority.

2. Ownership: An operational champion needs to own the project. This is the person to whom ultimate accountability falls. They are the one that has to drive communication and get people to participate

3. Line of business buy in: Terms are applied in specific business contexts. If those close to the front lines are not part of the process, then the taxonomy will lose relevance and therefore not be fully adopted.

4. Foundational knowledge: People involved in the process need to understand where they are going and the process for getting there. This kind of foundational knowledge needs to be facilitated throughout the project so that after the project is complete, the organization will have traversed the maturity curve.

5. Specific branch and node ownership: Individuals who understand the specific domain of knowledge need to be responsible for parts of the taxonomy so that the process is manageable.

6. Accountability and measurement: Tasks of maintenance or participation in review meetings or term feedback need to be part of people’s job descriptions and they need to be evaluated on these tasks in performance reviews. If this is not part of job descriptions, then it will not be done.

In order for the organization to really embrace term management, people need to see how it benefits their work. So integration with existing projects ‘in flight’ is important and has to be done with a consideration for current workloads. By showing stakeholders how particpation in your project will help them and not hinder them, you will be able to gain support. But if you make it seem too difficult and onerous, people will naturally say “why bother?”. The balance lies in being realistic about the effort without losing support. This can only be done in the context of explaining multiple benefits to projects and processes.

Diverse groups need to be aligned, which is always a challenge. Getting people to understand the challenges and processes for moving forward is the place you need to start.