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