Category: SharePoint 2013

Content

SharePoint Operating Model: Part 3 – Content

nathanwells20142 Comments

Introduction

Now that you’ve set the strategy and direction for your SharePoint Operating Model, you can start to work through the 5 operational pillars. The first of these is Content. Content is the lifeblood of a Digital Workspace, be it transient working documents or carefully curated web content. Good content is a key driver for user adoption, and therefore something that warrants careful focus and attention when defining your Operating Model.

Content pillar in the op model

In this post, I will explore the key factors that influence the quality of your content, and what you can do operationally to ensure it is good. Things you need to think about in this part of the Operating Model include:

  • Your definition of what is and isn’t content. Where is the line drawn between content and enhancements/functionality?
  • How are you going to ensure content is always “good”? Does your definition of “good” content vary depending on the context/type of content?
  • How are you going to clearly define the boundaries between types of content, particularly at the site level?
  • A good Information Architecture (IA) provides the foundation for good content. How will you manage and build upon your IA post-implementation?
  • Are there any additional roles and responsibilities you need to put in place in order to deliver effective content on an ongoing basis?

I will consider each of these questions in turn as part of this post.

What is/isn’t content?

It’s important to define exactly where you draw the line in terms of what is or is not Content. Due to the fact that changing content is – in reality – still a change, there can sometimes be a bit of confusion between what comes under this pillar and what comes under the Enhancements pillar of the Operating Model. In SharePoint terms, I define Content as being information that can be added to the system, and the Information Architecture that underpins it. This is as opposed to functionality, which includes features and enhancements that need to be custom built and deployed. Another good way of splitting the Content and Enhancements pillars of a SharePoint Operating Model is to think of content as being anything that can be configured in the UI without needing to go through a formal development lifecycle. Anything outside of that is considered an Enhancement, and therefore subject to some of the controls you’ll put in place around change (see the forthcoming post in this series on Enhancements).

The diagram below shows some examples of what I classify as Content and what I classify as functionality (things that sit within the Enhancements part of this Operating Model):

What is content

What is “good” content?

In the Introduction to this post, I spoke about “good” content. To my mind, good content has four key characteristics:

  1. Useful: the content must be serve a clear purpose within the context of where it is located. For every piece of content, authors should be asking themselves questions such as “Who is my intended audience for this content?”, “What tasks do people need to accomplish having read this content?” and “What related pieces of information might they need to accomplish these tasks?”
  2. Trustworthy: the content must be the single source of the truth for that particular piece of subject matter or information. When users can find the same information in two different places, it compels them to make a decision about which one is the official source that they should use to accomplish their tasks. This is not a decision you want to force on your users.
  3. Fresh: related to trustworthiness, your content must be kept up-to-date. When users find information they know to be outmoded, it degrades the trust they place in all other content on your system. Even if the content is still accurate, if it has not been checked or modified in a long time, users will often assume that a more up-to-date piece of information exists and will continue searching. Again, not something you want users to have to do.
  4. Easy to find: closely linked to your Information Architecture (I’ll come to that later in this post) is how easily users can find or discover your content. Users can find your content via search, or they might be linked to it via navigation. It might even be content that’s dynamically surfaced on another location, but making the content easy to find is an important consideration.

As part of your Operating Model, you should think about your definition of “good” content, as it will frame some of the policies you later define as part of Governance. Later on, it is especially necessary to have some direction around what content should/should not be uploaded to SharePoint from a compliance/appropriateness point of view, and to provide some guidelines around writing for the web and keeping a consistent look and feel. This will really help the quality of your published information, in particular. But these are all details that can be ironed out later in the Operating Model: the important thing at this stage is to set the direction.

Some experienced SharePoint practitioners reading this post may already be thinking, “that’s all well and good, but achieving all of those 4 things with every piece of content is a tall ask”. And they would be right. The 4 aspects of “Good” content are less important to enforce with transient working information – the sort of stuff you’d expect to find tucked away in document libraries on a team site or a project site – compared to web content on your publishing intranet. Different approaches to ensuring ‘good’ content should be taken depending on the type and purpose of a site, which leads neatly on to the next section of this post…

Types of Site

Defining clear boundaries between the types of site that your digital workspace will support is an important step to complete as part of the Content section of your SharePoint Operating Model. As alluded to above, different types of site require different approaches to managing information. They will have different requirements around who and how they are managed, their lifecycle (and the lifecycle of their content), and how stringently content guidelines and policies should be enforced for the information they hold. It is necessary to be clear about the boundaries between types of content/site so that you can define effective Governance later in the Operating Model definition process.

I like to split sites into five broad categories. These are:

  1. Publishing sites;
  2. Collaboration sites;
  3. Social sites (or Groups);
  4. Custom sites; and
  5. Personal sites (OneDrive or My Site).

Within these five categories, you will find several sub-types of site, which will often vary sector-to-sector, particularly within the Collaboration category. I’ll give some examples below, along with some other criteria for how you manage these different types of site.

Publishing Sites

Publishing sites fill the need for leadership, management and business areas to push information to employees in a streamlined manner. A small group of employees will use these sites to publish and disseminate officially curated information to the masses of the company. Publishing sites are the hub of official content within a Digital Workspace or Intranet.

Publishing sites
Example types of content News; Department/team “vanity” sites; Official policies and processes; Intranet homepages; Information sites about the organisation
Who can read this content? The whole organisation.
Who can update this content? Small, tightly controlled group of specialists.
What is the Ownership model for these sites? Centralised.
What type of information is stored? Primarily web content, some documents.
How do people primarily find this content? Navigating
Importance of content Usefulness High
Importance of content Trustworthiness High
Importance of content Freshness High
Importance of content being Easy to Find High

Collaboration Sites

Collaboration sites provide a private ‘virtual office space’ for team members. People within the team can create, update and access the files and information they need on a day-to-day basis. They can get updates on important tasks, keep in touch with their team mates, and organise other information like contacts, calendars and useful hyperlinks to facilitate the smooth operation of the team. Collaboration sites can also help projects, bids and other teams formed for a finite period of time to organise their documents and information.

Collaboration sites
Example types of content Team sites; Project sites; Bid sites; Extranet sites; Wikis
Who can read this content? Generally, just the team it services.
Who can update this content? The team the site services.
What is the Ownership model for these sites? Devolved.
What type of information is stored? Mainly documents, some list/tabular data, some web content, some discussion/social content.
How do people primarily find this content? Search; opt-in (actively choosing to follow a site), some navigation.
Importance of content Usefulness Low
Importance of content Trustworthiness Medium
Importance of content Freshness Medium
Importance of content being Easy to Find High

Social Sites

Social sites (communities on SharePoint, Groups on Yammer) are designed for any and all employees to connect with people first, and information second. The social information an employee sees on an Intranet or Digital Workspace is based on their relationships, interests and subscriptions to content/groups. From the employee perspective, the social aspects of an Intranet or Digital Workspace are a real-time stream of opinions, ideas, conversations and free-form dialogue. Social sites allow employees to connect with other people in their team, department, function, profession, area of interest, or area of expertise.

