Metataxis Blog

And it’s great to see the plug for the ISKO UK one-day conference in September on Linked Data, which should be a very good session http://www.iskouk.org/events/linked_data_sep2010.htm (so here’s another one – plug, that is).

Judi

Microsoft has fixed many of the annoying and grossly wrong features of SharePoint 2007. I won’t list what these are in this posting but I will summarise what I see as two very important areas of SP 2010.

What you can do “out of the box”. With SharePoint 2007, for all but the least demanding (or poorest!) organisations you eventually needed to write some bespoke code, or buy third party web parts, even if it sometimes took a while for you to realise this. This resulted in all sorts of issues: cost of implementation, cost of maintaining the code, missing in-house skills, upgrade complexities, and many other negatives. However with SP 2010, the point at which you need to resort to bespoke code is now much further away. There are now so many rich and easy to use tools for configuration, that the need for custom software development I see as being the exception rather than the rule.      

An achievable Information Architecture. Having spent many months for many clients, trying to design and implement useful and efficient information architectures with SP 2007, I know this is not always easy (it is possible, but you have to take some real liberties with the design to avoid significant bespoke development). With SP 2010 the situation is now very different. It has fixed most of the issues that used to make my life difficult. Content types can now be syndicated, as can metadata schemas. Proper taxonomy management is possible; tag driven or formal file plans can be designed, and many more.

Factor into the above two themes, the number of times the words “information architecture” were used by tech-heads at this year’s European SharePoint conference, then I’m starting to think that Microsoft has been bugging our offices…  

Marc

There have been numerous rumours of late of the fate of the National Programme for IT (NPfIT), the NHS IT programme which has come in for a lot of flack over the years.

The most recent article I read (earlier today) around its potential demise following the election later this year, made me think about an essay I once read by Clay Shirkey "In Praise of Evolvable Systems" which examines the numerous problems that centralised systems always encounter after the first flush of development - they start strong and improve slowly, plugging gaps, but never evolve fast enough to keep up with the surrounding environment (classic Electronic Document and Records Management Systems are a perfect example!), whereas evolvable systems start out weak but gain strength exponentially. In terms of analogies - its like dinosaurs and mammals - mammals win every time.

So maybe the existing modules of NPfIT could adopt a more evolutionary approach to assessing technology that the NHS needs to flourish. The original principles that the programme was shooting for have become obsolete - but they are so monolithic and expensive that there is no wiggle room. All systems need wiggle room!

Anyone whose interested, Shirkey's original article is filed here: http://www.shirky.com/writings/evolve.html well worth a read.

Cerys

Great attendance at the discussion session on SharePoint for Records Management yesterday with James Lappin and myself - hope you guys enjoyed it as much as I did! Thank you to everyone who submitted questions - sorry if yours didn't get answered in the day - never fear, James & I will be posting the answers to the questions here, and on his blog (http://www.thinkingrecords.co.uk) over the coming week, and just possibly on a new blog dedicated to questions on the subject of SharePoint & RM (watch this space...).

Aynway, here are the list of questions we gathered ready for yesterdays session:

How would you describe sharepoint if someone who knows nothing about it asked you to explain it to them?

Can you give a comparison of functionality for records management between SharePoint 2007 & 2010?

Are there any case studies of any public sector organisations out there using SharePoint successfully on its own - and without significant customisation - to address their RM needs?

Is there any point in trying to implement RM in Moss 2007, or would it be more cost and resource-effective for us all to spend our energies in getting our information governance policies and rules in order to prepare to 2010?

It would be good to hear your views on the viability of adopting a classification scheme in SharePoint that is based largely on LGCRS.

What are SharePoint's capabilities for the management of hard copy records?

Can SharePoint be used as a digital archive?

Is there any recent literature which usefully tackles the subject of SharePoint and records management?

Any more for any more? Either post in the comments, email me direct: cerys.hearsey@metataxis.com or tweet us using the RMS conference hashtag #rms2010 and we'll add your questions to the pot!

Cerys

At this years RMS Conference in Manchester (22nd & 23rd of March) - James Lappin (Thinking Records Ltd) and myself will be presenting an interactive question and answer session around SharePoint 2010 and what it means for records managers - the idea is that the answers to the questions etc are then written up post conference and posted here, and on James' blog.

So - what are your questions? What are the SharePoint 2010 questions that are burning away in the back of your mind? Email them to me (cerys.hearsey@metataxis.com), or tweet us at @Metataxis or @JamesLappin and we'll hopefully include your questions in the session, and the subsequent write up!

Cheers, Cerys

Call me naïve, but I'm constantly surprised at how little most organisations seem to know about their own information. Like how much they've got, where it is, what it is…. But that's good news for us, as we're often asked to carry out surveys or inventories of electronic and/or paper documents and data, usually as part of a wider information management piece, and they always provide a fascinating insight (for us as well as the client!) into each organisation's business and how it's carried out.

There are many reasons why you might want to carry out an inventory, for example:

• to identify vital business information (especially records)
• to support information governance, eg DPA, FOI or RUPSI requirements
• to support the migration of existing documents, records or data into a new environment
• to investigate possibilities for system and process integration
• to support the easy production of an Information Asset Register
• to inform file plan or taxonomy development
• to inform the development of document templates
• to plan for future storage requirements.

I’ve just completed an inventory for an organisation of about 700 people, and almost all of the above apply, so the inventory is pretty extensive and includes over 80 questions for each ‘collection’. The main difficulty has been identifying just what a 'collection' is in this context, as there are business documents such as you get in every organisation, but also extensive data sets, databases and publications which may all have a relationship to each other.

Our approach is to identify the teams (that in itself can be a challenge!), and create a profile of the team in terms of their function, but also in terms of the kinds of documents and records we can see that they use by analysis of file shares. This gives us a very preliminary view of the potential scope of each team's content. Interviews with the teams will then reveal 'collections', ie coherent bodies of content used for specific business purposes. Sometimes these will be distinguished just by the business purpose, but sometimes format or location will also be a factor.

When the inventory has a relatively straightfoward and focussed purpose, it is very useful to send out the questions beforehand, but you have to be sure of your clients and their content before you do that. If I sent out my 80 questions for the complex inventory, I think people would run! So interviews are vital, but quite often people don’t know all the answers themselves, and you need to talk to other members of the team to get the whole picture.

We use InfoPath forms to record the information and create tailored reports so it's easy to find out how many of this and what kind of that, otherwise you can spend hours analysing each questionnaire. The questionnaires and profiles are then all stored on a SharePoint site that is open to all to look at and query (but updating of the information needs to be carefully controlled, obviously).

Carrying out an inventory can take anything from 2 weeks to 6 months depending on exactly why you’re doing it, how complex the content is, and how many people you have working on it. Another contributory factor is how well people know their own information (and no-one is going to be able to answer the question ‘how many spreadsheets do you have?’), so the more you can do for yourselves by using tools to analyse file stores, for example, the better. We’ve developed tools to count numbers of documents and analyse formats, and that helps a lot. And when calculating how long it will take, don't forget to add in the time it takes to set up the interviews, and to set them up again when people forget or cancel.

As well as the documentary evidence (ie the profiles and questionnaires), we always provide a report which highlights the main findings of the inventory, and there’s always something in it which surprises the client, whether it’s the sheer number of documents per person, or the number of Excel spreadsheets across the organisation (an important consideration if you’re thinking of migrating them to SharePoint, as it really doesn’t like macros at all), or the number of different repositories, or the fact that so many key assets are stored by a third party (fine if they’re archived material, but less good if they’re current IP). Which goes to show that inventories are extremely useful things.

- Judi