Doculabs consultants see a lot of SharePoint in our work with clients. It’s safe to say that 99% of our consulting clients have SharePoint in some form or other, and 75% have a substantial SharePoint footprint enterprise-wide. And while each client’s experience with SharePoint is distinctive, there are some common threads:
- Struggle to create, enforce, and maintain basic governance: Once the SharePoint genie is out of the bottle, it takes on a life of its own, and folks like IT, Legal, Records Management, Corporate Communications, and HR have their work cut out for them trying to manage end-user behavior.
- Difficulty realizing the full benefits of SharePoint usage: SharePoint is a tool that holds great promise for organizations looking to improve their information lifecycle management, but figuring out how to deploy SharePoint so as to deliver on this promise has proved more difficult than anyone could have imagined. For most of my clients, SharePoint’s main use case is basic shared drive replacement, and in most cases it provides little added benefit over those shared drives.
- Conflicts with other enterprise applications: SharePoint is a bit of a jack-of-all-trades application: it tries to deliver “good enough” functionality across lots of enterprise content management (ECM) areas (e.g. workflow and collaboration, document management, portal/web content management and records management). But most organizations already have other systems fulfilling some (or all) of these capabilities, so figuring out which system should do what becomes a real challenge.
Given these common themes, one of the planks in my SharePoint soapbox platform is information architecture (IA) – i.e. the way your SharePoint environment is organized, from the overarching structure of all your sites, down to how documents are named and stored. And while taking the time to address IA concerns isn’t a silver bullet to solve the three issues above, you definitely can’t solve them without it.
Let’s take a look first at what IA is and then how it can help you improve the effectiveness of your SharePoint environment.
A (Very) Brief History of IA
Richard Saul Wurman is widely considered to have coined the term “information architecture” in the mid-1970s (as cited in Information Architects, Richard Saul Wurman and Peter Bradford, editors, Graphis Press, 1996). He describes the information architect as one who:
- Organizes the patterns inherent in data, making the complex clear
- Creates the structure or map of information which allows others to find their personal paths to knowledge
- Addresses the needs of the age focused upon clarity, human understanding, and the science of the organization of information
As it’s commonly approached today, IA is a discipline and a set of methods that aim to identify and organize information in a purposeful and service-oriented way. (Some of you may also be familiar with it as a term used to describe the resulting document or documents that define the facets of a given information domain; see Information Architecture by Michael Cummings [2009]; retrieved 5 July 2011 from Interaction-Design.org).
And the goal of IA as it’s commonly approached today is to improve information access, relevancy, and usefulness to a given audience, as well as improve the publishing entity’s ability to maintain and develop the information over time (also from Michael Cummings).
SharePoint without Effective IA
When you net it out, IA is really about what’s not obvious: Users tend not to notice the IA of a site unless it isn’t working. And when they do notice good IA features within a site, they instead attribute these successes to something else, like high-quality graphic design or a well-configured search engine. But no matter how transparent IA is to the end user, its importance for that end user’s experience can’t be overstated: A good IA pretty much ensures a good user experience; a bad IA pretty much ensures a bad user experience.
For my money, nowhere is the pain of bad IA felt more acutely in the business sector today than in SharePoint. Given the petabytes of content managed in SharePoint across, say, the Fortune 500, and given how few of those organizations have built a deliberate, effective IA for their SharePoint implementations, it’s safe to say that the lion’s share of documents in corporate America’s repositories are a mess and that end users at those organizations are suffering the effects of the absence of effective IA.
The typical corporate SharePoint deployment exhibits one or more (if not all) of the following symptoms of poor IA:
- No rhyme or reason to site structure or site collection structure
- Thousands of sites, a large percentage of which are unknown/unknowable to the organization’s SharePoint administrators
- Content duplicated within SharePoint as a result of poor version management practices; also duplicated across SharePoint, shared drives, hard drives, and email as a result of poor information lifecycle management
- No consistent use of metadata (if it’s used at all)
The implications of these symptoms for end users are predictable:
- Multiple copies of documents in different locations and no way to tell which is the one you’re looking for
- The same folder hierarchy on SharePoint as on shared drives (i.e. the mess has simply been lifted and shifted to a more expensive tool)
- Lack of standard file-naming conventions, meaning users must open documents to determine what they are
- Orphaned or missing documents, so users spend significant time recreating documents that should (and likely do) exist somewhere
- Difficulty finding information unless you already know where it is, leading to usage of the classic “phone-a-friend” technique of finding things (that is, assuming they’re still at the company)
Effective IA in SharePoint
An effective IA can help alleviate these problems. It can help improve the effectiveness of your SharePoint environment by allowing you to better organize your content through:
- Standard file names
- Consistent site structure and folder hierarchy
- Relevant, accurate metadata (neither too little nor too much)
- Rationalized content types
The result of taking the time to build an effective SharePoint IA is that users more frequently know what to name their documents, where to find the documents they’re looking for, and how to navigate within and between sites.
Granted, there’s no “one-size-fits-all” solution to your SharePoint IA problems. But there are some high-level guideposts you need to consider as you plan for building a SharePoint IA. Like diet and exercise, they are somewhat obvious advice, but that doesn’t make them any less accurate; these are the things any organization needs to do to be successful with SharePoint over the long haul.
1. Make sure that you build time into the project to address key IA elements for SharePoint.
- Site structure – both the structure of the site collection and of individual sites
- File-naming conventions – determining what (and how much) metadata it will reflect
- Folder structure – whether to use folders and how to organize them
- Metadata – what fields to use, what content to attach them to, and which users need them
2. Make sure that you have the resources in place to maintain your SharePoint IA going forward.
- SharePoint IA owner – responsible for the viability and sustainability of your SharePoint IA
- SharePoint IA Center of Excellence – group of cross-functional end users, led by the SharePoint IA owner, who meet regularly to address issues relating to your SharePoint IA
- SharePoint IA champions – end users tasked with (1) representing SharePoint IA for their areas and (2) representing the needs of their areas to the SharePoint IA Center of Excellence
3. Make sure that you have the processes in place to maintain your SharePoint IA going forward.
- Top-down communications to educate SharePoint users on the importance of IA and how to work effectively within your SharePoint IA
- Bottom-up communications to inform the SharePoint IA Center of Excellence and the SharePoint IA owner about issues on the ground with your SharePoint IA
- IA refresh to revisit your SharePoint IA at regular intervals in order to assess continued effectiveness, identify gaps, and determine how best to close them
The Final Word
Although I’ll reiterate that there’s no silver bullet, hopefully the advice I’ve given here gets some of you on the path to effective IA in SharePoint. You should be able to connect the dots and see how much of the pain that end users experience is not a result of SharePoint’s limitations as a tool or because IT did a bad job standing up and maintaining the environment. Rather, too little time (or none at all) was set aside to think about your SharePoint IA – i.e. how the information in your SharePoint environment should be structured so that folks can more easily and effectively use it.
I’d love to hear from folks out there who’ve experienced the good, the bad, and the ugly around SharePoint IA – both IA practitioners as well as end users. What’s been your experience with SharePoint IA? Any one part of an organization that’s gotten SharePoint IA particularly right or wrong? Anyone have thoughts about my approach to the problem or solution?
As always, I love a good conversation and don’t mind being heckled, so jump in and let’s get the conversation started.