SOcial sites
Example types of content Yammer groups; SharePoint community sites
Who can read this content? Mainly open, some locked down.
Who can update this content? Everyone.
What is the Ownership model for these sites? Devolved.
What type of information is stored? Discussion/social content.
How do people primarily find this content? Opt-in (actively choosing to follow a site).
Importance of content Usefulness Low
Importance of content Trustworthiness Low
Importance of content Freshness High
Importance of content being Easy to Find Low

Custom Sites

SharePoint is a flexible platform that allows you to create all manner of custom applications that fulfil a specific purpose. Examples of Custom Sites include forms, workflow/process automation, knowledge management, management information/reporting, product catalogues, document management, and records management.

Custom sites
Example types of content Custom workflow sites; Forms; Business Applications; Management Information/Reporting sites
Who can read this content? Generally locked down.
Who can update this content? Varies case-by-case.
What is the Ownership model for these sites? Centralised (due to highly customised nature of site).
What type of information is stored? Varies case-by-case, but
How do people primarily find this content? Opt-in (actively choosing to follow a site).
Importance of content Usefulness Low
Importance of content Trustworthiness Low
Importance of content Freshness Low
Importance of content being Easy to Find Low

Personal Sites

A single page portal that contains the user’s personal sites, links, etc. OneDrive (AKA My Site) consists of the user’s profile, and personal documents (split between private and shared). Private documents are intended for viewing only by the individual user whilst Shared Documents are for personal files that the user wants to be viewed by a wider audience.

Personal sites
Example types of content Personal documents; Profile; Personal blog
Who can read this content? Generally, just the individual user.
Who can update this content? The individual.
What is the Ownership model for these sites? Devolved.
What type of information is stored? Personal documents, web content (blogs).
How do people primarily find this content? Navigation (for own personal site), direct linking/sharing (for content on other peoples’).
Importance of content Usefulness Low
Importance of content Trustworthiness Low
Importance of content Freshness Low
Importance of content being Easy to Find Low

Information Architecture

Information Architecture (IA) is how you structure and categorise the content within your SharePoint environment. Traditionally, it is thought to impact two aspects of information management: findability and “put-ability” (awful, awful word). But in my opinion it also impacts two more things which are crucial to an effective SharePoint Operating Model: scalability and manageability.

  1. Findability: related to one of the four aspects of “good content”, findability is how easy it is for users to retrieve and discover content. This might be via search or via navigation. A good IA will provide an intuitive navigation experience, surface the most relevant information to users, and allow them to retrieve information effectively using search filtering and logical queries.
  2. “Put-ability”: God I hate that word. But there isn’t really another way to represent ‘the ease with which a piece of content can be added to the system’. In older versions of SharePoint, there was a real dichotomy between put-ability and findability, in that the more metadata tags you have against a piece of content the easier it is to find, but the more friction there is for users in terms of adding it to the system. And vice versa. But with SharePoint 2013 and SharePoint Online, search technology has evolved to such an extent that findability is less reliant on a good IA. It is now much easier to find a sweet spot between findability and put-ability.
  3. Scalability: another aspect of IA that has become much easier in recent times due to technology improvements is scalability. An important SharePoint ‘bucket’ that impacts scalability is the site collection, which used to be limited in size to just one Gb due to site collections being unable to span multiple content databases on the backend. Now though, the content database size limit (and therefore the site collection size limit) has increased into the terabytes for SharePoint Online. I remember in the MOSS2007 days, having to spend ages projecting content size growth and struggling to come up with intuitive ways to split information into different site collections so that the solution would be scalable. But nowadays, you only need to give this equal treatment with the other aspects of a good IA, rather than it being the thing that drives all thinking, requirements and solutions around site structure.
  4. Manageability: a good IA makes your solution easier to manage, particularly in areas of the platform where ownership responsibility is devolved. A bad IA results in an ungovernable mess of sites and content. Consistent classification of information and clear lines of responsibility derived from a well thought-through permissions model makes a SharePoint solution much more manageable.

You should define your IA as part of the original implementation project, but it also needs careful management post-implementation. I’ll talk about how to manage the different aspects of a SharePoint IA below:

Taxonomy

Your SharePoint taxonomy is the formal classification system for words and labels that describe something related to your organisation. Because these classifications are likely to be used across large swathes of information on SharePoint, it is important to control who, how and when they are updated. Some taxonomy term sets can be left ‘open’, whereby users can contribute new terms while others can be ‘closed’, whereby only a small, centralised group can update them.

Something key to keep in mind when managing your taxonomy on an ongoing basis is that if your taxonomy drastically changes, it could impact how information is targeted at users. A common feature of intranet homepages is news articles targeted at the current user, based on attributes like their location, team, and job role from within their profile. To match specific content to a user, SharePoint needs to find a common attribute between their profile and the content. This attribute is often in the form a term within a taxonomy. If terms sets are torn down and rebuilt, you may discover that you have orphaned content (content with no users to be targeted at), or – perhaps even worse – orphaned users (users with no content that is targeted to them).

Content Types

Content Types are a uniquely identifiable way of grouping settings and metadata columns together. For example, a ‘Policy’ might be one content type, which has columns like Expiry Date, Related Department etc. etc. Another content type might be ‘News Article’, which has columns like Published Date, Author, Related Articles etc. They are a key building block of information architecture in SharePoint, as they provide consistency for how similar pieces of information get classified across libraries, sites, and site collections.

Choosing how you manage Content Types across SharePoint is an important decision to define in your Operating Model, since it can impact the findability of content. You can use the Content Type Hub (CTH), which is where a single site collection pushes changes to Content Types and columns at subscribed site collections, ensuring they are all consistent. Or, you can make it a dev task whereby a script is run to update all Content Types whenever a change is required. In my experience, the CTH works well in collaboration site scenarios, where there is a very consistent set of Content Types across a large number of site collections. For any custom development that uses Content Types, it is not such a good fit and I would advise scripting instead. One other issue to keep in mind is that thanks to the CTH running on a periodic timer job, Content Types and metadata may not be immediately available once a new site collection is created.

Permissions

It’s worth thinking carefully about who and how permissions will be managed on an ongoing basis. Keeping things tightly controlled for published areas is always a solid plan, but you can afford to be a bit more relaxed about transient, collaboration-related spaces that serve a much smaller audience. Effective permissions management is something broadly enforced as part of governance, mainly via training efforts to site owners. But keeping a handle on it is important in order to ensure users will have the right level of access to the right information once your SharePoint platform expands and grows over time. I’ll take a much more detailed look at permissions in the Governance parts of this Operating Model series.

Navigation

The areas of content that rely most heavily on navigation are the published areas. Often, this navigation will consist of a persistent global navigation structure or megamenu, controlled by a special term set. Ensuring only a small group of trained individuals have the ability to update this term set is vital, since changes to the global nav will impact all of your users and all of your published sites/pages.

For local or left-pane navigation, it is usually best left at the behest of the individual site owners. SharePoint provides a few options to generate a left nav based on the structure of the site within Publishing areas, but collaboration spaces tend to be much more open and less automated.

Search

