I made a presentation with the JBoye SharePoint 2010 community this week. The topic was Metadata and Content Types in SharePoint 2010. We talked about the vast set of functionality that depends on these things and the potential value of giving metadata management som focus.
The core of the talk went into some best practices for managing content types across midsized and large organizations.
It is my experience that organizations are often not giving the area of metadata and content types the focus it deserves. Therefore quite a bit of information is still identified (using Content Types) as “items” and these documents have a tendency to disappear in the vast amount of data most companies put into SharePoint. Content Types are the capability to “type-cast” every single content artifact, to add a structure to the entire information corpus.
When implementing SharePoint, we need to get this topic into the IA work, early in the planning phase. The way we use content types may have an impact on the way we need to design the SharePoint infrastructure; using thing like Content Type Hubs, inheritance etc.
When hiring an Information Architect for planning your Intranet IA, you need to make sure that this person also have sufficient knowledge of how SharePoint works, and the capabilities it has. There are not a lot of resources available the really master both of these trades, so a fallback plan can be to build an IA team, where both competences are equally available.
Download the presentation here: Using Metada and Content Types in SharePoint
Here is the slidedeck from the SharePoint community meeting at Danske Bank late november. The topic was Site Lifecycle Management and Governance for SharePoint 2010.
Especially in collaborative environments, it seems that the ongoing growth of sites – both in terms of datasize and number of sites – are challenging for most companies. In this meeting we discussed how to establish a model around site creation, that defines a set of supported site types with relevant SLA’s attached to them.
Naturally this approach requires (at least it helps a lot) a custom site provisioning tool, but making this investment is probably a good one.
You can download the presentation here:
I recently read a post by Dan Holme on Governance for SharePoint, that I wanted to share.
In the post Dan is pointing out the trouble many business are having with separating governance from all the other thing they need to do to maintain a reasonably well managed SharePoint service. This is how Dan put’s it:
(You can read the full post here: http://www.sharingthepoint.org/blog/Lists/Posts/Post.aspx?ID=4)
“Governance is, without doubt, the buzzword of the day in the SharePoint space. Unfortunately, there is a lot of noise around governance, and the word has become overloaded with perspectives and guidance that cover the gamut from strategic management to project management to design and architecture to service delivery. Governance has become the “catch all” for anything that an organization believes it needs or is missing to make SharePoint successful.
In recent months, I’ve tried to frame the discussion of governance in order to provide some structure as well as sanity to the noise and hype. In my recent keynote at SharePoint Connections in Amsterdam, I laid out my perspectives on what governance means—from the business to the technical layer—and provided tools to help organizations move forward thoughtfully and effectively on their SharePoint journeys. In my opinion, governance is not about documenting everything and the way everything will be forever and ever; but is more about establishing a process that enables the organization to move forward, with each step and each new solution adding to the organization’s understanding of its information and service management requirements.
Where governance ends, management begins. While service governance defines the people, processes, policies, and technologies that deliver a service such as SharePoint, too often organizations stop when the governance document is complete. They discover—all too painfully—that it’s not realistic to simply “expect” that governance policies will be followed consistently, if at all. Therefore, it’s critical to consider how to make the service manageable in a way that enforces governance policies and, if possible, automates the implementation of policies.”
Excellent points – matches my experiences very well… So where exactly does governance end and management begin?
When implementing governance around SharePoint, it seems to me that the most efficient way it to look at governance as a practice. Instead of building governance documents as a part of the SharePoint implementation project, you will probably be better of establishing a governance practice.
So what it that, then? The governance practice is an organization that delivers on excatly the things Dan is mentioning. But the practice is a “living organization” that will not only define policies, but will also maintain them on a set schedule, and report status of each and every policy and how policy controls are doing.
And with the Policy Controls, we are starting to overlap management territory. First of all…There is NO need for a policy if we dont have the means to control it. So Policy Controls must be a mandatory part of your policies. But executing a control is an operational task that must be conducted by someone. That’s why you have a governance practice (it’s not just a board).
Some controls are made using management tools (and some are not). But even if it is a management tool that identifies a policy compliance issue, it must be reported back into your governance practice, as any failed control will expose a risk to your ability to deliver value with SharePoint. And at the end of the day, you are doing governance to manage risk, right?
So – what I wanted to get across here is, that there is a very fine line between management and governance, when it comes to SharePoint. SharePoint is a very broad platform – which is a big part of it’s succes – and in many companies SharePoint is used in completely different ways than the it-folks expected it to be, exposing a major risk to the business. If you want to overcome that- and stay in control – it is not a question of functionality, but more a question of your ability to define the service you provide, and maintaining a practice to control every single aspect – business or technical – of it.