Services from 3rd Parties Guide

Time for a service delivery article, looking at working with external SharePoint agencies in a SharePoint environment in BAU… If you are operating and managing SharePoint environments for your clients, you may find that there is a business requirement for enhancements or modifications to something to take place which would alter your controlled SharePoint environment. This business requirement may be one where there is a call for the intended work to be carried out by utilising services from an external ‘SharePoint’ on a sub-contracted basis.

Now, before continuing, and for arguments sake, this article does not consider how the ‘agency’ was chosen, and does not consider what they are going to deliver.

So, let us look at some of the reasons why an external SharePoint agency is chosen instead of meeting requirements using internal resources:

  • A SharePoint solution is being delivered which requires more than the available resources.
  • A complex migration from one version of SharePoint to another.
  • Development of the platform (programming modifications and enhancements into the SharePoint platform).
  • Additional 3rd party services (e.g. analytical, monitoring, etc.)

Taking on the services of an external SharePoint agency to carry out work means coordination, communication and harmony. Do not go down the route of simply opening the entire SharePoint environment, and saying ‘Hey, come on down, do your stuff’. If you do that we are talking ‘category 5 blunder’, as there’s no control of your environment, no idea on the outcome of their work delivered to the environment and worst of all no configuration management of SharePoint. On the other side, I definitely do not mean adopting a ‘Get your Hands off my SharePoint’, shutting windows in a Wild West mentality and cringing behind the blinds. That’s just plain obstructive and likely to let off warning bells from the business.

A structured approach is required:

  • You have all the information that details what is going to be delivered.
  • That the risks and issues are covered.
  • That there is a clear scope of work.
  • That there is a defined review – start and end.
  • Whatever is delivered is documented (to the hilt).
  • Whatever is delivered is handed over and to the clients satisfaction.

Is managing a SharePoint implementation programme the same as managing an agency to deliver a specific element of work to SharePoint? In a way, Yes. The process of managing a group geared to implementing a specific product is no different – control and configuration management is key.

Here’s a quote from a top flight manager in a blue chip company adopting SharePoint and doing it via a ‘SharePoint’ agency using the ‘hey come on down’ approach:

“It was mad. I had consultants all over the place… I was confused… No one knew who did what… Hardly anyone knew who was in charge… No one seemed to have a clear answer as to what they were doing, why and most importantly for how long”.

The above simply relates to the fact that communication is the missing element. The manager above didn’t know who the agency account manager was and no controls were put in place to review the work. Make sure you acutely know the agency account manager and that you are fully aware of what is going on and who is doing what, and why.

Communication and the Work Package

So, the first thing that needs to happen is that there must be set clear rules of communication between that account manager, yourself and the client. To establish that, there are three things the account manager needs to draw up. A scope that describes unambiguously exactly what will be delivered, a list of people who are involved and an agreed duration covering the engagement.

The documentation provided by the account manager covering the above is known as a ‘Work Package’. This Work Package is put before the client, who then needs you to validate the Work Package as the SharePoint person managing the deployment(s) and through you agrees who else needs to see and validate the work package before it proceeds.


Even when creating a Work Package, agencies in my experience sometimes forget to agree who will be providing the resources and/or when the resources will be needed. It is not specified in the Work Package, maybe because there is an assumption that the client will provide it, or that the agency will provide it. The issues arise when the agency requires access to client key resources – SharePoint access for example (which will require some kind of access to be defined). Not doing this upfront causes anxiety for the agency and creates a bottleneck for the client – especially if there are interfacing teams to contend with (production of access accounts follows a procedure etc.). Clearly, agreement on resource provision needs to be set in the Work Package at the beginning.


Control of subcontractors is very important when allowing access to SharePoint environments. In most cases, access is not provided to company electronic resources unless the individual is part of the organisation, and there have been checks to ascertain the levels of security applied. You do not want to be part of the following issue!

“We had an agency, a SharePoint consultancy they were, to come and carry out a maintenance review on our SharePoint environments. We thought that by giving then direct and unfettered access to our network and SharePoint, they would be able to carry out an efficient and quick review. We also felt confident that they had the relevant skills required. So, we left them to their own devices. However, during their ‘review’ of SharePoint we lost access to the entire environment for over as day, all caused by a mistake made by one of the agencies consultants. That mistake cost us over 50k in lost revenue that day”.

Now reader, if you work in a ‘Desktop’ team, you would probably know that providing network infrastructure services access to clients goes through due process. However, that is simply not enough. We all know that providing access to resources is much more than a ‘fire and forget’ – meaning, that you simply provide access to the resources and then ‘walk away’.

Control of access means managing that access and that would mean recording what needs to be accessed, when, why and by whom. There needs to be a continual record of changes to SharePoint use and allowance to sites. Record the agency requirement to access SharePoint, reasons and duration of the access request. The process of managing changes to SharePoint is known as SharePoint Configuration Management.


Continually, repeat, Continually review the work carried out by the agency. This means reviewing that work package. When do you do this? Constantly (yes, continually). Why? Well, for a start, it is all good for the agency to ‘run silent’ because there has been agreement on what they will deliver. But if you do not monitor their progress the work package will distort. The potential for a torpedo to be fired from the client simply because the agency has found a loophole in the work package that slows their progress is high if the work package is not reviewed regularly. Here’s another wonderful example of when not enough review means chaos – the following is an excerpt from a manager (maybe the same one from the previous example):

“The consultants said they would review our SharePoint environment, and the review scope seemed clear enough. The consultants went away, carried out a review and gave a report, which did not relate to our environment at all!”

What about Office365 and SharePoint Online?

Service delivery in SharePoint Office365 online only differs because a key segment of control is not available – infrastructure. This does not exist; things like monitoring and logging changes from the perspective of server to web analytics usage. However, administration is still there, and so is development. Even if the Delivery is different, the key aspect to service is trust and external agency capability, which is no different. This is particularly in relationship to supporting Office 365 tenancy and SharePoint online sites for customers.