There has been a transformation in e-mail use since the early days. Some of this is due to the fact that originally tools were just text (e.g. MS Mail). Now tools like MS Outlook with MS exchange are incredibly feature rich. Also e-mail was much slower back in the day with the time for messages to be delivered from servers often an hour or more. Now if e-mail isn't instant.....users complain. The tendency to use email as an instant messaging system is partly responsible for the degradation of the quality of writing - as noted, it has become a conversatoin rather than a letter, with 'chat'-grade grammar and phrasing. When looking at the collaboration profile of e-mail it has become increasingly permanent, with our email stores being used as a file store. It is not uncommon for users to have 1000+ unsorted emails in their inbox - hardly a well planned information system.
While email can sometimes be a planned collaboration between two parties, more often it's not. Email is a asynchronous, 'different-time' tool, however users are often using it as a real-time tool expecting an instant response. e-mail is perceived as cheap by users however the cost of maintaining the infrastructure (hardware,software and people)is substantial. e-mails sent from mobile devices are often more succinct than those sent from PCs. Policies need to reflect e-mail is the same as an external letter and how to use it in the organisation. Email has become the user's all in one communciation tool, people e-mailing colleagues across the office from them, transferring huge files in and out of the organisation. In some cases people may desire to avoid Face to Face confrontation and so they use email, even when it is far from the best tool for the job. Email has largely replaced the letter and this has raised a number of issues. One is the fact that an email can be produced swiftly and distributed widely; the agility of the medium leads to a lack of 'damping' - no time to reflect on the right thing to say; and almost no opportunity to pull the outgoing, hasty response from outbox (or mail room - or even to call the recipient's secretary and ask them to remove it, as I ahve done in my more hotheaded youth). Since email represents the organisation and can impact on personal and organisational reputation, this is a risk,
.Historically letter writing skills for business communication were part of training professionals in an organisation, nobody appears to train people in e-mail writing in a similar way. The storage of email needs to be tackled as it represents important business correspondence that needs to be filed and easily searchable. Businesses are using: document management tools like SharePoint, INVU, case management software, archiving tools like enterprise vault and also bespoke systems. Individualks may save emails to a local drive, have a message store set up in theior inbox or (like me) transfer important infomration to OneNote. But there tends to be a lack of coordination.Policies need to reflect e-mail is the same as an external letter and how to use it in the organisation.
As an indicator of the value - and the problem - of email, note that personal email quotas have increased to around 400MB from about 50MB. The use of archiving tools is helping to reduce the need for large quotas. Outlook .pst files have a 2GB limit. That people use email in this way is not a 'bad' thing, it simply highlights the need, demand and utility for an instant messaging type tool; however the trend is for all email to be treated as IM and that leaves us without a considered communication medium (as letters were). I am torn between whether I want my email application to include IM facilities (OCS goes someway towards this) or whether to keep them seperate and make email become more formal again - but for that to happen we need to see a general decline in email volume. Finally, it is worth noting the recent press announcments about Google Wave - touted as the successor to email. http://wave.google.com/
Director at Cloud2
It has been our observation that many, and perhaps most, SharePoint projects in the English (as distinct from Scottish, Welsh etc) National Health Service fail to a greater extent than they succeed. Yet the NHS has very strong needs for the types of solution that SharePoint provides, it has increasingly mature infrastructure and project skills as well as access to technical skills which are as competent as any other sector, whether provided internally, through contractors, suppliers (or partners as we like to call ourselves) and Microsoft itself.
In the course of our research 9and writing a much more extensive article on the subject) we have identified teh following core reasons why SharePoint projects fail:
In our development of the NHS SharePoint Solution Accelerator we hit the common problem of how to design a document library scheme that met the core needs for our clients. At the heart of this is a set of design goals, which can be simplified as:
- A single place to access information
- A simple means for creating/adding information (and a single place to save them to)
- High system performance
In an ideal world, one would store everything in a central, monolithic library, with powerful search, views etc to allow content access and rich metadata to locate the content in the library.
However prevailing wisdom around SharePoint suggests that an approach using many discrete libraries is preferred, using a Content Query web part to present aggregated views where ever they are needed on a site.
So we are left with these two extremes, neither of which is ideal.
The monolithic approach provides a single place to ‘look for’ information and to store information. However it relies on a large number of views being created to ‘slice and dice’ the extensive list of documents (generally measured in tens of thousands) into manageable virtual libraries. The use of Content Types helps support this approach in SharePoint 2007, allowing different content in a single library to have different metadata, security etc. It also makes it easy for content creators, as they only have to know one place to save their documents. Importantly, it addresses the classic problem of hierarchical taxonomies, namely ‘how to store a single document in more than one place in the structure’. Metadata driven views allows a Policy document on Infection Control (for example) to appear in both a ‘Policies’ and a ‘Public Health’ area. Ultimately this option is scuppered by the performance requirement. SharePoint struggles with this many items in a library.
The other extreme largely solves the performance issue, with a relatively small number of items per library. Also any views of that library and functions associated with it are clear and well defined because each library ahs a specific purpose. The danger that this ends up looking like a traditional Directory-like filing scheme, which forces users to look in different libraries for documents (and expecting them to know which library the document they seek is in) can be largely avoided by using Content Query parts to create filtered, sorted views of documents sourced across multiple libraries. Again, metadata is used allow a document to appear in multiple lists.This approach is undermined by the continued requirement that someone who needs to create or save a new document must know which library it is supposed to go into before it can be saved, and choice of the correct library will determine which content types, templates and metadata are provided.
Inevitably a compromise must be reached; however such a hybrid solution tends to have an element of ‘worst of both worlds’ in the way it works.
We have been developing some concepts to mitigate this, based on enhanced search, alternate navigation and pre-emptive actions. Even we don't have all the answers though. It’s a problem that will continue to vex both informatics professionals and solution developers for many more years, we suspect.