SharePoint Branding Part 7 -The ‘governance’ of it all..

Well, here we are! After delving into dark arts where everybody but metrosexual web designers fear to tread (HTML and CSS), we then delved into the areas that metrosexual web designers truly fear to tread (packaging, deployment and even some c# code!). Finally, we get to the area where everybody is interested until it happens to get in their way! (Ooh, I am a cynical old sod tonight).

That is Governance!

May I start by quoting from that wise band “Faith No More” and their first hit “We Care A Lot”, who in 1987 were of course thinking of collaborative document management when they wrote..

“We care a lot about the gamblers and the pushers and the geeks
We care a lot about the crack and smack and whack that hits the street
We care a lot about the welfare of all the boys and girls
We care a lot about you people cause we’re out to save the world

And it’s a dirty job but someone’s gotta do it”

Now, we are only going to talk about governance in relation to branding here, which is really a pimple on the butt of the overall governance of SharePoint. In saying that though, much of the philosophical basis from which I write this article is pretty much applied to the other areas of SharePoint governance anyhow.

So, what are we trying to do anyway? If you go and google or wikipedia the subject of governance, you can pretty much summarise the academic definition as “cover your ass”! Whether you are answerable to the CEO of a blue chip with a billion dollar market cap, or to the CEO of a 25 user small business, if you are going to take the fall, you want to make sure you take a few others with you, right? 🙂

Therefore, one of the first governance issues to deal with is the fact that we need a team with well defined roles and responsibilities. Each team will cover off different areas of SharePoint governance that can broadly be grouped into a few different categories:

• Project Management
• Infrastructure
• Development/Design
• Operation
• Training

Now, you may group things a little differently then me, but you get the idea. I have deliberately NOT listed design (and with it branding) separately because it depends on the type of SharePoint project being implemented. If it is a web content management oriented project (like an internet site), then design probably warrants its own category. However, if it is a collaborative project, then design is quite likely part of development process.

I think this point deserves further consideration.

WCM vs Collaborative Sites

SharePoint is a multipurpose beast. It can be used as a straight out CMS system and compete with the likes of Joomla, Drupal, RedDot and EpiServer. It can also be used as a document management system, management reporting tool, project tracking system, collaboration platform and so on and so forth…

When used as a CMS only, it’s pretty good, all things considered. There are some pretty snazzy examples of WCM sites that make you stop and think, “wow – is that SharePoint?”. But the typical visitor to a WCM based SharePoint site will not likely be using many of the other goodies that SharePoint offers. In these type of sites, there are a few content authors, but mostly the people using the site are visitors consuming the web content. Really, that’s about it.

But if you have been reading this series of articles, I spent the first three talking about how much of a pain the core.css and application.master issue is on corporate branding. If you haven’t, I suggest taking a look.

The issue is that many aspects of collaborative functionality use parts of SharePoint that is tough to brand. Cameron Moll has written a brilliant article on this issue and I consider it mandatory reading. Many collaborative functions are based on a central master page called APPLICATION.MASTER. Therefore, if you have made a well branded master page for your content, the user experience will be inconsistent when they perform certain administrative type tasks.

Cameron nails the issue perfectly here: “This is all perfectly fine in the CMS scenario, as only an infinitesimal fraction of your users will switch between published screens and admin screens. However, in the collaboration scenario, nearly any user can, and will, switch between published screens and admin screens to complete tasks. Because your skinning won’t be reflected in the admin, what should otherwise be a continuous visual flow for users instead becomes a jarring transition from your beautiful theme to SharePoint’s vanilla theme and back again”.

Now this entire series of articles has been based on the ‘other’ side of SharePoint (i.e. *not* WCM). In my opinion, in a purely collaborative SharePoint implementation, branding should be one of the last things you do. Your time is better spent refining collaborative functionality. However if you are doing WCM, it should be one of the first things to do.

You can imagine then, that the worst case scenario for all involved in a SharePoint project is mixing WCM and collaboration. It carries with it the exact same type of problems and risks that I outlined in my article on collaborative document management vs records management. Try and do both, and you will not only dilute the benefits of each, but you end up with an over time/budget process with plenty of pissed users and stakeholders.

Moral of the story? Decide what you want to be!

So let’s move on.

Best Practice Standards

A while back, I posted a series of articles on best practice methodologies and the laws around compliance. For many areas of governance, much of the work is done for you by these best practice standards. Certainly, aspects of the ITIL books on ICT change management, deployment management, design and planning and operations management will factor in branding governance.

I hope for people who have read those articles wondering why I included my four articles in a SharePoint oriented blog, you should see it all start to come together now. They are your philosophical starting point to approaching SharePoint governance

For what it’s worth, although ITIL is currently flavour of the month for many IT departments, I think that you can get a lot out of ISO27000/27001 and COBiT as well. ITIL is very inwards facing in a lot of its subject areas. What I mean by that is that non IT Senior management and board level tend not to give a crap about ITIL, but are likely to have more of an interest in COBiT, particularly in the US (not just because it has prettier pictures either). COBiT is a much “higher level” standard than ITIL, and is a better philosophical starting point than ITIL which is more prescriptive. In reality the standards well complement each other, but if you are wondering which one to start on, I’d go with COBiT. (Another much more detailed post on SharePoint governance against these standards is in the works).

It’s a dirty job but someone’s gotta do it

So let’s start with some high level governance principles for branding a collaborative SharePoint site. Here is what we need to define and document.

• A management structure for supporting the development and deployment of branded MOSS Sites
• Key roles and responsibilities within this structure
• Policies, standards, guidelines, and decision processes required to support the deployment of branded SharePoint Sites

What are the rationales for setting up a framework to assign accountabilities?

• Knowing who is responsible for making decisions
• Knowing how decisions are made
• Knowing who is responsible for implementing decisions

In addition to this, branding governance aims to:

• Consistently provide a high quality user experience by ensuring that the branding governance plan is followed
• Establish clear decision making authority and escalation criteria so that issues are resolved on a timely basis
• Ensure compliance with established corporate style guide

Roles and Responsibilities

ISO27000/27001 puts a big emphasis on accountability. Without a strong culture of accountability, it is very difficult to adopt governance without it getting out of hand. One organisation I worked for had mapped out their process for dealing with the service desk and it was too big for an A4 sized page. It had to be printed on poster size and was the ugliest flowchart you have ever seen. This is a common symptom when clear lines of accountability do not exist. There is safety in complexity and ambiguity.

Thus, it is vitally important that the right roles are assigned the right responsibilities and people are fully aware of where their accountability lies.

The following table is a typical example of the roles and responsibilities of personnel involved in the governance of the MOSS branding. Depending on the size of your organisation, consolidate the roles and positions to suit. I’ve put the responsibility definitions into cleverworkarounds’ plain english to make it more interesting, but you may want to formalise these a little more if you use this 🙂

Role	Position	Responsibility
Steering Committee	Senior Divisional Heads Marketing Manager IT Manager SharePoint Architect	The buck stops here! If it all goes to hell, these are the guys who get burned! (but have no doubt they will apportion the blame all round)As a result of that prospect, they tend to like to signoff on all branding things! (and everything else too)Oddly enough, they also therefore believe that they provide vision and direction to the MOSS branding
Business Owner	Board Level Project Sponsor	The person who writes the cheques! They are who the steering committee answers to. Thus, people are generally very nice to them!They get to set the direction of what they want, even if their branding taste is dodgy 🙂 (If they try and mix WCM and Collaboration try and tactfully dissuade them)
SharePoint Support Team	Application Support Manager SharePoint Administrator SharePoint Designer SharePoint Developer	These guys take all the vision stuff from the Business Owner and Steering Committee and actually designs and develops the corporate MOSS brandThis team also resolves operational issues and enforces best practice in relation to the MOSS branding solution
Site Collection Owner	SharePoint Administrator	Activation of branding features is performed by the site collection owner
Infrastructure Operations Team	Farm Owner Site Collection Owner Infrastructure Owner	These guys keep the support team honest. They ensure that branding is packaged up according to policy and install those features/solutions to the farm. This ensures the technical integrity of the branding development

Policies and Standards

So now we have defined who is responsible for what, we can now put it all into policy.

Corporate Style Guide

The first thing you need to do is define a corporate style guide, or locate the existing one and refresh it via the steering committee. The style guide houses all relevant standards, requirements, and recommendations surrounding corporate brand. It is not a technical document, as it covers the tone, presentation and all implementation aspects, specifications, attributes and elements, summed up to present a brand consistently throughout all media.

This guide changes over time and its owner is likely the marketing division of the organisation and not just the SharePoint branding steering committee. It is best to engage with the division or individual that owns this guide, to ensure that the steering committee is in the loop during periods of review and updating.

Once you have an approved style guide, you can now apply it to SharePoint components.

Master Pages

If you adopt the principles of my earlier posts in this series, you may not need to have more than a single master page for your entire farm. A well defined master page with clever use of CSS override techniques allow you to offer different branding, yet using a single master page. If this is a realistic prospect for you, then it makes sense to enshrine in policy that you will only maintain one corporate master page.

Best to leave the master page in the master page gallery for the site collection. That document library has versioning and content approvals enabled. Thus, it eases change and configuration management, as well as packaging and deployment.

The master page should be named according to a consistent convention. I personally like to prepend the company name to the master pages, as well as layout pages as then it is very easy to see what components are customised from what is build in. I enshrine this in the branding policy as a mandatory requirement.

That master page should be well documented with all of the modifications made to it. Typically, if you have modified say, DEFAULT.MASTER, you will have to document modifications like

• Any assembly references added to the master page (see this post if you want an explanation)
• Any hard-coded links to other CSS files and the definition of new styles
• Modification of the HTML structure of the master page (e.g. Adding left and right borders to the default master page)
• Any examples of non-compliance with the corporate style guide

Layout Pages

A collaborative style SharePoint site may require additional layout pages. The rules pretty much apply as per master pages.

• Name them consistently with master pages (eg prepend company name)
• Document their setup, where it is used and why it was required

Styles

Corporate style sheet guidelines should be documented and these are a direct translation from the corporate style guide. Logo’s, fonts, formatting, colors, backgrounds, etc are documented either as mandatory standards or recommended guidelines in the CSS style guide.

In addition, CSS style sheets should be both well documented within the CSS file using comments, as well as documentation around the implementation of the style. If you have overridden say, some of CORE.CSS, then mention it in the comments for the style why it was done.

CSS styles should live in the Style Library for each site collection. Unless you have an exceptional reason, there is no point in reinventing the wheel and putting them anywhere else. Naming of CSS sheets should also be consistent with the master pages and page layouts. So if I was writing a governance policy for ABC corporation, I would use something like

• ABCDefault.master
• ABCWelcomeSplash.aspx
• ABCDefaultStyle.CSS

Site Templates

Although I didn’t cover site templates in this series on branding, the concept is simple. Once you have set up a site the way you want it, you can save it as a template that can be re-used for other sites. Certainly, it is common for project oriented companies to create a project site template with a particular combination of lists, web-parts, workflows, event handlers and libraries. Each time a new project is initiated, a site is created for that project based on the template.

This helps us to achieve the governance of a consistent user experience, as well as improving change and configuration management.

The process of creating a site template is potentially complex as the amount of collaborative functionality provided grows over time. Therefore, guidelines for the development of site templates must be developed to ensure they meet minimum standards. Potentially, site templates will be used by different organisational groups, with their own unique requirements. You will need to find a balance between overall site/branding consistency versus the costs and overheads of accommodating unique requirements.

Therefore, a formal approval process culminating with steering committee approval should be in place to manage the ongoing management of every corporate site template. The corporate style guide will also very likely influence the look and feel of custom site templates.

For each template, you also need to determine which parts of the template may be changed by site owners, and which may not. This can be enforced by security settings, but you still need the official policy to fall back on if tool based controls do not give you what you need.

Having said all of this, much of the governance around site templates is focused on non-branding considerations such as security, audiences, functionality and the like. We will not discuss this here as it is not really a branding consideration.

The point is, site templates have similar branding governance requirements to master pages, page layouts and styles.

Operational Management

In the previous section I looked at the governance requirements of branding from a SharePoint building block point of view. Now lets take an ITIL oriented perspective

Change management and approvals

With change management, go straight to ITIL and get what you need as far as process is concerned. ITIL defines the objective of change management as:

“The objective of Change Management in this context is to ensure that standardized methods and procedures are used for efficient and prompt handling of all changes to controlled IT infrastructure, in order to minimise the number and impact of any related Incidents upon service.

ITIL defines a CAB or change authority board that advises the ‘change manager’ prior to change approval. For my money, the steering committee will delegate the CAB function to the other groups who assume *custodianship* of the process. For example, the steering committee still bear ultimate accountability over the deployment of branding, but once the policy has been set, they delegate the validation of the deployment to the IT Infrastructure Operations Team.

Now bear in mind, we are talking about branding only here, and ITIL in the wrong hands can create ridiculous amounts of red tape.

But in relation to change management, this is the sort of stuff that should be considered.

• Change justification. Have we recorded the request (who and why)?
• Assess the impact of the change (cost vs benefit)
• Test the change. Any branding changes require comprehensive testing on a non production environment. You never know how various web-parts render, and a formal testing methodology must be defined to ensure that say, your latest snazzy style turns out to make the calendar view look crap.
• Packaging and deployment. Updates to branding should be packaged and deployed in accordance with corporate policy. The goal here is to ensure efficient, consistent deployment with easy means of rollback. We will delve more into packaging and deployment in a moment.
• Implement the change, update documentation and logs
• Conduct post implementation review of the change

Packaging and deployment of branding

Well, unless you are reading this series backwards, I think you should have a fair idea by now that I recommend that all branding should be implemented as a SharePoint solution. Check article four, five and six for more info. For me personally, I consider that if an application developer does not comply with this requirement (or whines about having to comply), then they have no serious idea about the importance of governance. That for me is a risk that I would prefer not to live with.

You will need to ensure that if 3rd party developers are doing your branding, that they are aware of all your other branding requirements, such as naming conventions so that the content packaged up inside the solution follows your governance standard.

When branding is packaged up into a SharePoint solution, we have a single file than can be easily deployed to the farm, upgraded and rolled back. In a disaster recovery situation, re-applying your branding is literally as easy as installing the solution and activating it.

Source control

On a large scale site, you may opt to use source control like Subversion for your branding components, especially if you are writing custom event receiver assemblies as I described in article six.

But then again, SharePoint itself is actually a great platform for implementing a governance site. You can make use of version enabled document libraries to hold your packaged solutions, procedures, standards and guidelines and other related content. Plus, you can use a calendar list+workflow for scheduling and notifying stakeholders of updates or changes, a task list for logging and tracking issues and infopath+workflows for automating the change management process.

Furthermore, I have found Colligo Reader to be very useful for SharePoint governance sites, as it alleviates the chicken-egg risk of storing all of your governance and change history in the same tool that you are governing. Often I am asked, “what if SharePoint is down, how can I get to my documentation?”.

Colligo allows you to have a full offline sync of all your governance lists, documents and views, thereby significantly reducing this risk and that barrier to adoption. I also suggest that you buy a copy of this product and add to your governance policy that you will always keep an up to date sync of your governance site offline.

Summing Up

So finally it ends. I originally thought I’d cover it all in 3 articles but in the end it took 7 large articles. But I’ve now gotten to the end of this arduous task of attempting to cover SharePoint branding from end-to-end. I hope that you have found this series of articles of use, and I appreciate you for sticking with me. If these articles were of help to you, please drop me a line and let me know. If you really want to show your appreciation, and you live in Perth, West Australia, I’m quite partial to Hoegaarden 🙂 (but if its your buy I’ll drink anything! 😛 )

over and out

Paul