If you want to successfully implement SharePoint in your organization, then you need to clearly define and manage your information architecture (IA). There are a number of things you need to do to define your SharePoint IA and here are five critical steps to ensure you are on the right track.

Information Architecture in SharePoint

The best way to think about information architecture is that it’s a blueprint, a way to organize your information so it’s easy to find by the right people. And while SharePoint isn’t the only platform that is in need of a well defined IA, it is one, that if badly defined, can cause more information silos and frustrated employees than you can even imagine.

The key to getting it right, is to plan it right, from the start. Now we hear some of you smirking because you know that what you have now is in such a state that it seems impossible to fix. Rest assured, it can be done.

Planning your IA

Information architecture is a key element of your governance strategy. Governance is a huge topic for SharePoint, everyone talks about it, everyone has their own ideas on how to implement and manage a SharePoint governance strategy and the associated IA, and you know what? It’s all really good advice. But there’s just so much of it out there, how do you get focused and started?

We told you that there are a number of elements that make up your SharePoint IA, including:

  • Sites and Site Collection Structures
  • Content Modeling and Content Type Definitions
  • Metadata Schemas and Taxonomy Management
  • Search Integration
  • Managed Administration

You say, that’s great. I get it, but now what? Where do I start? There are five critical steps that you need to do/ask yourself and your organization to get you on the right track.

Step 1: Understand Where You are Coming From

A clean slate is great place to start, But it’s typically unrealistic. Maybe you are a new company and have the opportunity to plan your information architecture from scratch. Or maybe you have a pretty well defined IA with your current system, it’s just lacking some functionality that SharePoint can provide, so you’ve decided it’s time to move on. You are probably one of the lucky few.

Others come from a range of crazy fileshares, desktop folders, outdated intranets and multiple business apps. It’s like trying to find a needle in a haystack, unless you are the knowledge worker who has been with the company for many years and have developed your own little system of playing “where’s Waldo?”

For many, SharePoint 2007 was implemented in their organization in an ad hoc, sometimes grassroots manner. Which means that no one had central management of the platform. Divisions/departments and often groups within those divisions/departments were going along doing their own thing, building SharePoint sites, defining their own metadata, assigning their own permissions. Multiple copies of documents scattered across folders and sites, search severely lacking, but oddly enough, many people happy in their little worlds, because they could do what they wanted, and they could usually do it quickly.

What’s the point here? Know what you have now. Have it well documented and have a clear understanding of how the users of that current system(s) feel about it. Don’t assume everyone wants a change, regardless of how good it would be for the organization overall. If you don’t really understand where you are coming from, you won’t be able to properly figure out how to get where you need to be.

Step 2: Know What Players Need to be Involved

Is it obvious to you who should be involved in defining your new SharePoint information architecture?

  • The business users/information workers who use the current system(s) and will use the new SharePoint implementation. These are your advocates (including your devil’s advocates). If you don’t have some naysayers on your team, you’re missing the opportunity to convert a potentially large group of unhappy users -- these people can become your strongest advocates.
  • Compliance / record managers who know the rules and regulations that your content must adhere to.
  • Your current information architect, assuming you have one. Maybe this person hasn’t managed a central IA yet, but it’s likely they have been involved in one or more projects that involved knowing what content is out there, how the business works and what the business objectives are.
  • Your SharePoint 2010 Information Architect. You are going to need someone on your team that understands how SharePoint 2010 works. This is the platform you have chosen to work with, that means you need someone who knows how your information can be best implemented within it. You can define your IA without considering how SharePoint works, but we wouldn’t want to be the IT team trying to implement it.