Why there is a shortage of SharePoint experts

Microsoft has been very successful to promoting their SharePoint product, even though SharePoint has been around for a while, there 2007 and now 2010 version is something every organisation wants.

With Microsoft practically giving away SharePoint licenses to organisations via EA agreements – we are reaching a very unique and rather unexpected situation where the demand for SharePoint developers is surpassing the demand for Web developers.

This shift in demand are forcing IT departments and Web Development companies to reduce the size of the web development teams and increase the size of their SharePoint team, in other words, take staff originally hired for web development and get them into SharePoint development.

This is currently the "normal" approach in getting SharePoint experts, many IT Recruitment companies still don’t understand this shift in demand, and are not yet focusing in the SharePoint space, some recruiting companies haven’t even heard of SharePoint and see it as a specialist skill.

Restructuring organisations to handle the shift in demand is a change that will naturally lead to resistance and conflict. To the managers and other decision makers, this change seem minor, especially when “converting” ASP.NET developers, since SharePoint is built on ASP.NET, and it is assumed that the same skill set and approach is needed with minimum training on the SharePoint basics. That is not the case.

An ASP.NET web developer became a web developer by studying and gaining experience in the following...

• HTML
• CSS
• DHTML
• JavaScript
• JQuery
• ASP.NET (C#, VB, etc)
• SQL
• AJAX

They also use a range of products created especially for ASP.NET web development, mainly...

• Visual Studio
• SQL Server Management Studio
• Some code repository like SVN or Team Foundation Server

That’s the tools they have in their tool belts, over time, they become experts by continuously applying this skill set and learning the best approach in using them when completing tasks.

For SharePoint, the approach is different, very different. All the HTML, CSS, JavaScript and so on is provided by the SharePoint product, SharePoint experts are not suppose to touch that space, deploying SharePoint solutions is more focused on planning, installing and configuring, with less emphases on developing.

If development is required, it’s because SharePoint cannot satisfy the organisations unique requirements “out of the box”, and something “custom” needs to be built. Custom development in SharePoint is regarded as the last resort, while an ASP.NET developer sees this as the first option, placing them in a situation they are not comfortable with right from the start.

Since a SharePoint solution is different from standard ASP.NET web applications, tools like Visual Studio and standard code repository tools have their limitations and the Web Developers are forced to use another tool, mainly SharePoint Designer, which is another learning curve hurdle that can limit adoption.

If the bulk of the SharePoint project is focused on planning and configuration, then the skills that the developers were perfecting as an ASP.NET developer no longer drives the success of the entire solution, but rather the success of a small component (if any custom development was required).

The SharePoint developers are also faced with a challenge that they never experienced as an ASP.NET developer, there are restrictions when developing and providing a look.

An ASP.Net Developer is used to having full control over every component of the web application, from its functionality to its look. SharePoint is a product with a large amount of functionality built in, and developers need to configure the required functionality and make it available to the end user.

They need to move away from creating a SQL database, the foundation of their solution, and move towards using the existing SharePoint database via SharePoint lists.

Look and feel is template based; adjusting the default look usually creates an environment that SharePoint is not expecting that can lead to drop in functionality (Read my Post for more details).

SharePoint may add these restrictions and limit what the developers can do but the end users are unaware of these restrictions and expect all their unique requirements to be for filled. It’s not the end users fault, there requests don’t seem unreasonable, it’s just that SharePoint was not built to work that way, the following are example of “simple” requests that cannot be done via SharePoint without something custom being done:

• “I would like my site to have 3 navigation menus” – SharePoint manages a Global Menu (Site Collection Specific) and a Current Menu (Sub Site Specific) only, that’s 2 menus.

• “I would like my menu to hover down to 3 levels” – SharePoint Global Menu hovers to 2 levels only, SharePoint Menu Configuration screens do not allow the levels to be modified.

• “I want to use an AJAX/Silverlight menu” – It is not recommended in SharePoint 2007, this is explained in detail in my previous post.

• “I want the same menu across my entire site, all managed in one place“– Global Menu is Site Collection dependant while the current menu is sub site dependant, a different site collection or subsite means a different menu, managed in a different place.

I limited my examples to SharePoint navigation menus only, just to show you how one component can give a developer a big challenge from “simple” requests that would have been a lot easier to complete if the SharePoint was not used.

So what does this tell you? Demand shifts are forcing managers to turn web developers to SharePoint developers. This is not what web developers signed up for, the approach for these projects is very different, and in many ways restrictive and frustrating, so they don’t do it, leading to the shortage in SharePoint skills.

How do we solve this problem? Stop looking at converting Web Developers, when seeking SharePoint Developers, unless the developer shows a strong interest in SharePoint, you will have a lot of resistance in this change, rather get the ASP.NET developer trained in custom development for SharePoint only, the skills required for that are the skills web developers are already comfortable with, and focus on getting different set of people for SharePoint installation planning and configuration.

Another approach is to understand the purpose and restrictions of SharePoint and communicate that to the end user so there expectations are well managed; unrealistic expectation places unnecessary pressure on the developers which leads to frustration and will draw them away from SharePoint development.