Search is such an important aspect of IA to manage on an ongoing basis that I’ve dedicated a section of the ‘Operations’ pillar of the Operating Model to it – more on that in a future post. But broadly, your search needs to be monitored and optimised to ensure users can retrieve the most relevant content. I prefer to define and manage search schema (the mappings of properties to refiners, and the query rules that determine ranking logic and ‘best bets’) centrally from the search service application. This ensures a consistent search experience across the platform, rather than a (potentially) slightly different experience per site collection that becomes hard to manage.

Site Structure

The final part of IA that needs ongoing maintenance is your site structure. This needs to be thought through carefully from a manageability, consistency, and scalability perspective, and it can also impact how easy to navigate your sites are. For this reason, it’s usually a good idea to control how sites get created. This could be via a centralised team setting them up manually, or via an automated provisioning mechanism.

The other bonus of centralising the creation of sites is that you can nip any daft site ideas in the bud before anybody starts using them or creating content. For example, if your SharePoint platform is still quite nascent and only provides publishing/Intranet functionality on Day 1, you don’t want users to be able to create their own Team Sites until you have properly planned out the IA, web templates, provisioning mechanism, and (if you’re on-premises), scaled your infrastructure to accommodate the massive amounts of content that ends up living in collaboration spaces. Centrally controlling site creation is – in my experience across many SharePoint implementations – one of the most important things you should do to ensure your platform remains manageable post go-live. There are exceptions of course, but generally, applying this rule of thumb will make your SharePoint environment a much more effective platform.

New Roles and Responsibilities

In order to manage Content as part of your Operating Model, it is necessary to have some new roles and responsibilities for individuals or teams. The numbers of people you have fulfilling these roles will depend on the size of your organisation/user base, and the functionality you have deployed with your SharePoint implementation. For example, one of my clients – who have deployed SharePoint to almost 120,000 users – will have a ‘Business Support Team’ consisting of over 12 people fulfilling the Intranet Manager role, plus several more Community Managers. A smaller client I have worked with (<1000 users) has one full-time employee fulfilling both the Intranet Manager and Community Manager roles. It remains to be seen whether these are the right numbers of people as these are both new projects just going live, but this gives some idea of the scale of Content-related support required for larger deployments and the fact that you still need to do it even if you’re a small/medium-sized business.

Intranet Manager

intranet manager
Focus >        Usability and usefulness of content on SharePoint
Department >        Cross-functional between Business and Technology
Summary >        Takes responsibility for the findability of content and the structure of information on the intranet

>        Bridges the gap between Technology and the Business

>        Experienced SharePoint professional, with a particular focus on information architecture
Responsibilities >        Responsible for dealing with content-related service requests and tickets

>        Review search reports and make changes to synonyms and query rules to optimise search usability

>        Encourage optimal use of tagging for content on the intranet, particularly content with a broad reach (such as news articles)

>        Regularly review, ratify and – where appropriate – update the taxonomy to ensure it continues to provide maximum usefulness

>        Act as one of the gatekeepers for new site and site collection requests

>        Ensure permissions follow best practice

>        Ensure navigation is appropriate on all pages

>        Ensure different areas of the intranet are used for the appropriate purpose (e.g. no storing of personal documents in a Publishing site)

>        Reviewing analytics reports and advising/implementing necessary changes to ensure adoption, based on these metrics

>        Communicating best practices and etiquette on the intranet

>        Evangelising the intranet at every opportunity

>        Participating in training preparation and delivery

>        Creating and maintaining help content

>        Participating in Governance Committees

Community Manager

community manager
Focus >        Social community facilitation
Department >        Comms
Summary >        Manage day-to-day social activity on the intranet or Enterprise Social Network (ESN)

>        Well connected within the business

>        Experienced in communication, technology and social media
Time Commitment >        Full-time
Responsibilities >        Actively engaging with members of the intranet/ESN, responding to unanswered posts and generally being a ‘role model’ for how to use the social aspects of the intranet

>        Communicating best practices for etiquette on the intranet/ESN

>        Removing inappropriate content

>        Triaging reported posts

>        Evangelising the intranet and social at every opportunity

>        Participating in training preparation and delivery

>        Encouraging senior executives to regularly post/comment

>        Creating and maintaining help content

>        The Community Manager is NOT a policeman/woman or a monitor. Their focus should be the health and success of the intranet/ESN from a social point of view.

>        Participating in Governance Committees

Bringing It All Together

The Content pillar of your SharePoint Operating Model is incredibly important: Content is what users come to your system for in the first place. You need to put some lines in the sand around what is/isn’t content, and the exact purpose of different types of site. You need to make sure you have a plan for how you manage your Information Architecture on an ongoing basis, and ensure you create some clear roles and responsibilities to provide adequate support around Content creation and management.

There are further deliverables, processes and policies I would advise producing in addition to the suggestions in this post, and I will cover these in the forthcoming Governance part of this series. But for now, these broad decisions and definitions will help you ensure you have a solid first pillar of your SharePoint Operating Model. Even if you only do the stuff described in this post, you will be well on your way to delivering a great Digital Workspace and fostering user adoption and employee engagement through your high quality, well-organised content.

Thanks for reading.

—————————————————————

Part 1 – Introducing the SharePoint Operating Model

Part 2 – Strategy

Part 3 – Content

Strategy

SharePoint Operating Model: Part 2 – Strategy

nathanwells20142 Comments

Introduction

A SharePoint Operating Model brings standardisation and integration to the processes and people running SharePoint. You cannot deliver efficiency and predictability (standardisation) or link the efforts of all the different parties involved in operating the platform (integration) without some clear top-down decision-making. This is where the ‘Strategy’ part of the Operating Model comes in. The diagram below shows where ‘Strategy’ fits into the wider Operating Model I put forward in the previous post.

Strategy in the op model

In its purest sense, a strategy contains three elements: a statement of the problem; a solution to that problem; and a list of cohesive actions to deliver that solution. As much as we’d like to tell ourselves otherwise, delivering SharePoint is only ever likely to be a cohesive action, one of many things that come together to fix a problem as part of a wider business or IT strategy. For this reason, I’m going to horrify purists and use the word ‘Strategy’ to mean “high-level stuff that someone important needs to decide”. It’s vital to get this clarity, or you are just operating the platform for the sake of it. Without these decisions, you won’t have a view as on how it impacts the rest of the organisation and its broader strategy. You need these things defined to provide direction and impetus for action, and to guide the broader Operating Model.

Below, I detail some of the key decisions that you must make in the Strategy part of your SharePoint Operating Model.

Roadmap

A good roadmap should give a clear sign of where the platform is heading. This is for both capabilities delivered, incumbent systems replaced, and major changes required in the organisation to support the new technology. It should also give an indication when you will deliver these things so that you can mobilise resources.

I like to define a roadmap at two levels: Firstly, it’s good to have a map that shows a macro-level view of where SharePoint sits within an organisation’s broader tech landscape. Secondly, I like to define a more SharePoint-centric roadmap which details the exact capabilities that will be delivered for the platform, and the phasing of this delivery.

High-Level Roadmap

The diagram below shows an example high-level roadmap:

Sample Roadmap

