tfpl blog

Sharepoint: a viewpoint from IT directors

Charles Christian has posted onto  The Orange Rag a summary of a round table discussion between IT directors of Law firms  on SharePoint.  See Charles' post for the full summary, but below I have grouped together some of the points that most interested me:

What is SharePoint?

• Sharepoint is still perceived as all things to all men -what exactly is your firm trying to achieve and do with Sharepoint?
• Microsoft defined SharePoint as an Information Management Platform – it is a toolset with which a firm can create a multitude of applications.

SharePoint's phenomenal growth

• From Microsoft’s perspective Sharepoint is their number one business application in terms of sales, with over 100 million Sharepoint licenses, that’s one in 20 MS licensed PCs in the world using  Sharepoint!

Impact of SharePoint on the vendor market

• Some felt quite strongly that Sharepoint is and will continue to enable them to reduce the number of bespoke and niche applications they need.
  It was generally agreed that the vendors to have/are/will suffer from SharePoint are: 1) Portal vendors 2) Web Content Management solutions 3) Workflow solutions
• One prominent IT Director guaranteed that in 5 years there would be no Document management Systems (DMS) as we know it today instead this would all be done through and using Sharepoint.  Neil Cameron Predicated that fairly soon any enterprise portal/intranet will be run with Sharepoint

I like the point about SharePoint being all things to all men:  it has for example driven a coach and horses through the distinction between an intranets and a document management system.  I worked for one organisation which was rolling out a document management system for colleagues to store their working documents,  whilst replacing its intranet with SharePoint.  Pretty soon they realised that by giving every team the ability to create sites on SharePoint they were in effect rolling out two document management systems at the same time.

Google vs Microsoft: Google Sites vs SharePoint

In February 2008 Google launched the latest addtion to their Google Apps suite:     Google Sites.  It has been dubbed as Google's answer to Microsoft SharePoint:  an application that allows teams  and workgroups to create collaborative sites to share information and documents. 

Google are allowing any individual to create a Google Sites application for their organisation for free, and in minutes.   Google's hope is that the application will then spread virally within the organisation, as that individual invites other colleagues to join and collaborate with them.   

Google are by-passing IT departments, hoping that teams impatient with their organisation's systems will jump ship to Google Sites.

However Google are offering IT departments a way back into the loop.  Once a Google Sites application has reached a critical mass in the organisation then  IT departments may want to step in an take control of it.  Google have made provision whereby a Chief Information Officer can sign in and demonstrate that the or she owns the organisation's domain name. They willl then receive administrative rights over their organisation's Google Sites.   They also have the option of  upgrading to Google Apps Premier Edition, and at that point becoming a paying Google customer.

The risk of this model is that it poses a question mark over control of the sites. Could I see my team's collaborative site deleted by our Chief Information Officer who had subsequently secured administration rights?  Conversly, from a Chief information Officer's point of view,what would be the point of paying to upgrade to Premier Edition if I didn't get the ability to weed out reundant sites?

I created a TFPL Google Sites application this afternoon, simply by registering with my tfpl.com e-mail address.  If or when any of my TFPL colleagues creates an account for themselves using their work e-mail address they will be:

• told that there is already a TFPL.com instance of Google Sites
• able to see my name and e-mail adress and the names of any other TFPL colleagues who have already created an account for themeselves
• able set up collaborative sites within TFPL.com (the sites themselves are similar to wikis)
• able to assign access permissions to any site they set up within TFPL.com. They can choose between allowing all TFPL colleagues to see it, restricting access to invited colleagues ( they can  also invite people outside the organisation) or allowing the whole world to see it.

In theory if my other forty colleagues signed up we could be up and running with collaborative sites for our projects and programmes within a couple of hours.

See also  Sarah Perez's article on ReadWriteWeb   Is Google Sites the next SharePoint

The future of RM

Earlier this week, we hosted another free training course for our registered temporary workers.  The course, ‘From EDRM to Google Docs: what does the future hold for records management?' was led by James Lappin.

Around 30 of our temps heard James compare three different models for managing electronic documents  (EDRMs, Microsoft SharePoint and Google Docs).  The advantages and disadvantages of each were examined.

‘I thought James Lappin's presentation was excellent. I was particularly impressed with how the presentation was structured and the content thought out.’

‘James is clearly an excellent trainer and able to relate his knowledge of systems in a relaxed manner which makes the information easy to absorb.’

For more information about temps training events or temporary recruitment at TFPL contact katy.crosse@tfpl.com

What you do once you have successfully implemented EDRM?

On Wednesday I heard an extremely witty and informative talk by Ben Plouviez of the Scottish Government.  Ben is one of a select group of people who can say they have successfully implemented an EDRM system all the way across a large and important organisation.

Rolling out EDRM is a long old slog. You have to procure it; configure it; build your fileplan, your retention schedules and access rules; write your policies and procedures; pilot it; take it to every team, get their folders set up and get them trained.  By the time you've done all that you are three years older than when you started.

And what happens next?    Here is my summary of  Ben's advice on what to expect (or rather what not to expect)

• Don't expect a post -implementation party:  most of your project team will have found other roles in the weeks immediately before the end of the implementation project

• Don't expect much in the way of resources to manage and support the system:  Once you've implemented the system the organisation's attention, energy and resources will be diverted elsewhere.

• Don't expect to be able to find people with the multiple skill sets you need to support the system: your ideal support team understands the business and its operational needs; the technology and the configuration of the system; the organisation's records management policies, fileplan, access rules and retention rules; and the legal framework (particularly Data Protection and FOI).  There aren't human beings alive who combine all of these skill sets.

• Don't expect to know what is really going on in terms of usage of the system:  there are very few benchmarks out there for what constitutes good usage of an EDRM system.   Your system might be able to tell you that a certain team has saved a certain number of e-mails to the EDRM.  But what does that tell you? Should they be saving more than that? or less than that? Are they the right e-mails?  When you do come up with a good key performance indicator don't automatically assume that your system will be able to run you a report on it. 

• Don't expect the system to help with information overload: as the system grows and grows with more and more departments contributing to it and more and more documents on it, so the search results return more and more hits and the quantity of information overwhelms the quality of information.

• Expect technology to always move one step ahead of your EDRM:  How does the EDRM capture things like blogs, wikis and instant messages when these things were barely thought of when your implementation started?

• Don't expect your fileplan to survive organisational change unscathed: however hard you try to ignore the organisational structure when you draw up your fileplan, it will inevitably colour the fileplan and when the organisation changes the fileplan will need to be adapted to.

• Don't expect the work on the EDRM to ever finish!

Ben was speaking at Unicom's conference  'Preserving and protecting data and information assets'