The lost art of problem solving

A Tweet from @Northumbria_RM caught my eye the other day. It was a quote from a contributor to their AC+erm e-Delphi Study along the lines that “RM is something that should be done not something that can be bought and installed.” Nothing too controversial there you might think, after all its what we records managers always say: ‘no quick fixes’, ‘get the processes and standards right first’, ‘try to install a system on a mess and you just have an expensive mess’ etc etc

But what if we are wrong? What if this conventional wisdom is more a reflection of the nature of most records management technologies than representing a universal truism? Sure it’s a certain recipe for failure to attempt to rollout an EDRMS without having prepared every inch of organizational, procedural and cultural groundwork in advance but maybe that’s because of their nature: their size, the (unrealistic) scale of their ambition and their sheer (over?) complexity. But need it be so? After all, most of the technology which is transforming our organizations and our lives seems to be heading in the other direction. We now live in a widget-led world with people designing simple specific apps to solve very specific problems or achieve very specific end results. Take the recent Apple i-phone advertisements extolling the eclectic range of apps available for download, or the simplicity of something like Twitter.

It seems to me that what our users actually want and that we should be finding ways of providing are simple, specific ‘RM apps’ that can be quickly, cheaply and simply ‘bought and installed’ to solve specific problems. Maybe the underlying problem is that we have spent the last decade looking at the problem from the wrong end of the telescope. We’ve been focusing on trying to fix the entire organization whilst hoping that eventually some of the benefits might trickle down and be felt by the ordinary user; where, with hindsight, we might have been better off working out what the problems were that were holding back individual users and building specific solutions to fix them.

When I first started out in records management in 1996 it seemed to me that records management was about finding creative and practical answers to genuine and specific problems in relation to how people managed their records. We needed a means of coordinating retention actions across multiple systems, so we designed one. We needed a way of maximizing the storage space we had available so we designed a location control module that meet our needs. Now of course the talk is of enterprise-wide solutions and international standards. I have no problem per se with either of these but do wonder if together they have unwittingly led us to a situation where all we have to offer is a homogenized, ‘one-size-fits all’ version of records management where we have little choice but to try to shape our problems around the available solutions and where our only route to success lies in trying (and largely failing) to first achieve organizational and cultural change on a scale which is frankly beyond both our reach and our pay-grade.

So it was with rather envious eyes that I read about the forthcoming Repository Fringe Challenge with a bunch of repository developers fired up to come up with genuine, workable solutions to an actual specific problem that is taxing their user community. This isn’t sitting back and hoping that the standards bodies and vendor community eventually acknowledge the problem and build in functionality to their products that are designed to suit everybody. This is a bunch of enthusiastic guys sat round PCs, thinking the unthinkable and finding cool ways of making it happen and then giving it out to the community to use as they see fit.

It’s a way of working and thinking which records management seems to have lost, and I think we are all the poorer for it.

It's the conversation, stupid

The thing l like most about Google Wave (at least from the YouTube presentation) is about how everything is geared around the content. Technologies and even concepts that we take for granted as essential, distinct entities in their own right such as email, blog posts, word processing software - even the document itself- all start to seem strangely artificial and inconsequential: what matters is the content and, most importantly of all, the conversation that it represents. It is this conversation or, to be more accurate, these multiple and ongoing conversations that are central to the Wave philosophy with everything else built to enable, support and manage them.

Now from the records manger’s perspective this might all sound like a bit of a nightmare: seamless, perpetual conversations with everyone free (by default) to edit everything. Where is the record? Heck, what is the record? But just as some of the concepts underpinning Wave require us to rethink most of what we take for granted about information creation so too it will its management.

Funnily enough this is similar to a point I made yesterday during a Podcast discussion with James Lappin, Elizabeth Lomas and Stephen Dale (I’ll provide a link when it’s up) which was made before I had any real knowledge of what Wave was about. That is that records management in the future will not be about managing individual objects all with finite and predictable lifespans but about capturing the numerous links between them as part of an ongoing thread if, when and how they are used.

It’s about the context. It’s about the conversation.

A step closer to making Records Management2.0 a reality?

Readers of ‘Managing the Crowd’ will be aware that I ended the book with some suggestions regarding how records management functionality could be successfully integrated into and applied to Web2.0 content. One of these was to create “a folksonomy service that can penetrate ddep content, at an individual content level, across multiple service providers". I argued that the logic underpinning social bookmarking tools such as Delicious already took us many steps forward in this direction. Obviously at present they are only used for resource discovery but (I argued) there was no reason why this functionality could not be extended to also allow the individual user and the ‘crowd’ to which they belong to also assign retention and management criteria alongside search metadata.

At the time of writing the book the main factor preventing this from making the leap from theory to practice was that “at present, Delicious works at a level above that required for our purposes. It may allow users to tag individual web pages, but does not extend this functionality to enable tagging of ‘deep web’ content, for example documents within a Google Docs account and presentations within Spresent.” (pg 131).
Earlier this week I was sent the following email announcement being sent to all owners of lists hosted by the JISCmail service.

“From Tuesday 16th June, every list homepage and every posting stored on the JISCMail online archives will include a bookmark/share button which will have links to a selection of social bookmarking/sharing sites.

Social Bookmarking allows you to share, store, organise, search, tag and manage webpages you would like to be able to revisit in the future, or share with others. For example if a posting is made to a JISCMail list that you know will be of interest to someone else you can email a link to that person using our button. Alternatively you can choose one of the social networking sites you are registered with, e.g. Twitter or Facebook, to share the link with a group of people. You might use the sharing button to bookmark a link to your list homepage or a particular posting on a list that you can revisit at a later date on a site such as Delicious.”

So there we have it: it is now possible to extend the reach of social booking down to an individual file level (in this case the millions of emails archived on the JISCmail website). Now, of course there may be many other technical, professional or practical obstacles preventing the realisation of my idea but it seems to me that one potentially major one may just have disappeared…