SharePoint Service Delivery concerns itself with capability, and the methods used to ensure that the clients SharePoint vision and goals align with the users, and includes focusing how those responsible for managing the platform (the technical teams) fit and provide that service through guiding principles. These, if followed will ensure that your SharePoint environment can be managed in a structured and measured way.
For those starting to read this article and thinking ‘this will not apply to me because I develop things’ or ‘this will not apply to me because I look after servers’ – think again. If you do not attempt to grasp or understand what SharePoint is there to achieve in your organisation, then the products that you develop and the platform you look after will be out of sync with business aspiration. Remember that Business aspirations and goals are unlike like IT goals aspirations when it comes to SharePoint implementation.
So, before understanding the guiding principles to successful SharePoint service delivery, let us summarise a statement (I use this – it’s mine) which you can use when someone asks ‘What is SharePoint’?
Microsoft SharePoint is a strategic technology that allows people to seamlessly work with each other through a centralized content management platform. SharePoint is a business platform; and SharePoint provides users with the ability to create and manage their SharePoint sites and enclosed content.
Therefore, it is also safe to say that successfully centralizing content management and optimising the way data is published and shared will align with the company goal to achieve operation efficiencies. Henceforth, by advertising individuals’ skills sets, interests and promoting work-based social networking in using SharePoint aligns with the company goal to make the most of the companies key asset, its people.
This means work concerning the design of how SharePoint will evolve in an organization. This is not altogether technical. For the last ten years of SharePoint, the document was the centre. For the next ten, it will be the user. And it is vitally important that once the fundamentals are in place that the principles of the design are reviewed, again and again. This is what I call SharePoint Service Delivery. Some of my suggestions concerning the design for SharePoint Service Delivery are given below.
Suggesting Guiding Principles.
Drive through a SharePoint roadmap
A ‘completed’ SharePoint implementation becomes part of an integrated framework of organizational systems and tools (and a crucial one), placed provided to enhance the productivity and ROI. A successful SharePoint implementation is based on the success and delivery of each part of a ‘roadmap‘. This roadmap is based on aspects of user productivity in using content management systems, each seen as a project in its own right. For example, the process of publishing content is one part of the roadmap. Search is another, User Profiles another. Development of the roadmap requires input from the user-base and approval of the client at high level. The roadmap sets in stone the planning and execution of SharePoint projects in priority – it builds the SharePoint house. Note that, in instances where the SharePoint implementation as failed, a roadmap is vitally important in putting things right.
Advertise SharePoint benefits/success stories to users, follow a ‘viral advertising’ approach, but do not attempt to impose SharePoint
Think that the implementation of SharePoint completes when it is installed? Wrong. SharePoint user adoption is based on how SharePoint is provided, and intended users need to be convinced of its benefit. There is simply no point in saying ‘SharePoint is great because it has these tools’ – that techno-centric attitude to delivery is not valid. In any SharePoint implementation there is resistance. Overcome Resistance through awareness, natural influence and marketing. Understand the resistance, empathise with that resistance, change user behaviour, train them, train them and train them. SharePoint implementation requires user facilitiation. You need to overcome resistance and that means building trust. Users need to be willing to do this and a great method is through having ‘brown bag’ sessions through which you describe benefits of SharePoint (through an understanding of core user requirements). As SharePoint grows various solutions which have been successful should be showcased and advertised through as many channels as are available. Also, dont forget that collective user behaviour is influenced by an evangelistic approach which then changes beliefs of SharePoint. Examples include convincing users of the availability, resilency and performance of the platform (not by simply stating technical specifications of SharePoint!). Remember also that SharePoint is NOT a silver bullet – therefore, enforcing SharePoint onto users solves nothing but resentment. The key is integration. Read on.
Do not attempt to impose SharePoint or SharePoint tools over ‘best of breed’ e.g. consider how to integrate tools with SharePoint rather than ignoring these tools
Following on from the last two sentences of the previous section. SharePoint is not a silver bullet. You must not ever assume or even suggest that SharePoint will solve and meet every user requirement. This is especially so due to the myriad of business processes multiplied by the products currently used to service them. There will be many instances where a process tied into the use of a particular tool services the need and already has a specific roadmap and relevant systems. To attempt therefore to replace those with SharePoint will confuse, cause un-necessary re-training, and in most cases cost more to implement. Additionally, consider third party tools where SharePoint fully integrates with that will immediately add value, without attempting to re-design the wheel through hacking SharePoint or ‘coding’ around the problem.
Promote creation of ‘SharePoint champions’ within business teams to drive SharePoint into the business
User Adoption is fostered through building a collective culture where there is knowledge that the product is being used and communicated through success stories. These success stories are not just related to showcasing SharePoint solutions, they related to showcasing the people (in the business) who helped create those solutions. These people generally are keen and have been able to glean more knowledge of SharePoint; and its therefore crucial to exposed them to others. So, identify those in the organisation who are keen to learn SharePoint and/or are evangelising to their colleagues about doing more things in SharePoint. Create a central announcement where comments from those people can be communicated to others. As a scenario, working with a large user base of SharePoint, decisions were made to capture basic ‘How Tos’ that came from various business members. These where then summarised into blogs and pushed to a central page but pointing out their source – this worked very well. Also, from those individuuals ask opinions on how SharePoint use of products can be improved; communicate those solutions as necessary. From these individuals, three benefits. First, more users are introduced to SharePoint; second, use of SharePoint governance tips come to the fore and third, a level of support is obtained in the relevant business teams where SharePoint champions are identified. Note that this is a continual process since business teams continually evolve.
Promote ‘self-governance’ and accountability for content through site owners and department users rather than imposition of rules/policing by departments.
In any SharePoint environment, you will have a centralised IT support team. However, it will be rare that in thatui team you have a SharePoint support guy whose sole job is to reactively wait for calls to come in. Additionally, IT Support is not responsible for content stored by the business – they did not create it, have little to no knowledge of the process surrounding that content or the security that needs to be implied and maintained. IT Support looks after the programme of products of which SharePoint is a part. And, when it comes to the process surrounding the creation through to the retention of content no-one is closer to that than the business members. The management of SharePoint content is therefore a business imperative. To meet that, train your users on how to manage that content and the sites where that content lives. There will be times of course when IT Support steps in to aid, however, if the business understands and is accountable for the content managed then they will be more in tune to using the product.
Drive towards rationalising SharePoint site areas, by defining Information Architecture and promote a clear SharePoint framework.
The layout of SharePoint in terms of content ‘silos’ should be explicitly defined. Examples of this include silo-formation of areas to provide a specific SharePoint deliverable, for example Search. Others include places where business teams will work in a dynamic environment, and those where say records are kept. This is a huge area to consider, that said, start with the basics and design a clean taxonomy of site structure – this is a core aspect of the roadmap allowing you to prioritise the solutioning of these. Once the basic high level structure of sites has been defined and agreed you should post this to a central site (called a One Stop Shop) and make it available to all – this helps users identify where content is located and describes why the structure has been applied. This is also a continual task as the business evolves, so does the taxonomy – however, the high level should not be subject to change.
Work with SharePoint ‘out of the box’ features and avoid customisation unless strictly necessary
There are many reasons why when building SharePoint delivery that implementers stick with seeking to use out of the box features. First, there’s the training element. Second, there is the support element, and third, there is the user adoption element. All go hand in hand. Training because to on-board new users (and existing) takes time and resources; this is extended if SharePoint is modified using third party components. Support, because adding third party tools means they have to be built into being managed, as well as the normal support element (instead of keeping the eye on a priority ball there are now many to juggle). User Adoption, since users now have to contend not only with the use of SharePoint unmodified, but with SharePoint modified. Let me explain this with a simple scenario.
Company XYZ has SharePoint environment with two SharePoint web applications, Web Application A and Web Application B. Web Application B is customised – its look, feel and certain fundamental operations have been customised. Users have access to both of these Web applications.
The result? Confusion reigns as users find that the fundamental operations in Web Application A are unlike Web Application B.
Guiding Principles are important.
As pointed out earlier, SharePoint in an organisation is simply a part of their computing provision. And like any part of the software puzzle in an organisation, the role of service delivery and support goes much further than simply solving technical problems as they crop up. This thinking sits critically with SharePoint as it has a much more intrinsic connection with the business users. The aim is nothing less than ensuring service delivery acts as a catalyst by which the Business and IT meets their fundamental purpose; that of making workers more productive with SharePoint.
Throwing a stick into a pond and waiting for your pet dog to jump in and retrieve it will not help unless there is an incentive and they have been trained!
You cannot hope to do build SharePoint Service Delivery without getting help from your users – so be ultra-enthusiastic and passionate about your aims and you will succeed in getting their aid.
So the principles laid out above will help you creating a solid SharePoint delivery structure, with flexible requirements meeting business using out of the box features from the outset, continued training and alignment with the business goals concerning SharePoint’s evolving roadmap.
