Sunday, August 22, 2010

The “All in One” SharePoint Guru does not exist – so stop looking and focus on plan B (Part 1 of 3)

I published my “Shortage of SharePoint skills” blog post on numerous sites, many readers were in agreement with the points made in the article but the comments surrounding the blog post indicate that the shortage exists because companies are looking for ONE person to handle the entire SharePoint delivery.

I have a few theories why this is happening. Bottom line, the business does not know what SharePoint is; they see it as a product similar to Word and Excel, so they get there IT administrator to install this product, and expect everyone to use it.

Unfortunately, it’s not that simple. Unlike Word and Excel, SharePoint is a platform, not really a product, and this platform is very flexible. It’s designed that way so it can be adjusted to fit within your organisation, be it a small business or a multinational company.

SharePoint also offers a lot. It’s described as a collaboration platform, but this platform offers Content Management, Intranet Portals, Business Intelligence, Workflow Automation, Records Management just to name a few. This high volume offering makes SharePoint a rather complex platform.

To add to the complexity, SharePoint is a platform designed to empower the business users to update their website and add features and functionality to satisfy their business need (in a well controlled and governed environment). This was a role previously fulfilled by the IT department, so a successful deployment would ultimately mean a shift in control and a process changes which can be a challenge to implement in large organisations.

This level of flexibility and complexity means that a lot of information, planning and input from many different types of experts (technology and business related) is needed for a successful SharePoint deployment.

I have been working with SharePoint projects since 2007, from then till now I have defined a list of essential skill sets needed for a successful SharePoint deployment. This is my findings (grouped by typical phases you would find in a SDLC).

Phase 1: Envision

In this phase, you need to determine what the business wants. A Project Manager and a SharePoint Business Analyst is needed to hold meetings with Stakeholders and define the requirements.

Lets focus on the SharePoint Business Analyst, the BA is expected to have a good understanding on what SharePoint is all about, this means a strong SharePoint overview (not necessary technical) skill set. The BA will need to know what SharePoint can offer and how it is offered. With that knowledge, the BA can determine the following...

  • Is SharePoint the right solution for the business requirements? The truth is, it may not be, rather figure that out now, before investing more money.
  • Can SharePoint provide the features requested “out of the box”? Must custom development satisfy the business requirements or can an alternative “out of the box” solution be provided.
  • What is the business expecting? Are these expectations unrealistic or not in line with SharePoint’s offering? Assist in managing the expectation.
  • Determine a phased approach, as mentioned before, SharePoint offers a lot, determine the immediate success factors and focus on that
  • Determine “who will need what access to what”. For all the business requirements requested, determine the owners of that feature, the administrator, the approver, the contributor and also the viewer
  • Compile a Governance Plan to determine rules, standards, processes and what SharePoint features should be made available
  • Determine how the business would like their content structured
  • Determine how the business would like to search for content (taxonomy)
  • Gather information that affects capacity planning such as expected number of concurrent users or expected amount of content that requires indexing.
  • Determine what SharePoint License is required. Can SharePoint provide all features requested via the Standard License or is the Enterprise License required?
The Project Manager need not have a strong skill set of the SharePoint offering, but having it will be advantageous. His focus will be on the management component of the project which is not the focus of this article.

I do want to add that the PM needs to initiate the forming of a Steering Committee, that will provide direction to the SharePoint Solution as well as support to the governance plan

For the BA to gather the information mentioned above, he will have to engage the following people:

  • Project Sponsor - to determine his requirements and objectives
  • Business IT Manager – to determine hardware and software availability, details on existing systems that may require SharePoint integration (or SharePoint is replacing) and other IT specific or technical information
  • All Business Unit Managers – to define their unique business requirements (it is recommended to meet them via a phased approach if the organisation is large)
  • The Steering Committee – for proper decision making and governance support

Phase 2: Planning

Article continues here

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
  • 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.