Where I work at, to say we do a lot of MOSS implementations is asking the question, “Does the pope have a big hat?” Of course, the question is yes, and one of the struggles that we have is structuring the Information Architecture of the site correctly. This is a fairly important issue because moving document libraries around after the information architecture is designed can present all kind of issues, especially for business users that are just barely learning the basics of SharePoint and don’t understand the difference between a list and a document library.

One of the biggest conclusions we came to is that the site map doesn’t necessarily reflect how the information architecture should be structured, and are actually designing to two site maps — one for the information architecture, and other for what the ned user sees. Complicating this is how Microsoft defines information architecture within SharePoint, and how the rest of us think about information architecture.

What to do?

Let your governance be the guide, and have an open communication channel with the SharePoint developer. From this conversation, we came to a few realizations:

• All information wants to be free (and sometimes in the same place). Some organizations need all documents in the same store vs. separate document libraries. That’s fine, so maybe filtering that document store based on personalization is the best approach. If more collaboration is needed, it’s probably a good idea to develop a workflow that promotes from a local document library to the document center.
• Sometimes designing to an organization chart isn’t a bad idea. Departments are still departments, and when they want to use MOSS, maybe they should think in silos (I almost can’t believe I’m saying this). Many times demanding that a full inventory of the site just isn’t possible because the site will evolve over time, so the best solution is to give them a design pattern to follow for the information architecture, and separate the departments enough so one department’s mistakes can’t affect other organizations within the company. When given a SharePoint deployment, some users are going to run with scissors, and you don’t want to have mass casualties because of poor information architecture.
• There might be several levels of navigations, but the user doesn’t have to see them. We’re working on an implementation where there a hierarchy of four levels within the department, however a grand total of 20 users will see all departments within the four levels. So we are designing a mostly flat navigation structure that still has all the levels intact, but the other 6,000 users don’t see the levels — they only see the navigation they have access to under governance policies. In other terms, design to the 80 or 90 percent, not to the 10 to 20 percent.
• It’s best to have completely separate project or publishing sites if they involve users that are from several different departments. This is basically designed around the ideas of audiences that are around projects, and that might be across several departments. A creative solution is designing a site that contains departments and projects in two different site collections, and treating projects more like team sites with some publishing capabilities. That allows different members from different departments to be associated with projects, and no projects to be associated with a single department.