My article ‘Getting SharePoint right: Thinking about the ‘big picture’’ in the Journal of Digital Media Management is now available online. See Volume 4, number 1 at www.henrystewartpublications.com/jdmm/v4.
The future is all around us. We are experiencing change affecting all aspects of our lives – from the professional to the personal. Although we don’t know exactly what the future holds, we can be certain that in 5 years’ time so much will have changed. But change does not have to be negative or scary: doing things differently is not intrinsically bad, but we do have to come to terms with how the changes will affect us both personally and at work.
We believe that the information profession is facing exciting opportunities and now is the time to grab them with both hands! Yes, some roles will undoubtedly disappear, however new ones are appearing. These changes will definitely impact on how we interact with and support our business users.
To our minds one key way of coming to terms with and embracing change is to understand and actively engage with the elements of change – that way one can reconcile and adapt to change, taking advantage of the opportunities it brings.
Noeleen Schenk (Metataxis) and Sheila Moorcroft (Realising Your Future) have been doing just that. We have started a series of conversations with thought leaders in the wider information and knowledge management discipline. The aim of the discussions is to identify key trends that are already affecting (or will do so in the near future) information and knowledge management, considering what this could mean to the profession and how it will impact on how organisations create, use and manage their information assets. A summary of the discussions to date can be accessed here.
In order to facilitate our conversations, we have created a LinkedIn Group and will be holding regular (every 3-4 months) evening meetups. We would welcome as many people as possible to join both conversations.
The first meeting is on September 6th (NOTE CHANGE OF DATE) in London – details and booking via Eventbrite.
The blogosphere is full of SharePoint consultants proclaiming how folders are a terrible thing. Many of the articles are from, I suspect, SharePoint consultants who have just realized that information architecture (specifically metadata in this context) is something useful, and aren’t sufficiently concerned about bringing round change-averse users.
Before I explain why some folders may be a good thing, let’s look at the standard “why folders are bad” list…
- Nested folder structures are usually specific to an individual user or team. True, but so can metadata be. This is isn’t an argument against folders, it’s an argument for naming things consistently and governing what they are named. i.e. have a well managed taxonomy. Also, as with metadata, it can sometimes be useful to have a truly local name for something, either because it really is a local thing, or you want to build buy-in from your users by letting them sometimes give things their own names (I am not saying there should be a free for all, just some concessions, sometimes).
- Folders tend to make content hidden. Yes they can, again if poorly named (like metadata). But this assumes hiding content is a bad thing, when in fact it can be a good thing. Namely, it’s useful to just show users the things that they care about in that moment, with nothing to distract them. This exact argument is the reason SharePoint views are so useful and powerful.
- Folders eat up the fixed portion of the SharePoint URL. Yes. Agreed. But only if you go crazy with folders. See my rule of thumb below.
- Moving files from one folder to another changes the URL if you link to it. Yes. Agreed. Especially if you don’t have an information architecture. But luckily there is a way round this – have an information architecture. If you have a good information architecture, content tends not to need to move around much if at all. Of course if you move documents into a different library the URL will break. The real answer to link rot is use document identifiers, that don’t contain their location. SharePoint provides such functionality (more or less).
- Maintaining security by folders in SharePoint is an administrative nightmare. Yes. Agreed. But something you often have no choice about, even with a good information architecture. Also, what’s the alternative? Rather than creating a folder to delimit the security, create a new library, or a new site. That’s just as bad (possibly worse) at fragmenting content.
- Finding documents is difficult. Yes. Agreed. It can be (see the need for an information architecture, ad nauseum..). But less so if you use folders and metadata. Check out standard SharePoint view functionality on how to do this. Sometimes the folder structure makes it easier to find what you want. We know that search doesn’t always work, whether you’ve got metadata or not, because you don’t know what you don’t know. Folders allow you to browse, which is frequently very helpful.
- File duplication. With folders you can store multiple copies of the same file in different folders. Yes. Agreed. But you can do this without folders also – across libraries and sites. Folders can make it worse, but file duplication across sites is far more common (many teams copy documents to their team site to ensure they can always be found). If this argument is simply extended, why not put all 30 million documents in one mega-library!?
- With folders there is only fixed one view. Yes. Agreed. But only if you only use folders: why not use metadata as well and get both the options? Why deliberately remove a useful way of organising and finding content?
- Sorting and filtering isn’t possible. Yes. Agreed. But only if you only use folders: why not use metadata as well and get all the options?
- Changing folders is harder. Well, sometimes. But change should be not so common with a good information architecture. Also, changing lots of metadata isn’t always easy either. Cut and paste between folders can be much easier.
- You lose context when navigating. Not really. There many ways of showing the folder context in SharePoint. Also, just using metadata can be worse, especially if you use multiple columns and filters simultaneously.
- Using nested folders is just like having a file share, why even both with SharePoint? Yes. Agreed. But only if you only use folders: why not use metadata as well and get all the options? Can you spot a trend here…?
- You can’t see how many documents are in a folder. Yes. Agreed. But only if you only use folders: why not use metadata as well…
- When you allow users to create folders, you are prone to misspellings and so on. Yes. Agreed. That’s why you need active governance, and templates (i.e. an information architecture). Metadata can be much more easily made consistent, but that requires upfront effort and ongoing management. All this is good, but you haven’t improved the situation by disallowing folders, you’ve just moved the problem somewhere else.
And now for the reasons why folders are OK in moderation.
- Usability. Users like them, a lot. You will have many other battles to fight with users when you ask them to use SharePoint. It’s very useful to give them something familiar while you simultaneously introduce them to the benefits of metadata, search, views etc.
- Grouping. Sometimes users need to have a loose grouping of content. Looser than a document set, and looser than can be easily defined using one or more metadata tags.
- Permissions. Folders can be used to group user permissions. See above. Not ideal, but much better than file level permissions.
- Default metadata. Folders can be used to auto-populate default metadata. This is one of my favourites. Ask a user to fill in a metadata field and they will baulk. Ask them to add a file into a specific folder (with default metadata) and they won’t blink an eye. Agreed that there are many issues with doing this, but with a stable information architecture it is achievable and results in good metadata with minimal user effort.
- Retention and disposal. Folders can be used to hang retention and disposal rules on. Of course content types can also be used for this, but sometimes that doesn’t fit your content so well.
- Hiding. Folders can be used to hide content. See above. It’s useful to just show users the things that they care about in that moment, with nothing to distract them.
And to round off, my rules of thumb for SharePoint folder use are:
- Many document libraries will not need folders. How many depends on your information architecture, which in turn depends on the content, context and users in your organisation.
- One level of folder is acceptable, but you have to convince me. I’d say I’m convinced 50% of the time.
- Two levels of folder are acceptable, but you really have to convince me. I’d say only 10% of libraries can justify two folders deep.
- Three levels of folder are not acceptable. If you need them, your information architecture is wrong. It needs shifting up a level, so that your one deep folder becomes a library, your two deep folder becomes a level one folder etc. (on some very rare occasions I have felt three levels of folder are permissible, but this is only in cases of very structured content).
To wrap-up, SharePoint folders have their place, and can be used in moderation. But don’t go crazy.
The future is uncertain – it cannot be predicted. However this does not mean we should not be identifying and analysing current developments that point to potential paradigm shifts in how we create, manage and use information and knowledge. These developments fall across the political, economic, social, technological, legal and environmental spectrum.
Analysing these developments by identify the driving forces will help us consider the future trends we are likely to encounter and the future we would like to create. By having structured and thoughtful speculation about the future, we can begin to prepare for whatever future may arrive. It is one of the important keys to business preparedness.
Noeleen Schenk from Metataxis and Sheila Moorcroft from Realising your Future will be holding a series of invitation-only workshops over the next two months as structured and facilitated conversations to explore the developments and identify the likely trends shaping and changing the generation and application of knowledge and information in strategy and research.
The aim of the workshops will be to:
- Identify predetermined elements (i.e. will persist in any scenario)
- Identify the driving forces (i.e. forcing the pace of change such as increased global competition)
- Decide which are current trends (i.e. current events that are variable)
The outputs of the workshop will be a series of trends which we will then survey participants to assess the impact / likelihood – possibly also an indicative timeframe or other measures for each of the trends, in terms of their relevance and implications for IKM in the next 5-10 years.
The findings will be more widely circulated next year.
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….
Metataxis had its second Summer party, but alas not in Regent’s Park as planned like last year. The rain forced us (!) to the pub. So unfortunately we had to spend the entire afternoon eating good food, and drinking in the Edinboro Castle. Maybe we will get sunshine next year!
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.
|Download this article.|
The two Marc’s spoke about how to effectively and efficiently evaluate your EDRMS requirements to SharePoint, using the IMSPIRE tool.
See our detailed post for more details.