I’m currently in the middle of a long series of posts on SharePoint information architecture (IA). We’ve covered a lot of ground, from the definition of IA, to the problems caused by not having an effective IA in SharePoint, to a consideration of the key mechanisms SharePoint provides to help you create an effective IA.

Last post, we turned from more technical considerations to the roles you need to create (and maintain) an effective SharePoint IA. Here, we’ll wrap up with a consideration of the following key processes you need in place for your SharePoint IA.

• Top down communications
• Bottom up communications
• IA refresh

Most of what we’ll cover here builds heavily upon the last post, so if you haven’t read it yet, stop and do so—this post will make a lot more sense if you do. Click to continue »

I’m currently in the middle of a long series of posts on SharePoint information architecture (IA). We’ve covered a lot of ground, from the definition of IA, to the problems caused by not having an effective IA in SharePoint, to a consideration of the key mechanisms SharePoint provides to help you create an effective IA.

In this post, we’ll turn from these more technical considerations to the people and process elements you need to create (and maintain) an effective SharePoint IA.

It’s all about the people

It might seem obvious, but if you don’t have the people in place to design, implement, and maintain your SharePoint IA, it won’t happen. Despite that, at practically every organization I work with, they short change themselves on the bodies needed—not just for IA, but for SharePoint in general. Click to continue »

I’m in the middle of a series of posts on SharePoint Information Architecture (IA) that’s looking at the key people, process, and IA-specific mechanisms at your disposal for creating (and maintaining) an effective IA for SharePoint.

Up to this point, I’ve been digging in to the IA-specific mechanisms, which are:

• Site structure – both the structure of the site collection and of individual sites
• Folder structure – whether to use them and how to organize them
• Metadata – what fields to use, what content to attach them to, and which users need them
• File naming – what (and how much) metadata will it reflect?
• Document types – how many, how many levels deep?

We’ve already looked closely at the first four, so we’ll wrap up our consideration of IA-specific mechanisms with SharePoint document types before turning in the next post to the people and process mechanisms. Click to continue »

I’m in the middle of a series of posts on SharePoint Information Architecture (IA) that’s looking at the key people, process, and IA-specific mechanisms at your disposal for creating (and maintaining) an effective IA for SharePoint.

In the first three posts, I’ve been digging in to the IA-specific mechanisms, which are:

• Site structure – both the structure of the site collection and of individual sites
• Folder structure – whether to use them and how to organize them
• Metadata – what fields to use, what content to attach them to, and which users need them
• File naming – what (and how much) metadata will it reflect?
• Document types – how many, how many levels deep?

We’ve already looked closely at site structure, folder structure, and metadata (check out the previous posts if you need to catch up), and will turn here to SharePoint folder file naming, a messy business under the best of circumstances. Click to continue »

I’m in the middle of a series of posts on SharePoint Information Architecture (IA) that’s looking at the key people, process, and IA-specific mechanisms at your disposal for creating (and maintaining) an effective IA for SharePoint.

Right now, I’m digging in to the IA-specific mechanisms, which are:

• Site structure – both the structure of the site collection and of individual sites
• Folder structure – whether to use them and how to organize them
• Metadata – what fields to use, what content to attach them to, and which users need them
• File naming – what (and how much) metadata will it reflect?
• Document types – how many, how many levels deep?

We’ve already looked closely at site structure and folder structure (check out the last two posts if you need to catch up), and will turn here to SharePoint metadata, a must-read for anyone in charge of a SharePoint deployment. Click to continue »

I’m in the middle of a series of posts on SharePoint Information Architecture (IA) that’s looking at the key people, process, and IA-specific mechanisms at your disposal for creating (and maintaining) an effective IA for SharePoint.

Last post, I began digging in to the IA-specific mechanisms, which are:

• Site structure – both the structure of the site collection and of individual sites
• Folder structure – whether to use them and how to organize them
• Metadata – what fields to use, what content to attach them to, and which users need them
• File naming – what (and how much) metadata will it reflect?
• Document types – how many, how many levels deep?

Click to continue »

I’m in the middle of a series of posts on SharePoint Information Architecture (IA). In the first four posts, I ran through what IA is, the problems caused in SharePoint when you don’t have an effective IA, and some of the key people, process, and IA-specific mechanisms at your disposal for creating (and maintaining) an effective IA for SharePoint.

With that done, I want to turn in the next series of posts to consider these people, process, and IA-specific mechanisms in more detail, to give you a fuller idea of just what it’ll take to create and maintain an effective IA for SharePoint. Click to continue »