SharePoint Intranet Implementation – CSF – Simplify the Contribution and Management of Content

CSF – Simplify the Contribution and Management of Content

Many Intranets I have seen over the years have been implemented with the focus being on a single consumer audience.  This model may work well for an Internet (public facing) site; however, I contest it is a model that doesn’t work well for Intranet implementations.  First and foremost, we have to implement a consistent model that makes the contribution and management easy for those who are performing updates and managing content on a day-by-day basis.  This requires us to separate the content contribution model from the visual representation of that content.

Common Mistakes

If you focus on the visual representation model first and use it as the basis for your contribution model, you will most likely have the following difficulties:

  1. Your visual representation will most likely only solve a single contextual need; meaning, it is quite common we have to re-purpose content to aid with different contextual business needs to support aggregation, search, dashboards and so on.
  2. Targeting content to be stored in a single location will require addition security, governance and maintenance.  I will explain more below.
  3. Content contributors will have to remember, or bookmark, all the various locations on your Intranet needed to get their jobs done.

Let’s first take a look at the single location for storing, managing and visualizing content of a specific type.  This is the common implementation model I see most often and the one I rarely use on Intranet implementations.  Corporate policies are common throughout most Intranet implementations, so I will use this as a basis for the following examples.

In the example above, all contributors and consumers visit a single site where corporate policies are managed.  This is, by far, the easiest implementation approach in SharePoint; however, not the easiest to manage.  The biggest problems you will encounter with this approach are forcing the contributor to go to this site to manage their documents and the management of policy document security.

First, an employee who works in the Human Resources department should be able to go to a single Intranet destination to perform all of their day-to-day duties.  Approaching the contribution and management of content using this type of model will make the contributors and owners of that content much happier.  Secondly, if you store all corporate policy documents in a single document library on a Corporate Policies site, you will need to manage item level security.  If you don’t do this, every contributor will have the ability to modify other departmental policies; and it will happen, I guarantee it.

I know, you can overcome the item level security maintenance nightmare in a few different ways; use folders (doesn’t promote findability, ugly navigation), use a document library for each department (doesn’t solve the problem with simplifying the contribution and management of the content).  Also, don’t forget about the different contextual needs you will encounter with regards to content consumption.

How can you avoid these mistakes?

Now, let me introduce you to a couple of alternative implementation models that will solve all of the problems described above!

The alternate approach displayed above uses a model where corporate policy documents are stored and managed at the department level.  Meaning each department is responsible for managing their own corporate policy documents.  This in itself solves the security model problem; you only need to manage the contributors for each department at their specific site level.  In addition, each departmental employee goes to their specific departmental destination to manage their corporate policies; thus simplifying the contribution and management of their content.  Another note; this also aids with solving that age-old question “where do I store and manage my content?”

This approach also provides you with the “All Corporate Policy” document view found on most Intranets.

The key to this approach is to uniquely identify documents of type Corporate Policy.  We accomplish this by using SharePoint Content Types.  Most Intranets I implement have a Content Type named “Corporate Policy Document”.  I assign this Content Type to each of the departmental specific document libraries where corporate policies are to be stored and managed; the difficult work is done!

You now have corporate policy documents positioned in a manner that allows you to aggregate them in many different ways too.  For example, it’s quite easy to create a search scope on all documents of type Corporate Policy Document, located in the Operations department or Finance Department.

The second alternative approach displayed above has the same basic site structure, contribution model and use of the “Corporate Policy Document” Content Type.  The only difference in this model is the documents being published to the Corporate Policy aggregate site in a PDF format.  Again, this is only an alternate approach and will cost additional budget to implement.  However, some companies would prefer published corporate documents be delivered on an Intranet in PDF format; thus reducing the read/view tools required by the consumer.

Conclusion

The suggested models I have provided above are not difficult to implement or complex in any way.  My goal is to change the way you think about separating the storage, management and visual representation of content.

If you have any questions or comments about the implementation approach suggestions above, drop a comment below and I will respond!

 

3 Comments

  1. Pingback: Enterprise App Stores on the Way?; Windows 8 in 2012; What’s Next For Microsoft? - SharePoint Daily - Bamboo Nation

  2. I agree with both concepts, however how would approach #2 scale in a large environment. Example, a School District with 250+ schools.

  3. Hi Mike,

    The example approaches provide you with a logical view of the implementation; not the physical information management layer. The goal being to get you away from thinking about centralizing the storage, management and dissemination of content. Storage and management of content has to be separated from the dissemination of content. In addition, separate the physical implementation layer (i.e. the technical information management details) from the user interface and experience.

    From an information management perspective, which I will be covering a lot more in future posts, the topology of your farm will play a key role. Smaller Intranet implementations can sometimes get away with physically implementing everything in a single Site Collection; though this is not a scalable approach nor one I use very often. Larger Intranet implementations will have departmental content stored in dedicated Site Collections. In my SharePoint Intranet Design series, which is coming soon, I will describe various approaches.

    Bob Mixon

Leave a Reply

Your email address will not be published. Required fields are marked *


− 4 = one

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>