SharePoint Operating Model: Part 2 – Strategy


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.


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.


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


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

Is SharePoint Dead? My thoughts on Microsoft’s Latest Announcements about SP2016.

I recently read an article by Dan Holme on IT Unity, in response to Microsoft’s blog post outlining the strategy for SharePoint and O365. Sometimes when I read or hear a particularly good line, I get that amazing feeling of something ‘slotting into place’; that feeling you get when something that’s been in your subconscious for a long time (but you have never quite been able to articulate or form some coherent thinking about) suddenly reaches clarity. This is the line:

“After a decade, I still struggle to answer the question, “What is SharePoint?” because I have to start by asking questions like, “It depends… what are you trying to do as a business?” SharePoint has always been too big of a story to tell. Ask me what OneDrive for Business is, or what PowerBI is, or what Yammer is… I can tell you. The granularity helps a lot.”

Nobody can succinctly explain what SharePoint is, what it does, and the benefits it brings to a business because it is just too big. When a friend or family member asks me, “So, what is SharePoint?”, I usually roll out some analogy about a box of LEGO bricks, or start using buzzwords from the SharePoint Pie of Despair. The person usually ends the conversation more confused than they were at the start. I don’t think this is a particular reflection on my ability to articulate concepts either (well, I hope not), because I have never heard anybody give a good explanation or definition of SharePoint. It’s just too intangible as a concept; too hard to envision for people who have never seen or used the platform.

Microsoft’s approach to break down the services and capabilities provided and supported by SharePoint into smaller, bite-sized “experiences” makes perfect sense, and makes my life a lot easier to boot. It’s much simpler to explain and articulate the business value of an individual use case than it is to do the same with SharePoint as a whole. As a consultant, it means I can focus on guiding customers towards the experiences and portals that provide the most benefit to their users without having to explain, “We’re giving you SharePoint, but we’re only doing 20% of what it’s theoretically capable of at this stage of the programme”. It means that we can look at Office365 in a more holistic way, rather than SharePoint requiring a completely different project approach to the rest of the products in the suite. Strategic roadmaps are easier to define, explain, and obtain executive buy in for. It means organisations can better identify their requirements and aspirations when going out to tender. It helps to stop the blurring of the lines between different concepts in SharePoint (such as publishing portals versus team sites/collaboration spaces), increasing our ability to govern the solution and aiding user adoption. And it may, at some point in the future, allow Microsoft to give their customers more granular licensing for individual areas of functionality or features that currently come under the SharePoint umbrella.

So is SharePoint dead? Well, no, but as a concept and a brand, it is probably terminally ill. The functionality it provides will carry on and continue to evolve, and the skills/people needed to implement and support it will be in just as high demand as ever. I’m really excited to see what the next 12-24 months holds for SharePoint, and I am fully behind Microsoft’s “experiences” vision.