As anyone working with SharePoint and trying to get people to use solutions provided will know – you simply cannot guarantee any success concerning the usage of any SharePoint solution, if the relevant support provided is not ‘good’ enough in the eyes of those using the solution.

All services, combined to meet a particular business requirement is a solution, made up of products. In particular for of SharePoint support, the SharePoint platform is in the ‘centre’ of these solutions.

It does not matter whether the solution is based on one or more internal products, or provided through a third party as an app. It does not matter how much you strategize, how much you evangelize, how much you ‘butter up users’ to use the solution. Users will not use the solution unless the support for that solution is ‘good’.

Now, there is a lot of things needed to ensure a support service is ‘good’. Without going into that in any detail, let us look at one of the components of the support service, knowledge of individuals providing the support.

So, support of any SharePoint solution is crucial and must be measured to be effective. To measuring support effectiveness, means rating the knowledge that SharePoint support individuals have; which is associated to products that make up the solution, and even beyond into the products also being supported.

Scenario 1. User A is using SharePoint which has a component which delivers information coming from an external database. The component is a third party product integrated with SharePoint. The third party product also delivers information that the user can work with in Microsoft Outlook, and can be viewed using Microsoft Office tools, or downloaded as a PDF to the individuals cloud based storage service.

Therefore, the knowledge that the typical SharePoint support individual will have at the very least is a combination of SharePoint knowledge, the third party product, Microsoft Office, the cloud based storage service, plus soft skills in dealing with the users.

Scenario 2. Technician A is working on a SharePoint server issue which includes the use of Visio services and the State Service to set an ID. The Visio service delivers diagrams which show dashboards against team performance across the business.

The above shows a situation where the technician is not directly connected to a relevant user and yet the service appears to be critical to the organization. The knowledge that technician needs to have is a combination of ‘lateral thinking’ combined with specific SharePoint product knowledge.

In many organizations, the technician in Scenario 1 and Scenario 2 are one and the same, but yet, the two scenarios are completely different. Clearly, SharePoint is not the only product being supported. This presents questions such as:

• How do you gauge whether the knowledge of that typical SharePoint support individual has is sufficient?

• How do you know whether the products being supported are really vital to be supported?

• How can your SharePoint sponsor be made aware of the number of products being supported and any relevant issues concerning technician knowledge?

In order to answer this, you will need to carry out three tasks:

1. List the products supported and the level of importance of each of those products to the business

2. Identify Product relevancy

3. Rate technician knowledge against the relevant products.

SharePoint is not the only product being supported

Have you ever listed many how products your SharePoint team supports? Including SharePoint (Front and Back-end services), the operating system, integrated services within applications such as Microsoft Office suite, associated Microsoft Office tools, systems hardware, SharePoint third party applications, add-on bits of hard and soft for other enterprise platforms in the business, Office 365, cloud file-sharing services, cloud chat services, etc. The figure may well come out to around 30 products. For each of these supported items, any one of your SharePoint support team will be able to claim a level of knowledge anywhere between ignorance and ‘absolute guru’ status, and a few points in between.

So, with the number of products being supported being 30, let us assume that there are five possible levels of knowledge (with ignorance being 0 and absolute guru being 5). If that’s the case, then there are 900 permutations of product by knowledge (30 x 5 x 6).

Based on that, how would you be able to identify where the correct level of support applies? How would you be able to know which products are more or less important than each other to support from the business audience?

Identify Product Importance

As one would deal with any management problem such as this, the first action should be to take some measurements. Who knows how much about what, is it enough and are those the right things to know about? Start by making a list of all the products supported or suspect the users think you support. An example of such a list is given in Figure 1.0 below.

Note that at this stage it does not really matter where you actually support all the products or not – as we are going to ask the users to help us compose this list, their opinions count. When we then ask the SharePoint support team, we may find that we can support the product anyway.

Having composed the list, we need to find out which of the relevant products are worth supporting. Ask several users and several support members how important they think the product is to the business of the company. As we are trying to produce a numerical measure, the answers must be in a restricted range of options. The question I ask, for each SharePoint product on my list is “to the business of this company, is this product essential, significant, routine, or irrelevant?’. A response of ‘essential’ gets a score of 3, ‘significant’ is a 2, ‘routine’ is a 1 and ‘irrelevant’ gets a 0. In gathering the responses, I compile a list and I calculate averages. This becomes my product relevant matrix.

Figure 1.0. Product importance from the business’s perspective

So, using the list of products, ask the support staff on how knowledgeable they think they are on each of the products. Do not miss anyone out, as it is important that all who support users is asked about their ability on every product. This will give a measure of the support teams knowledge individually as well as collectively; allowing you to identify gaps in their knowledge.

