Sunday, August 01, 2010

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.

15 comments:

Rajesh Sitaraman said...

Useful one, clearly depicts the current trend

Amol said...

true... and the best part is that you have depicted and written it very nicely. Being a SharePoint admin, I am going through these situations.... nice post.

Sahil Kaul said...

Really a well written blog on SharePoint

JacoR said...

Nice Post, now we only need "Business" and the person who signs the cheques to accept this.

Maine Enthusiast said...

A well articulated post. I can add a couple of points based on my experience as a Sr. Consultant PM/BA who has delivered custom MOSS 2007 solutions for a number of clients. I have noticed that when .Net developers get brought in to extend a SharePoint solution, I they are often frustrated by having to build on a product that constrains their options and whose object model does not always deliver as expected. Few ASP.Net developers really like working in the SharePoint custom solution space. They find it confining and quirky to deal with. To your point about learning the SharePoint product, I have found that .Net developers do not always suggest the best SharePoint solutions. They can tend to see requirements as nails to be smacked with a .Net coding skills hammer. This can sometimes lead to a custom solutions when OOB functionality could have met the need with a user acceptable variation in the implementation.

Nadir Kamdar said...

I just want to add a point that is not mentioned in this article. If more that 20% of your SharePoint Solution is Custom (as in NOT OOTB) - chances are - SharePoint was the wrong solution - and you may have created an environement that is not using the SharePoint features properly and is difficult to maintain.

Andrew Twigg said...

A SharePoint Expert needs to be an expert in how business works, how people access systems not in coding. Nadir is completely right: if you're modifying SharePoint too much then it is not the right solution.

You don't want a developer - you want an expert who understands business and what SharePoint is capable of, and they are hard to come by - ask ERP companies trying to hire ERP consultants.

Benjamin Athawes said...

Just to add my $0.02, another factor is the cost of a SharePoint developer vs. a traditional .NET developer.

Typically SharePoint developers have .NET as a grounding so invariably they will cost more to hire.

Hence, companies often hire .NET people only to find that they don't get on so well in the SharePoint space.

Anonymous said...

This article is only true if you approach SharePoint as a *product* which is not always the correct approach. Instead, look at it as a productivity framework on top of ASP.NET and *all* of the issues in this posting go away and the real power of SharePoint as a platform become evident. This is how asp.net devs should approach SharePoint.

Anonymous said...

Nice post, although its a lot of words to basically say that SharePoint is a hybrid skill set for a packaged product that has a different set of tools than other web dev.

Mike Atkins said...

Fair enough, I agree absolutely that a lot of the thinking in SharePoint is different from "normal" .NET development.

So, how do you get SharePoint developers?

I think that SharePoint Designer is a great tool (despite its FrontPage heritage). I also feel that non-developers can be trained in SharePoint Designer, but that some development skill or background is probably needed.

Raj said...

Its a great article, firmly explains the need of developer skills to improve out of the box and have to look SP as a product rather than traditional framework.

Anonymous said...

Hi Nadir!

Great article. :) All I can say thank God for .NET developers trying to develop on SharePoint.. this actually creates interesting amount of business for us SharePoint troubleshooters :)

Eventually customer will learn/mature in the way how do they select the SP devs. :)

Cheers,
Boris

Oliver Houston said...

They discover it limiting and unique to cope with. To your factor about studying the SharePoint item, I have discovered that .Net designers do not always recommend the best SharePoint alternatives.

LewisTaylor said...

It is difficult to convey to employers the vast amount of knowledge one must acquire to be proficient in SharePoint.