This is quite a technology centred view of things, so you might want to include more on the business change side of it too. But whichever way you go about defining your high-level roadmap, it’s definitely a useful deliverable as part of a broader Operating Model.

Low-level Roadmap

For low level roadmaps, I focus on the phasing of SharePoint capabilities. I break the platform down into its core workloads, and also detail components that make up these workloads.

SharePoint capabilities roadmap

You should tailor these workloads and components for your particular organisation. But broadly they will include any/all of the following:

  1. ‘Foundational’ components – stuff that is needed across all other workloads such as your information architecture. This also includes the infrastructure and the SharePoint platform itself (if you’re on-premises, anyway).
  2. Web Content Management – small groups of editors providing carefully curated web content to the masses. AKA, your typical publishing intranet scenario. This may also include extranet content, and even a publically accessible web site.
  3. Search – you could consider this foundational, but it’s usually such an important capability that I call it out on its own. In particular, when you might go down the search integration, federation, custom connectors, or hybrid search route, it can get big and complicated.
  4. Social – maybe Yammer, maybe SP social. This covers the community forums, microblogging, following, and commenting functionality all good SharePoint platforms should provide. The key distinction to make between the ‘Social’ and ‘Collaboration’ capabilities in a SharePoint context is that groups/communities should focus on people and relationships first, information second (and vice versa for Collaboration).
  5. Personal – the ‘me’ stuff, such as my profile, personal document storage (OneDrive), and my sites. Plus Delve if you’re in O365.
  6. Collaboration – Team sites and project sites. Plus, maybe some other components like wikis and bid sites. Collaboration sites act like a virtual office space and allow people to create, update and access the information they need on a day-to-day basis.
  7. Enterprise Content Management – ECM covers things like Records Management, Document Management, and eDiscovery/Legal Hold. A more formal type of information management than the Collaboration workload.
  8. ‘Business Applications’ – the myriad of other stuff you can do with SharePoint to build applications that serve a distinct purpose. This might include BPM (Business Process Management), BI (Business Intelligence), plus all sorts of other weird and wonderful customisations. If your organisation is focusing heavily on one of these extra areas, you might want to call it out as its own workload.

It’s always a good idea to phase your rollout of SharePoint to get return on investment quicker. The most common phasing that I see is shown in the diagram above. A social publishing intranet first (with news, department sites, search, profiles, policies, processes, microblogging, commenting, groups/communities etc.); collaboration functionality next (team sites, project sites, bid sites, some sort of site provisioning mechanism etc.). But maybe your organisation brought in SharePoint as a Document Management System, or as a Records Management solution? Or maybe it was originally purchased with a view to automating business processes? Each implementation is unique, and you will need to phase your rollout accordingly to deliver the business benefits and investment objectives.

If you are in the cloud, you will also need to regularly review your roadmaps in light of the wider Microsoft O365 roadmap. Microsoft are continually releasing new features and enhancements for SharePoint Online and the broader O365 suite. You need to make sure you’re aligned with what they’re doing, or you might end up wasting money building stuff that becomes available for free in the near future. Believe me, I’ve seen it happen more than once.

Funding Model

The next high-level decision you should get agreement on as part of your Operating Model is how you will fund SharePoint beyond the end of the implementation project. A funding model is – at its core – who is going to pay for what parts of the system. Generally, you see organisations break this down one of three ways:

  1. A basic ‘layered’ funding model;
  2. A funding model based around the platform’s capabilities; and
  3. A model based around the organisational structure of the business.

Each of the models has a divide between operating cost and capital expenditure on new functionality and enhancements. The operating costs are spent on ‘Business As Usual’ stuff like licensing, managed services (to provide support and ops capabilities) and – for on-premises environments at least – the underlying server infrastructure. The other operating expense is what one of my clients calls ‘KSOR’ (kay-sore), or ‘Keeping the show on the road’.

This is the expense needed to drive the platform forwards from an adoption perspective, as well as the expense of smaller projects that do not need to be charged back to the business.

You need CapEx to provide extra functionality and enhancements for the system. It’s useful to divide this between smaller, department-specific enhancements and larger, more strategic pieces of work. Smaller projects can be charged back to the requesting business, while bigger programmes that benefit the whole platform and its total user base can be funded from a centralised pot. Who pays for this centralised pot is often a point of contention, and the three funding models I’ve put forward here tackle it in different ways.

1. Layered Funding Model

Layered Funding Model

This is the basic model, where OpEx costs get absorbed by IT. The requesting area of the business funds smaller, tactical projects, while IT’s CapEx budget funds larger pieces of work.

2. Capability-based Funding Model

Capability Funding Model

In this model, some of the costs are split between different parts of the business depending on the SharePoint capability they are servicing. This model relies on clear definition of what parts of the organisation assume responsibility for which SharePoint workloads. I’ve seen one organisation implement this style of Funding Model, but I’m personally not a huge fan. In my opinion, there is too much overlap between SharePoint capabilities to assign the expense to just one area. For example, ‘collaboration’ is something that the whole company uses, so it doesn’t make sense that one part of the business assumes the cost for it. Plus, this model can create political strain between areas of the business when it comes to prioritising new work.

3. Organisation-based Funding Model

Org Funding Model

This model is my personal favourite. KSOR OpEx costs and strategic CapEx costs are divided proportionally between the different divisions within the business. The proportion is based on percentage of the total user base for a particular division. You can also extend this model so that BAU OpEx costs get divided too.

Ownership

In some situations it is necessary to assign overall ownership to some elements of the solution and the Operating Model. This is particularly true when there are multiple third party suppliers involved in the running of SharePoint.

Functional Ownership

Assigning ownership at the functional level can be done either simply or in a more complex manner. Firstly, you can assign ownership at the infrastructure, software/platform, and solution tiers. This is something you should most definitely do if you have a Managed Services agreement with a third party supplier. In this situation, the lines often get blurred between infrastructure, software, and solution incidents/requests. Even in a cloud scenario, it’s still worthwhile, even though Microsoft will be looking after much of the first two tiers.

Functional ownership

Secondly, you can assign ownership by SharePoint workload or capability. As I touched on previously, assigning responsibility in this manner can sometimes get complicated and political. But occasionally, it is necessary. For example, the Comms and Marketing function might take ownership of the Intranet/publishing capabilities, while IT takes control of Collaboration. Maybe some sort of compliance function assumes ownership for Records Management, while a client-facing part of the business takes responsibility for the Extranet. Who knows? But defining this ownership is important to ensure the relevant people have a voice at the table. Every interested party needs a say in strategy, prioritisation, impact assessments, and governance boards/committees.

Operational Ownership

Similar to assigning ownership at the functional level, you might also want to assign it across the Operational Pillars outlined in the first post in this series. Different parts of the business are going to have different levels of input across the Operating Model. It is worth defining this as part of your Op Model strategy to help with buy-in. This becomes particularly important when doling out responsibilities for creating detailed documentation to support the Operating Model.

Operational Ownership

Objectives and Benefits

It’s important that you continue to focus on delivering benefits and objectives beyond the end of the initial implementation. I could write another massive series on how to capture and document objectives and benefits, but I will pay lip service to it here.

