HOWTO: How Document Collaboration Works at Microsoft
While the title of this post might indicate that there is a sweeping document collaboration strategy that all teams and people use, that’s not the case necessarily. We are big at dogfooding which is a made up verb indicating that we love to try out our own software and tools in our everyday jobs just the way our customers do.
To that end, this post will describe a successful multi-national document collaboration effort surrounding the recent publication of the Office SharePoint Server 2007 and Team Foundation Server 2008 guidance that was recently published on MSDN.
The guidance for this heavily anticipated documentation will be released in phases over the next few weeks and appear in a developer center located under the SharePoint developer center.
Here is the portal link which describes the focus of the guidance as well as links/placeholders to all the content as it gets published:
Team Foundation Server Resource Center
And here is the link to the first published article:
Using Team Foundation Server to Develop Custom SharePoint Products and Technologies Applications
Based on the guidance, and the descriptions in the above resource center, we have a total of five white paper documents that were collaborated on by over 50 people in several countries, including India, Germany, Ireland, Turkey and the Netherlands. This also included domestic resources such as product group folks and rangers around the country and in Redmond, WA. Here are some stats about the effort:
Collaboration Platform: Office SharePoint Server 2007 and Groove 2007 with Word 2007, Visio 2007 and OneNote 2007 (all latest Service Packs and hotfixes)
Team Size: Over 50 contributors and tester/reviewers actively marking up and editing the same set of documents over a 4 month period including Microsoft Services Consultants, Product Group team members (SharePoint and Visual Studio Team System) and external MVP’s
Deliverables: 5 white papers consisting of procedural and contextual guidance including screen shots, artwork, Visio diagrams for developers writing custom MOSS applications and using Team Foundation Server
How we did it:
I was fortunate enough to be at the hub of this activity and led the effort to work with all the talented authors, contributors and reviewers. What we did is to establish a SharePoint team site in on a our internally hosted Microsoft SharePoint 2007 Server collaboration farm. Using the Shared Documents library, I then created a Groove 2007 workspace and added the SharePoint Files tool.
SharePoint and Groove in Sync Together:
The SharePoint Files tool will connect to a designated SharePoint site at a level in its folder hierarchy specified by the user. In my case, I linked the tool to the Shared Documents folder. I then in Groove, created a folder hierarchy which the rest of the team would use to store documents and resource files related to those documents. The folder hierarchy synchronized back to SharePoint, thereby mirroring the workspace and the files therein.
From a collaboration standpoint, this was critical as a most of our authors and reviewers were at one point or another not connected to our internal-only corporate SharePoint collaboration environment. Thus, by making Groove the primary collaboration point, Groove workspace members could interact with the virtual team and the shared documents while at an airport, on the train, or anywhere with internet access.
How We Managed Changes to Documents:
Whenever anyone updated a document, the changes came streaming back from their workspace to everyone else’s copy. For me, I was the designated SharePoint synchronizer. My workspace was the first workspace that I invited everyone to, so it was the only workspace that synchronized back to the SharePoint team site. When my workspace received updates and reported unsynchronized changes in the tool, I simply synchronized back to the SharePoint site and all the changes went into the SharePoint “cloud”. This gave me, and everyone else a comfort level that our documents were preserved not only in each other’s workspace, but versioned in SharePoint as well which was backed up by Microsoft’s enterprise backup.
Collaboration Stipulations:
While the this arrangement gave us the flexibility to support collaborators accessing a document both in Groove and in SharePoint, I did not want to get into a situation where a single document had conflicting changes coming from both environments. Thus each paper’s collaboration team was required to choose their collaboration environment (SharePoint or Groove). Because of the benefits of Groove (only an internet connection required to collaborate) all of our team chose this approach. This left it to me to manually (if I chose) check out and in documents before synchronizing.
In addition, to avoid collisions of people editing documents at the same time in the workspace, what we did was to copy our standard MSDN template Word 2007 xml file for each contributor. This assured that they would be able to contribute freely without worrying about who else was in the document when they were. Once completed, I was responsible for editing and merging the documents back into a master composite copy (using Word 2007’s merge document feature).
For editing and commenting from our tech reviewers, we did the same thing. We made copies of the composite document which they could freely edit and mark up which I merged in and applied their edits to the master copy. All the while, I was synchronizing with the SharePoint site. We also had .one files in the folders for each white paper so we could share hand drawn or text notes on the topic.
Great Collaboration Experience:
It was really one of those great collaboration experiences where the technology worked like it was supposed to. Quietly, reliably and without issue. No document collisions, or burned documents or uh-oh moments. One great benefit is that I saved the workspace invitation within the workspace itself. Thus, any member of the the workspace or visitor to the SharePoint site could join the workspace themselves or forward it on to others. The popularity of this project inside Microsoft reached fever pitch when at one point we had over 75 active workspace members.