Building the structure: Building an Information Architecture document for SharePoint.
Now that you’ve cleaned up your “old” SharePoint environment, you’re ready to build the new one. Basically, the goal here is to learn from the mistake you’ve made and redesign a SharePoint environment that fits your needs. At this point, you don’t need any developer. You just need a good business analyst that knows what SharePoint is in terms of structure (site columns, content type, list, document libraries, view, etc.). The outcome of this step will be what we call an Information Architecture document.
Excel is my favorite tool. You can also use tools like XMind or mind manager to print cool layout of your information architecture. But in the end, Excel will be the best way to filter through you information and copy / paste content from one content type to another.
Basically, your Excel file should contain about 9 columns.
Site collection: All the site collections that will be present inside you SharePoint environment
Site: All the sub-sites.
Parent site: This is how you can manage more than one level of sub-sites.
List: This will contain the list name and type. (ex: SharePoint documents (library))
Content type: The name of your content type.
Column: The name of the column inside your content type.
Column type: The type of your column.
Default value: Default value for the column.
Column content: For choice (do you really want to use a choice column?), lookup and manager metadata field, this is where you can specify the content of the field.
I’ve made a quick draft of what an Intranet with one sub-site (HR) could look like:
This kind of document works fine for small SharePoint portal. If you have bigger sites to build, I suggest that you elaborate the content type content in a separate document and only mention their name in there.
At the end, when you click on the filter arrow, you should see all your site collections, sites and sub-sites, lists and libraries and content types / sites columns. Make sure that you validate all the information with the business user.
You should now be able to give this document to a SharePoint developer or build a more complete Word document that will capture all the site collection / sites inside a table of contents (where you will find the same kind of hierarchy) and describe all the assets inside the sites (WebPart, etc.).
Here’s an example of what you should find inside that Information Architecture document:
In the end, you should have a complete document that will allow any developers to transform this concept paper into a real SharePoint portal. As this might sound like a lot of work, usually it’s a lot easier when you perform this work after working on a SharePoint 2007 environment for a while. Usually, you know exactly what wasn’t working and you’ve learn from your mistake.
If it’s the first time that you build an information architecture document, I found a quick trick that makes things easier. Try to think in terms of archiving / deleting documents inside you’re environment. For example, if you’re a company that sells products you could have a “Clients” site that contains a sub-site for each of your client. You could have libraries for contracts, documentation, product release, etc. In the end, if you don’t do business with this client anymore and you want to archive the site to free space, what will happens to the contracts?
For legal reasons, you might need to keep this kind of file for a longer period of time. So you would end up creating a “Contract” site to keep all the client’s contracts and one site per client for all other kind of documentation. Hopefully, you get the picture now.
Have fun while building your SharePoint Information Architecture document.