Managing your information, and implementing a system to do it, is a complex task with many knots that need to be unravelled and it takes time to get it right.
All too often the focus of a project implementing such a solution is on getting it done rather than doing it right. Too much effort is spent moving the projects through various gateways rather than spending time on actually thinking through what needs to be done.
Information management systems such as SharePoint too often founder and ultimately fail to deliver the desired benefits because of this. Typically a system is rolled out successfully (i.e. on time) but it quickly degrades and information chaos ensues leaving users frustrated, information difficult to find and impossible to manage. In all likelihood you’ll end up with another project to put it right in a couple of years.
This situation can been avoided.
Proper thought must be given to understanding where you are and what you information landscape looks like. How can you build a system to manage your information if you don’t know what you’re intending to manage?
You must develop an information strategy so you know what you want to achieve and how you are going to go about it.
You must take time to design an information architecture that meets the needs of your users. This is vital to enable you to organise, describe and link information and the key to the efficient and effective use and management of your information.
And don’t forget about putting in place governance – without support, oversight and nurturing your nice new system will quickly end up a chaotic mess.
Remember that rolling out a system that meets a deadline doesn’t mean that you have a successful solution.
Think, plan, design – don’t just ‘do’.
I seem to be getting increasingly unhappy at the use of the term ‘metadata’ to mean the attributes of real world entities, as opposed to information objects. Here’s a response to an exchange on the LinkedIn Metadata Management pages. Am I just getting too purist (i.e. old and grumpy)?
Traditionally metadata has been information about information objects (I can’t bear that phrase ‘data about data’ which is very unhelpful). When a painting is digitised, as you suggest, for me it then becomes an information object, and accordingly would get metadata. Until that point, any information stored about the actual painting in the real world is cataloguing or description or …
I remember a meeting of the UK e-Government Metadata Working Group which produced the UK government metadata standard, where one member of the group suggested that information about events or buildings or people would qualify as metadata. Another member of the group exclaimed in a horrified voice ‘So a swimming pool can have metadata!?’ In fact of course a swimming pool can have a name, a location, opening hours, etc but that is surely data, not metadata. The webpage that contains the information about the swimming pool may very well – and should – have metadata, but that’s because it’s an information object.
I think the reason this bothers me is that when developing a metadata standard, which I often do for clients, I need to focus on the attributes of information, not the attributes of anything that might be mentioned on a webpage (for example). Otherwise I have to start including attributes for events, people, products etc etc, and thus my metadata schema becomes huge and unmanageable.
The taxonomy, on the other hand, needs to provide values for metadata and data, but that’s another discussion….
Many SharePoint implementations are unsuccessful. They do not deliver business benefit, are too expensive to build, too expensive to manage and are difficult to use by the stakeholders they are seeking to help.
SharePoint is a large, pervasive and complex system and as such is subject to the usual reasons for failure of all similar sized systems; but SharePoint in particular frequently fails because it has no information architecture underpinning the content, users and context of the organisation’s information environment. In most cases this lack of an information architecture is due to the implementation being IT driven. SharePoint in all but the most trivial of implementations is not an out‐of‐the‐box system – despite what many people believe and the Microsoft marketing machine suggests.
An Information Architecture within SharePoint is crucial because there are many design and configuration decisions that need to be taken before the implementation starts. In addition, many of the fundamental information structures within SharePoint are not easily changed once the implementation starts.
Information Architecture Phases
The information architecture activities for implementing SharePoint can be broken down into four phases:
- Analysis: Discovery of content and structures that already exist within the organisation
- Design: Creating the information architecture itself (see below)
- Configuration: Implementing the information architecture as determined by the design
- Testing: Validating the information architecture and reworking in light of user feedback
Key Aspects to Consider
The design of a SharePoint information architecture must consider a number of aspects of SharePoint functionality.
- Site Plan: Information to be stored and accessed within SharePoint must adhere to some overall structure. Whilst SharePoint does not implement a classical “fileplan”, one must be created never the less.
- Interface Structure (Usability): Once the site plan has been created this must be mapped to appropriate SharePoint interface structures.
- Content Types: Content Types are one of foundations on which much of SharePoint’s functionality builds. Therefore, getting the Content Types correct is of prime importance to any SharePoint development.
- Metadata: The metadata schemas to be used within SharePoint must be defined. This metadata is primarily related to the Content Types, but also in other key SharePoint structures.
- Taxonomies: Any controlled vocabularies required to populate metadata fields or define navigation structures must be defined.
- Search: Defining the parameters of the search and attendant user experience.
- Permissions Model: A SharePoint implementation must define the permission model that applies to it – namely who can do what to any given item of content.
- Workflow and Versioning: Any organizational document workflows that are needed must be defined.
- Policies and Governance: Whilst SharePoint allows significant codification of the information architecture and its usage, there will always be a need for policies and governance guidelines.
SharePoint lends itself well to having its configuration performed by information architects rather than software developers. The reasons for this are two‐fold: the detailed and comprehensive set of configuration options that are exposed via the administration user interface; and the pervasiveness of these options throughout the many SharePoint information structures.