(By the way… If you’re delivering a project that does not have any stated benefits or objectives, then pull your finger out and define them! It’s imperative that a project has some link to the business strategy and has captured the reasons the money is being spent in the first place.)

Dependency Networks

The purpose of defining investment objectives and benefits is to answer the following questions:

  • Why is the investment being made?
  • What types of benefits is the organisation expecting to achieve?
  • How can a combination of business changes and technology (SharePoint) deliver these benefits?

The benefits are particularly important in that they also provide a mechanism to track against realisation targets. This allows the company to define success for the implementation. Plus, it gives an early indicator if the expected benefits are not being realised (allowing for corrective action to be taken).

My personal preference is to capture objectives and benefits in Dependency Networks (such as the below):

Sample Benefits Dependency Networks

Benefits Profiles

A key element of the objectives and benefits work is to profile the benefits you are hoping to realise with SharePoint. This involves capturing things like the owner, target benefit, how you are going to measure the benefit, and measurement cadence. This ensures that the benefit will not be forgotten post-implementation.

Benefit Profile

Bringing It All Together

So there you have it, these are the high-level decisions you need to have in place in order for your Operating Model to be effective. To be honest, in an ideal world you would actually define some of these before the project even starts. Without these agreements, you will struggle to define the Operating Model originally, let alone actually enact it. Without strategy, there is no direction or impetus for action for your Operating Model. And without an Operating Model, you will be unable to realise the full potential of SharePoint within your organisation.

Thanks for reading.

—————————————————————

Part 1 – Introducing the SharePoint Operating Model

Part 2 – Strategy

Part 3 – Content

SharePoint Operating Model

SharePoint Operating Model: Part 1 – Introduction

nathanwells20142 Comments

Introduction

Most SharePoint projects focus on building the solution. This covers the information architecture, user experience, interface design, apps/add-ins, and system integrations that come together to form an effective SharePoint implementation. Fewer still define an effective strategy and business change approach for the project. But – in my experience at least – hardly any projects give much heed to how to run SharePoint once it goes live in the organisation. Having a well-defined Operating Model is crucial to ensuring the on-going success of the platform and can help to ease the difficult transition from project into service.

What is an “Operating Model”?

“An Operating Model is the organisational design that makes it possible to deliver the business strategy”. – Ashridge Business School

My interpretation of an Operating Model is that it’s a set of guidelines for how SharePoint aligns with people, processes and other technology to deliver the business strategy. The Operating Model defines the necessary level of process integration and standardisation to allow your SharePoint service to thrive and grow. It provides a general vision of how your organisation will enable the long-term business benefits of the platform. It drives the foundation for executing the SharePoint strategy.

I’ve also heard it described as “governance on steroids” in that it provides some definition to roles, responsibilities, processes and procedures. However, governance typically focuses on information management, application management, and IT ops. This is necessary work that all organisations looking to use SharePoint should be doing, yet SharePoint often requires something more holistic to get the most out of it long-term. This is where the Operating Model comes in.

There are two overriding dimensions that drive an operating model. These are:

  1. Standardisation; and
  2. Integration.

Standardisation is about defining how a process will be executed so that it runs smoothly no matter who is enacting it. This delivers efficiency and predictability around who is doing what, and helps align the platform across different divisions in the company, as well as third party suppliers.

Integration is about linking efforts through shared data, capability and knowledge. It ensures that new capabilities or initiatives delivered in SharePoint can be smoothly integrated with the pre-existing functionality.

A Sample Operating Model

The diagram below shows a sample high-level Operating Model:

Operating Model
A sample Operating Model for SharePoint.

The thinking behind this model is to divide SharePoint into five operational pillars: Content, Adoption, Enhancements, Support, and Operations. An overarching strategy supplements these pillars, and governance policies and processes underpin them.

 Strat3 Strategy defines the direction for the platform. It ensures everyone involved in operating the system is singing from the same hymn sheet and pushing for the same outcomes. It provides direction and impetus for action and helps to guide future investments in the platform.
 Cont2 Content encompasses all information stored on the platform. It covers the configuration possible without formal change control or lifecycle management.
 Adopt2 Adoption covers the on-going training, communications and business change aspects of running SharePoint. It ensures employees engage with and use the platform.
 Enhance2 Enhancements is how to deal with change in the system. This could range from adding small features to much bigger, strategic programmes of work.
 Support2 Support is all about how incidents, problems and service requests get raised against the system. It also covers who deals with them, and how to categorise and prioritise them.
 Ops2 Operations covers on-going maintenance tasks. These activities ensure the smooth running and optimisation of the system over time. You will typically find that on-premises implementations will be much heavier from an ops perspective. This is because you have little control over much of the IT operational tasks in SharePoint Online, as Microsoft looks after these for you.
 Gov2 Governance underpins the core operational pillars. It fleshes out the policies and procedures that must be followed to run SharePoint.

Together, these elements form a holistic Operating Model that can deliver standardisation and integration across the different pillars, and ensure that SharePoint can thrive within an organisation.

This series

I’m going to write a series of blog posts focusing on defining an operating model for SharePoint. I’ll do one post for each of the 5 operational pillars, plus one each for strategy and governance. I’ll also do an extra post on organisation design, and how to put together the right teams, roles and responsibilities to run SharePoint. I hope this blog series will provide some useful reference material for organisations who want to maximise their return on investment with SharePoint.

Thanks for reading.

—————————————————————

Part 1 – Introducing the SharePoint Operating Model

Part 2 – Strategy

Part 3 – Content

Migration

Migration Projects – Things You Should Know

nathanwells2014Leave a comment

Introduction

Recently, I’ve seen a few questions flying about on the various SharePoint community Yammer networks, forums and LinkedIn groups about migration. I thought I’d weigh in with my usual approach to migrating content into SharePoint, which will hopefully help you to facilitate a smooth, successful, on-time, on-budget migration project.

Analysis of source data

Before you can think about what tooling to use, how you’re going to communicate the migration, or any other activities, you need to know what it is that must be moved. Your analysis of the source data should include the following information to help you make sensible, informed decisions later in the migration process:

  • What is the total size of data?
  • How many files must be moved?
  • How frequently read is the info?
  • How frequently updated is the info?
  • When was the last time the info was read?
  • When was the last time the info was updated?
  • What types of files exist?
  • What is the average size of file?
  • Are there any specific permissions applied?
  • How is the data apportioned into different ‘buckets’ within the source system?
  • Who is the owner of this information?
  • Are there any unique IDs that need to be migrated?
  • Do old versions need to be migrated?
  • Are all users of the old system in SharePoint (user mapping)?

This analysis piece will likely take the form of some analytics stats, perhaps presented in a graph to help make sense of it, plus an extract in .xlsx or .csv format that captures the granular detail about individual files.

If your source system is SharePoint…

If your source data is stored in SharePoint, there is some additional analysis you will need to do in order to prepare for a migration:

  • Are there any full-trust code solutions on the system?
  • What is the database count?
  • What is the site collection count?
  • Are there any unghosted files?
  • Are there any custom site definitions?
  • Are there any lists with a large (>100k) number of items?

A good tool to use to gather this information is AvePoint’s Discovery Tool.

