A couple of OnePoint case studies

We have just got a couple of case studies published around our use of OnePoint, a combination of OneNote & SharePoint, and the value we are seeing from it.

The first will be published in Drug Discovery Today and you can read the pre-print here.

‘OnePoint’ – combining OneNote and SharePoint to facilitate knowledge transfer

The identification and development of novel drugs requires a multidisciplinary team of individuals whose membership changes during the lifecycle of a project. Incomplete knowledge transfer across this team can be a barrier to effective decision-making and efficient drug discovery. We have deployed a new infrastructure supporting information storage and distribution within small teams using Microsoft's SharePoint™ server technology in conjunction with the desktop application OneNote™. This delivers a user-friendly collaborative workspace that is fast, flexible and carries a low training burden. Demand from drug project teams for this ‘solution’ has now resulted in site-wide deployment to over 500 people across research.

The second case study, available here, was done in collaboration with Microsoft. In this case Microsoft also produced a video, see below, which really brings OnePoint to life (need Silverlight installed to view).

Pfizer Boosts Efficiency by 15 Percent with Easy to Use, Shared Note-Taking Program

For the past 150 years, Pfizer has pioneered the development of some of the industry’s most innovative pharmaceutical products. In 2007, Pfizer applied this “out of the box” thinking to a pilot program designed to enhance efficiency and knowledge management across project teams, and potentially speed time-to-market for new products. The pilot brought together the simple, intuitive user interface of the Microsoft® Office OneNote® 2007 note-taking program with the robust document management technology of Microsoft Office SharePoint® Server 2007. As a result, pilot participants reported a significant decrease in the number of e-mail messages they send each day, and one group reported a 15 percent increase in efficiency. Overall, the 600 participants reported a 2 percent time savings per week, which represents a cost savings of approximately U.S.$2.25 million.

People create silo's not technology

A couple of recent posts by Thomas Van Wal, SharePoint 2007: Gateway Drug to Enterprise Social Tools, and Dion Hinchcliffe, SharePoint andEnterprise 2.0: The good, the bad and the ugly seem to have re-started the SharePoint it's not really Enterprise 2.0 meme. These are both balanced articles and I agree with a lot of the points raised in them and certainly as with any application SharePoint has its strengths and weakness's. However one of the common criticisms of SharePoint is the rapid proliferation of sites upon deployment and I can confirm this from my own experiences, that in a large enterprise, within one year you can be looking at 1000's of SharePoint sites. But is this the fault of SharePoint? No this is a failure of deployment, it is a user failure.
SharePoint is no different to any other content management system and I've seen this same issue in every large content management I've worked with. There are two main reasons this occurs, firstly if someone does not manage the structure users will proliferate folders/sites in an uncontrolled fashion. In general people simply create what they need in that moment for their project. Secondly they restrict the access permissions, the assumption is that if they don't restrict access then someone will delete it/change it. Nothing creates silo's quicker than allowing users to control permission settings.
The implication in the 'proliferation of Sharepoint sites' comments is that if the companies had implemented a 'proper' Enterprise 2.0 tool set then this would not of happened. Sorry I don't buy this. It doesn't matter what the tool is if you don't invest resources in defining structure and allow users to manage permissions then you end up with a proliferation of silo's. I've heard of the same sort of proliferation of silo's occurring within wiki's based on Socailtext and Confluence, both of which allow user to create silo'ed wiki spaces. Even when the ability to set permission is inactivated or is not available, such as in MediaWiki, then you still need invest in wiki gardening to introduce and maintain structure as the wiki grows.
In the end it is not the tools but rather that those implementing social computing need to understand what they are trying to do. I'd guess that in many of the companies where silo's have proliferated it is more because the tools were introduced by people who understand technology not people/communities. In the end the whole social computing thing is not about the technology it is about the culture. If you don't understand the culture you are trying to create then don't be surprised if you end up with a mass of silo's.

Happily surprised by OneNote

Now those who know me know I'm no fan of Microsoft and I certainly have not been convinced by SharePoint but today I saw OneNote being used by a team to capture the day to day project thoughts, decisions and activities. This was done by using OneNote in combination with SharePoint. I have to say for the day to day transient project information this was working really well. The analogy is that they used OneNote as a project notebook that everyone has access to. It was organised by work area and had sub sections, essential a hierarchal file structure. What the team loved was the ease with which they could 'drop' information into it and the ability to move away from email.
Interestingly the person showing me this admitted that this was just a glorified file share. They also thought that OneNote only really worked for the project team. For those on the outside this environment is just too unstructured, maybe a little better than looking through someone else's file share but still with a lot of the same problems.
Now I've been trying to get people to use our corporate wiki to capture their project information and my first thought was 'Wow maybe I've got this wrong and wiki's aren't what is required!'. Then I recognised that different tools are needed for the capture of different levels of information. In this example the OneNote/SharePoint combination was capturing transient day to day information very well. However to capture the more persistent decisions and to support collaborative authoring of project documents then a wiki makes more sense. Finally as the project pass significant stage gates then the wiki page or sections of it can be published into a document repository to give a permanent snapshot of the project status. This model is very attractive as it seems to offer a way to manage the different requirements associated with the capture and sharing of different levels of information. I need to remember that one size does not fit all.