Back from a wonderful holiday and straight into the land of
SharePoint. Starting working on Book number 4 (there’s another blog
to describe that one), but there’s loads of awesome topics that I’d
like to share with you. I’d like to start by providing you an
article, based on a very important topic, SharePoint
Service Delivery.

Service Delivery in SharePoint is simply 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 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 focused 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. 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.

Drive towards rationalising SharePoint site areas,
by defining Information Architecture and promote a clear SharePoint
framework (e.g. Collaborate, Intranet, Search are defined
areas).
In another blog, I’m going to suggest the methods to create the
ground-work that will support the SharePoint infrastructure. That
infrastructure includes where hierarchically and functionally where
content is managed by the business. 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.