Prioritisation of source data

Using your analysis, you need to make some high-level decisions about what is going to be migrated. Key things to keep in mind are that if you are migrating to a comms publishing portal (intranet), then you probably don’t want to take working documents over – you only need published content. Based on usage stats, you can also start to formulate a plan in terms of which are the big ticket items that must be moved, which are the quick wins, which areas can wait a while, and which content is not worth migrating at all. This is also the time to start involving the business in some of the decision making. I find a workshop where the analysis is presented and discussed works well, and it sets the wheels in motion ready for the ‘Housekeeping’ activities (see below).

If you’re migrating from SharePoint, this is also the time you need to start worrying about full-trust code (server side code). If you’re migrating to O365, you will have no option but to rebuild these solutions as provider-hosted apps. Even if you’re migrating to an on-premises SharePoint environment, you should still consider following best practice and rebuilding any full-trust solutions as apps.

Housekeeping

The big thing to avoid with migration projects is moving rubbish from one bucket into a newer, shinier bucket. A migration is your chance to clean up some of your content and ensure your new system is better used and more organised. You need to engage the business and empower the content owners of each logical area to remove, change or add any information they feel they should. Buy in from senior stakeholders within the business is essential for this process, because people are never very motivated to do any housekeeping unless their boss is breathing down their neck making them do it.

Target system information architecture

If you’re moving content to a ‘greenfield’ SharePoint environment (i.e. one that is brand new and isn’t currently being used), you have the luxury of being able to design your information architecture from scratch. In SharePoint terms, information architecture is how your site collections, sites, libraries, lists, and folders are structured; how to classify information (metadata and content types); how to secure information (permissions); how navigation works; and how search works. If you’re starting with a blank slate, you can design your IA with the migrated data in mind, in order to make the migration process as easy as possible. A few things to keep in mind when designing your IA are:

  • Content size boundaries (such as the 200Gb content database size limit for SP2013 on-prem);
  • The list view threshold (5000 items);
  • The lookup threshold (8 columns); and
  • Avoiding item-level permissions.

If you’re migrating into a ‘brownfield’ SharePoint environment (a pre-existing, already-used system with live content and users), things tend to become a lot more difficult. You might have to refactor some of your original IA in order to accommodate your new content while still ensuring the system is scalable and does not exceed any defined size boundaries.

Something to avoid – particularly when migrating from file shares – is simply replicating the source system folder structure. Though folders aren’t necessarily an evil thing in SharePoint (as some consultants might lead you to believe), you are still likely to face issues around usability and maximum URL characters (256) caused by deeply nested folder structures. A flatter, metadata-driven structure is often a better alternative, though it takes more work to plan out.

Mapping and categorisation

You will need some way of knowing where content from the source system should land in the new system, and how it should be profiled with metadata. It’s important to do a mapping exercise to define this. You can define mapping for buckets of content, specifying the location they should be moved to in your new system, and you can do some categorisation on an item by item basis to provide any metadata that will be required for the migration. If you’re building some sort of custom tool or script to move your content, this step is especially important: You need to be prescriptive about precisely where each item needs to be moved when you are scripting the process.

Select the right tool for the job

There are several third party migration tools available from the likes of AvePoint, Metalogix and ShareGate. Personally, I have used Metalogix and AvePoint tools and found them to be more than adequate. I’ve not used ShareGate yet myself, but everyone I’ve spoken to about it has sung its praises. Therefore it probably comes down to your project’s budget and your organisation/implementer’s existing partnerships which tool you select. I suggest you assess all three of these tools. If you’re moving from SharePoint to SharePoint, a third party tool is almost always the way to go, at least in my experience.

An alternative to using a third party product is to build your own tool, or write a custom script. This is often a cheaper alternative to buying a product, and can often be the best option if you’re doing a relatively low complexity migration, for example from a file share into SharePoint. The thing to keep in mind is that your mapping logic will need to be sound, and you will probably need a complete extract of all the source data.

The final option is to get users to migrate content manually. I find this is a good choice if you have lots of rubbish in your source system that needs serious housekeeping: if your business people are migrating content themselves, they are inherently more motivated to do some proper housekeeping by virtue of the fact they will be reducing their own workload when they come to actually move the files. It is also a solid option for web pages if you have defined some nice new layouts in your target system, but still need to take across page content (particularly true of content stored in Content Editor Web Parts on SP2010 and MOSS 2007).

Trial run

Before migrating into your production environment, it’s worth doing a trial run into your pre-PROD or User Acceptance Testing environment (you’ve got a UAT environment, right?). You can test your mapping logic, tooling, and – perhaps most importantly – get a good idea for how long the process will take. This information will allow you to plan downtime, change freezes etc. more accurately, and ensure you can set the expectations of your stakeholders correctly.

Testing

You need a plan for verifying a) that the content has all been moved, and b) it’s in the right place with the right metadata in your target system. Another key thing to test for is broken links, which will almost certainly be a problem if you’re migrating any pages. Users and content authors don’t tend to understand the concept of relative URLs, so it’s likely any links between pages on your old system will be broken post-migration.

The actual migration

You need a solid plan in place for the actual migration into live, and you may need to communicate/enforce a change freeze in the source environment. An alternative to a change freeze is to migrate, get your users on the new system and then go back and ‘mop up’ the delta between your first migration and the go-live on the new system. A good time to do migrations is usually over a weekend, since they often cause disruption (either through change freezes or ‘locks’/performance problems when extracting or importing data).

Change Management

From the outset of the migration project, you will need a solid communication plan in place. You need to tell your stakeholders what will be expected of them and when, plus informing any users of the source system what is going on. You need to explain to users why the migration is happening, when it is happening, and anything they need to do (or not do).

You will also need to train your users with the new system: content authors will need to know how to create/edit/publish pages; users will need to know how to upload documents, categorise information and navigate the system; and site admins will need to know how to add new libraries, folders etc. The type of system you are migrating from should also impact how much training you need to do (for example, migrating from MOSS 2007 to SP2013 won’t be a massive step-change, but going from an ancient file share to an all-singing, all-dancing SharePoint system will be a major shock to the system for your users).

Governance

One final thing: if you don’t want your new system to descend into chaos, you will need a well-defined, enforced governance plan in place. Governance is a big topic, so I won’t open that particular can of worms here, but it’s something you need to ensure you have in place in order to realise many of the benefits of migrating to SharePoint in the first place.

Bringing It All Together

So that concludes my whistle-stop tour of how to approach a migration project with SharePoint. The complexity of migration should not be underestimated, and it is rarely a case of a seamless “lift and shift”. Even for simple migrations, there is a lot of analysis, stakeholder engagement and planning that you need to do in order to ensure success.

Thanks for reading.

Multilingual

Multilingual in SharePoint: Part 2 – How much will it cost?

nathanwells20141 Comment

Introduction

In the previous post in this series, I discussed the options you have available if you are considering implementing multilingual in SharePoint, as well as some of the factors that should influence which of these options to choose. In this second and final post in the series, I will talk about how to assess the true cost of implementing multilingual.

CapEx Costs