Rate SharePoint Knowledge

Before kicking off this section, please note that this relates to anyone working within the remit of SharePoint support. That covers a number of roles, and definitely those whose job is actually a ‘SharePoint support helpdesk analyst’. Again, you don’t have to follow this guide, you could use actual roles when I list technicians further down in this section, like say, SharePoint Administrator, SharePoint Engineer, SharePoint Consultant (though to keep things nice an anonymous and to protect the individuals integrity I’ve decided not to and used technician instead).

Using the product list, you should rate those charged with supporting SharePoint products on a level of 4 to 0, where 4 is the highest level of knowledge, and 0 is absolute ignorance. The knowledge levels are described in Figure 1.1. Use this as a guide, you can setup your own levels if you wish. As an example, I’ve used just four to put perspective on genius (level 4), or gormlessness (level 0). I’ve created an example of the product knowledge matrix in Figure 1.2.

Figure 1.1. Knowledge Levels against products
Based on the above, from surveying the SharePoint support team (remembering the point I made about using the term ‘technician’ at the start of this section), you will be able to provide a list of product knowledge scores against each technician in the product matrix shown in Figure 1.2.

Figure 1.2. Example of product matrix

When you compare the results of the two matrices of Figure 1.1 and Figure 1.2, you will see that SharePoint support has a number of serious problems. First, the overall average of the team at 1.95 is lower than 2, so collectively they can only just support the SharePoint products. The problem appears to lie with a tendency to rely on specialists; technicians 1 and 3 are clearly the experts and therefore you should consider whether the other technicians are being wasted / require training. It is a wonder that technician 1 replies should be taken with a pinch of salt in that the technician may overrate himself slightly?!

The next issue is that in Product 5 there is an item which people consider to be essential to the business (recall the example given in Figure 1.0), yet SharePoint support appears to be almost completely unable to support Product 5. Therefore, more investigation concerning the level of support provided for Product 5 is required to ascertain whether that support is provided via an external provider. If not, there needs to be a provision of support for Product 5 internally.

In Figure 1.2, you will also see that technicians 1 and 3 each have fairly balanced knowledge. There perhaps is little scope for doing anything to improve that knowledge, that said, other areas of product support should be addressed by them to level out their knowledge more.

In Conclusion

In the sea of SharePoint support, it is very important that there is clarity on what is being supported, the capability of the team and the importance that the business applies to each product being supported. The comparison of product relevance and product knowledge is an exercise that should be conducted on a regular basis. Good times to carry out such an exercise is when a new product is provisioned, or when a new solution is provisioned, of even when the ‘SharePoint Champion people pool’ has been updated.

Doing this assesses the ability of the SharePoint support team to provide effective support to the relevant Products which then will have a direct impact on the adoption of the Product by the business.

Benefits of carrying out an exercise to ascertain SharePoint knowledge is that:

1.A true picture of the actual knowledge of SharePoint workers is identified

2.Training can be identified directly related to the areas that SharePoint support are lacking on

3.This gives your SharePoint sponsor a steer on whether productivity of the users can be maintained given the number of products to support.

One last point. Doing this exercise can expose those who think they are omniscient wonders on all SharePoint products being supported (recall Technician 1 response of 4 to Product 1 in Figure 1.2). As a balance exercise, you can take the results from Figure 1.2 and check them against the ‘spot rate’ in your call logging system. From that you will be able to identify how many queries are being escalated from Technician 1 against Product 1. If that spot rate is less than 100 percent then that Technician is clearly not a superhuman in SharePoint product support!

If you have any questions or feedback on Geoff’s article please leave a comment below. We would love to hear from you.

See Geoff Evelyn speak on Ten Steps to Creating a SharePoint Support Model  at ESPC14.

Geoff Evelyn

Geoff Evelyn is a SharePoint MVP, focused on SharePoint Service Delivery which covers high level SharePoint Implementation, Support Management and Automation. Geoff is a Fellow of the Institute of the Analysts and Programmers, a Fellow of the Institute of Computer Technology, a Member of the Institute of Management Information Systems and Engineering Technology, a Prince 2 Practitioner, and a SALEM (Sequenced and Logical Enterprise Methodology) Practitioner. With nearly 30 years of experience in information systems, Geoff has published many articles, guides and books, with five about SharePoint covering solution implementation to information worker study guides. Geoff also has MCDST, MCSD, MCTS, MCITP Microsoft certifications and is M.O.S (Microsoft Office Specialist) Certified.