The upfront costs to implement multilingual are often considerable. There needs to be careful design planning, as well as changes to how you develop custom functionality and deploy it. After code-complete, the costs of content creation and training will also increase. For multilingual, the following upfront activities need to be taken into consideration on top of the costs you have already projected for SharePoint:

Design

If you are implementing variations in any form, you will need to consider the following additional activities as part of your solution design. You should also refer to the TechNet article about planning variations and utilise the resources provided there.

  • Determine which languages are required;
  • Plan which variations sites you require;
  • Plan which language site will be your source;
  • Plan your information architecture around the site collection limitations of the variations framework (i.e. variations works within a site collection, not across the web application/farm/tenant);
  • Plan timer job schedules (on-premises only);
  • Define who will be the designated contact for each of your variation sites;
  • Plan how search will work in your new multilingual architecture; and
  • Define your content translation process and any custom workflow required.

If you are implementing MUI (Multilingual User Interface), you will need to do the activities detailed below. If you are implementing MUI + Variations, you will need to do the activities below in addition to the activities above:

  • Define and document the translations required for all terms within your taxonomy, for all required languages;
  • Define translations for custom content type names;
  • Define translations for custom column names;
  • Define translations for managed property names;
  • Define translations for custom web part titles;
  • Define translations for lists and library titles;
  • Define translations for custom text within web parts; and
  • Define translations for custom user profile property names.

Build

As part of your development costs, you also need to account for the following tasks:

  • Provision custom site columns to support localised names;
  • Provision custom content types to support localised names;
  • Provision document libraries and lists to support localised titles;
  • Provision custom web parts to support localised titles;
  • Provision custom web parts to support localised content;
  • Create a custom control for search refinement panels (if you intend to use anything other than the default language label for a term in your search filters);
  • Provision your taxonomy with language labels for each term;
  • Provision user profile properties with labels for each language;
  • If using taxonomy-driven navigation, develop global navigation in such a way that it supports awareness of localised term sets;

Term Labels

Test

You need to test a multilingual solution in all languages. You will often find that your test execution estimates will multiply by the number of languages the solution will support, unless you opt for lightweight smoke testing. You also need to consider the following additional testing tasks:

  • Test UI in all languages to ensure the desired layout is still achieved with different word lengths for different languages;
  • Test content synchronisation processes;
  • Test search experience in all languages; and
  • Ensure all spellings are correct for all languages.

Deploy

For variations implementations, you will need to consider the following additional deployment tasks:

  • Configure variations timer jobs (on-prem only);
  • Configure variations settings and labels; and
  • Create variations hierarchies.

If you are implementing MUI-only, you will need to perform the below deployment tasks. If you are doing variations, you will need to do the tasks above and the tasks below:

  • Download and install all required language packs (on-prem only); and
  • Configure the language settings for sites.

Create content

Something that is often overlooked as part of multilingual implementations is the need for content to be created. In a typical intranet, dozens (perhaps hundreds) of sites will need page content and supporting documentation created and uploaded by devolved owners before the system is ready to be rolled out to the organisation. With multilingual, it is likely that the content creation effort will multiply by the number of languages the solution must support. All content must be localised for the correct language, including pages and documentation.

Business Change

Additional communication and training will be required to enable your content owners to use the solution correctly on an ongoing basis. This becomes much more relevant and important for variations, but should also be considered for MUI-only multilingual situations. You need to account for the following additional business change activities above and beyond what you would do in a “normal” SharePoint implementation:

  • Assign responsibility for the translation/localisation of content to appropriate people for each language;
  • Create governance plan (or add a new section to your governance plan) specifically for multilingual, and the rules and policies that govern how it is to be enacted in your organisation;
  • Communicate the publishing and translation process to all stakeholders;
  • Train source site content authors how to publish content to target sites;
  • Train target site content authors how to translate and publish content to their site; and
  • Train administrators how to monitor and report on variations.

OpEx Costs

Additional up-front investment is only half the story: by implementing multilingual, you are also introducing increased costs on an ongoing basis.

IT Support

Multilingual is technically complex, introduces risk and therefore increases your support costs. Your service desk will almost certainly need to field more calls for a multilingual implementation than they will for an equivalent single language solution. Support costs could increase by as much as 50% per month, depending on the exact solution.

Content Translation

So you’ve implemented a lovely multilingual solution that is reliable and works well, but you still need human intervention to localise content. This will be the single biggest cost increased incurred from going multilingual, but it is very hard to project. It largely comes down to whether you will localise content yourself, internally, or whether you will outsource the translation to a third party supplier.

If you need to translate/localise content using internal resources, you will almost certainly need additional headcount. The best way to estimate the increase in work is to get some stats for how many pages get produced per month (or year) and how many languages these will need to be translated to. News articles are the biggest source of ‘churn’ in terms of new pages on a typical publishing intranet, so these are a good starting point.

A company producing 500 news articles per year and implementing just 5 foreign language sites is going to require 2500 localisations of pages per year. That’s a lot of work. It’s also worth noting that you’ll probably need at least one translator per language site, because it’s tough to find people with the ability to speak more than two languages to a fluent, professional level.

If you outsource the translation of content, there will obviously be costs incurred. I would advise seeking quotes from translation companies, which are typically based on number of words to translate.

Future changes

Any future changes to your system will incur increased design, build, test and deployment costs in order to accommodate multilingual – just like the points outlined in the CapEx costs section of this document. This isn’t necessarily something you can allow for in a business case, but should definitely be kept in mind. The increased costs will keep on coming for every new investment you make in your multilingual platform.

Bringing It All Together

There’s a chance after reading this series of articles that you’re feeling a bit bummed out about the prospect of implementing multilingual in SharePoint. It’s expensive, but sometimes the business case will stack up because the need for localised content outstrips the costs incurred. For those companies that have the cash, SharePoint’s MUI and variations framework offers a robust means of delivering a multilingual solution. But you should never underestimate the increased effort, risk, and cost that must be absorbed in order to deliver such a solution.

Thanks for reading, and thanks to my colleagues Paul Ryan (http://paulryan.com.au/) and Chris O’Brien (http://www.sharepointnutsandbolts.com/) for facilitating some of my thinking in this area.

—————————————————————

Part 1: What are my options?

Part 2: How much will it cost?

Multilingual

Multilingual in SharePoint: Part 1 – What are my options?

nathanwells20141 Comment

Introduction

Requirements for multilingual SharePoint implementations are quite common in organisations that span across different countries. Providing information and content in a user’s native language is especially important for intranets (and internet sites), where localised communications and corporate information can be an important part of strategy, and perhaps even a legal requirement. But multilingual is difficult and expensive to implement and maintain in SharePoint: Project costs related to design, development, testing, and training will increase, as will ongoing costs associated with change, governance and support. Weighing up whether or not you should implement multilingual is a big decision that needs careful thought. This two-part series therefore aims to address the main points that need to be factored in when considering multilingual and SharePoint. These are:

  1. What are my options?
  2. How much will it cost me?

This post relates primarily to SharePoint Online within Office365, but the information can also be applied to SharePoint 2013 and other, older versions of SharePoint Server.

What are my options?

Out of the box, SharePoint provides two main options for multilingual:

  1. MUI (Multilingual User Interface); and
  2. Variations framework.

These two features are often used in conjunction with one another to provide a full-fidelity multilingual user experience, or just the MUI to provide a pared-down version of multilingual. In other words, this isn’t so much a case of “MUI versus Variations”, more a decision of whether to use one or both.

It’s also worth noting here that if you are willing to embark on a lot of custom development work, further options are definitely possible. However, this post is mainly concerned with the two bits of out of the box functionality.

MUI – Multilingual User Interface

MUI references the language settings in your profile and automatically translates some of the page “furniture” and out of the box elements. It provides the means of translating “non-content” elements of SharePoint pages.

How the MUI works

Things that are translated automatically by the MUI are:

  • Navigation;
  • Default column titles;
  • Settings menus; and
  • Office Ribbon.

The MUI also allows you to specify alternative language labels for the following elements:

  • Terms/term sets;
  • Custom column titles;
  • Custom content types;
  • List/Library titles;
  • User profile properties; and
  • Custom web part properties.

The MUI does not translate any content. This means that content will display in whatever language the person who created it wrote it in. Content might include web pages, values within free text columns, and information within documents.
If you are using SharePoint Server on-premises, you will need to install the language packs you require for your users as a pre-requisite. If you are using SPOL (SharePoint Online), this step has been done for you.

To enable the MUI on a site, you need to go to Site Settings and then Language Settings. From this screen, you can specify the languages you want to enable for the site.

365 Language Settings 2

Users can specify their preferred language via Office365 settings (for SPOL), or via their user profile settings (for SharePoint 2013 on-prem). Note that the browser’s default language is the default for SP2013 on-prem, but users can change it via their profile.

Language Site Settings

The page “furniture” will now display in the language the user has chosen, provided the site administrator allowed the use of that language in Language Settings.

MUI translations
There are a few “nuances” to be aware of with the MUI. Keep the points below in mind if you are planning on using it:

  • SharePoint search results will only include the default label for terms, not the alternative labels you specify for other languages. This means you will need to create a custom refinement panel control if you want to utilise your labels in search.
  • With SharePoint on-prem, it is good practice to install language packs regardless of whether you need multilingual. This is so that search finds plurals and different tenses of queries written in other languages.
  • It is also good practice to always install SharePoint in English, simply because there is a lot more community information available in English than in any other language.
  • You don’t need to install language packs for SharePoint Online; they’re already installed by default!
  • Remember, the MUI does not translate content, only page “furniture”.
  • Translated labels are often longer than their default language counterparts. This can affect the UI of a site, e.g. causing the top navigation to wrap onto a second line. Always test in every language to make sure issues like this are ironed out.
  • It’s a good idea to define all of your translations as part of your Information Architecture definition. Implementing the labels at the same time you implement all of your content types, metadata columns, term sets etc. is less effort than retrofitting them later on.

Variations

Variations provides a framework to facilitate the publishing and translation of content. Content is created in a source site and then replicated to local language target sites where it can be translated and published. Variations work well when you need to have the same content replicated in different languages.

At this point, it’s worth addressing the elephant in the room: Variations have a bad rep amongst SharePoint professionals, and rightly so. They used to be quite temperamental in SharePoint 2010, and a complete waste of space in SharePoint 2007. But in SharePoint 2013 and SharePoint Online, the functionality is substantially improved: Improvements in reporting, error logging and a more robust publishing timer job mean that Variations are now a reliable means of facilitating a multilingual SharePoint solution.

How Variations work

From an end user’s perspective, the experience of using a Variations-enabled SharePoint solution is pretty seamless. When a user initially accesses the site collection, they are ‘bounced’ from a landing page to an appropriate site for their language (based on the language settings of their internet browser application).

Redirection Hub

They can then consume all pages and content that the site owner of their local site has chosen to translate and publish. The theory is that they will get the same experience in terms of content for any language they access, though this is largely down to whether the local site owners have translated and republished the replicated content.

From a site owner’s perspective, pages and/or lists are replicated in the target sites in a draft state. It is still up to the local site content authors or owners to translate and then publish the content.

Content sync

Pages and lists are replicated via timer jobs that run periodically (every 30-60 minutes with SPOL, and these settings can be configured with SP2013 on-prem). When a Page or list is replicated to the target sites, a designated contact for the local site is notified and can translate and localise the content for their audience. Content authors on target sites have a few different options for actually translating the content:

  • Manual translation: the content author can edit the page/item manually and localise it themselves.
  • Machine translation: the machine translation service is used to automatically translate the content (note that this is the equivalent of using Bing translate, so it is about 60-80% accurate at best).
  • Export translation file: the content author can download a translation package in an industry standard format (XLIFF) that can be sent to a third party translation company. A package in the same format can also be uploaded and published by the content author.

Translation
When you create a site from a Publishing template (or when you switch on the Publishing Infrastructure and Publishing features), some extra options will become available within the site settings menu of the site collection root web. Under the Site Collection Administration heading, you will see options for Variations Settings and Variations Labels. As you can probably guess from the fact it’s a site collection scoped setting, Variations only work within a site collection, not cross site collection.

There are plenty of very good blog posts out there that will explain in detail how to set up variations, so I won’t recover well-trodden ground here. Specifically, the technet article about planning variations is well worth a read, as is this series of blog posts, which provides step-by-step instructions for setting them up.

A few tips for Variations

Things to keep in mind when implementing Variations:

  • Variations work great for out of the box content, but when you add customisations to a page, these web parts and apps will not be variations-aware. You will need to do some dev work to ensure all elements on a page can be translated, either by the MUI or manually by a content owner.
  • Content synchronisation is one-directional: you cannot sync content back from a target site to the source, or from target to target. You can only synchronise content from source site to target site(s).
  • Variations only work within a site collection. If you need to push content across site collection boundaries, you should take a look at the cross-site publishing functionality.
  • Content synchronisation (and hierarchy creation) are run from timer jobs. These run every 30-60 minutes in SPOL, and can be configured in SP2013 on-prem. The synchronisation is not instantaneous.
  • If you want the page “furniture” (e.g. settings menus and the ribbon) to be translated, you will need to use Variations in conjunction with the MUI.

Choosing an option

As mentioned earlier in this post, it’s not actually a choice between using the MUI and Variations, but a choice between the MUI on its own versus MUI + Variations. Two key factors that should influence a decision either way are:

  1. Do you need the same content in different languages?
  2. Do you have processes and people in place already that support the localisation of content?

If you answered ‘yes’ to these questions, Variations plus MUI is probably a decent route to go down. If you answered ‘yes’ to number 1, but ‘no’ to number 2, you should do some serious investigation into how much work you think it will take to localise content once you are live. It could get expensive. The other big factor is the amount of customisation you are implementing for your SharePoint solution: making web parts and apps MUI-aware and translatable will increase design, development and testing costs (and increase the costs of changes and upgrades in the future). This segues nicely into the subject of the second (and final) post in this series, which is all about how much it will cost to implement multilingual in SharePoint.

Thanks for reading!

—————————————————————

Part 1: What are my options?

Part 2: How much will it cost?