There’s an industry-wide SharePoint skills shortage. Nobody can currently meet their human resource needs: customers, systems integrators, independent software vendors, even Microsoft itself is short of talent. Such is the plight caused by a product that has been unexpectedly successful, beyond Microsoft’s own wildest dreams. The product marketing team in Redmond has been on autopilot doing ‘maintenance marketing,’ and most of the real brainpower has been oriented towards figuring out what should go into SharePoint V.Next, slated to release sometime in the second half of 2009. By March 2008, SharePoint had generated over $1b in sales and Microsoft had sold over 100 million licenses.
At this year’s SharePoint Conference, held in Seattle in March, the SharePoint skills shortage was already top-of-mind. Customers want to deploy SharePoint but can’t find people to deploy it, develop for it, and – specifically – provide the glue between what the business needs and what the product can do. This is a somewhat ironic turn of events: Microsoft’s trajectory with SharePoint is clearly to provide a different kind of tool, a tool that doesn’t require much software development to be useful in business. SharePoint is the first clear, mass-market-ready departure from custom development to ‘perpetual beta,’ to use a term from social networking/web 2.0. SharePoint is about providing smart end users with a big tool box full of components and building blocks to create amazing business applications. All you need to do with the building blocks is configure them to do something useful, and you get to bypass the IT department completely.
And there’s the rub: end users don’t know how to make software applications, and don’t really want to find out. Regardless of how easy it is to use the tool box, end users either don’t have the skills or can’t be bothered to learn them. This is the same kind of resistance that senior managers felt during the transition to the personal computer: they had grown accustomed to having someone in the secretarial pool type their correspondence for them – so why should they learn to do it themselves? It took a change of guard, a whole new generation of managers, to break through that perception and skills gap.
Microsoft, in its infinite wisdom, or perhaps its way of looking at the world through rose-coloured lenses, has tended to over-simplify the problem. In its eyes, there are apparently only two categories of SharePoint resource, and it’s only those two it provides any official training and certification for. Let’s spend a minute examining these certifications.
In SharePoint, Microsoft recognizes two job categories: IT professionals, and developers. An IT professional is basically an infrastructure specialist. Microsoft offers two courses and exams for IT pros. The first one teaches how to install and configure (from a server/application administrative perspective) Windows SharePoint Services 3.0, and another teaches the same skills for Microsoft Office SharePoint Server 2007.
For software developers wanting to work with SharePoint, there are also two courses/exams: Application development for WSS 3.0, and – you guessed it – MOSS 2007.
There are obviously numerous prerequisites for these certifications – some are actually listed as prerequisites, others would simply be useful to have in order for the learner to take as much value as possible from the courses. A SharePoint developer should already have very well-developed .NET framework, C# skill, ASP.NET and SQL Server skills. HTML, scripting, CSS and a decent understanding of workflow also can’t hurt. Similarly, a SharePoint administrator needs to have a solid foundation in general Microsoft server administration, security, management of web applications, Active Directory, SQL Server deployment and configuration, infrastructure/hardware sizing and planning, etc.
The key challenge presented by this over-simplification is that neither of these job categories are able to address the most glaring needs of customers, partners, or even Microsoft itself right now. What the entire industry is critically short of is resources who can close the gap between what business users want and how to do that in SharePoint. You could call this missing role a “SharePoint Business Analyst,” or maybe a “SharePoint Power User.”
Let me explain why the two prescriptive job categories from Microsoft do more harm than good. Infrastructure specialists, for the most part, are technologists. We’re talking about typical, old school IT folks who like to focus on things like installation, security, scalability, reliability, performance, backups, etc. If they know how the end-user functionality of an application works at all, it is only in so far as it helps them do their job, which is to get it running and keep it running. They don’t typically have the high-touch consulting skills and grasp of the business world’s requirements and priorities to help their customers create applications.
Developers, on the other hand, are trained to look at SharePoint from a “build perspective.” This means that their immediate, instinctive response to every business requirement is to custom-build it. You can’t blame them; it’s what they’re trained to do. But it’s also completely, entirely contrary to SharePoint’s purpose: what makes this a powerful, cost-effective platform is precisely the fact that you don’t really have to custom-develop everything, that you can – instead – “make it yourself.”
A typical SharePoint project team in the real world might consist of the following roles:
- Project/program manager
- Infrastructure specialist, for a short period of time
- SharePoint business analyst
- SharePoint trainer
- SharePoint developer, for a short period of time, to address any custom build requirements
- User support specialist/SharePoint power user
- Quality assurance specialist, for a short period of time (in theory, SharePoint projects require less QA because it’s a complete platform: if you don’t custom-build on it, you may not really have much to test).
So if we take a quick look at this list, we see immediately that Microsoft’s own training ecosystem doesn’t offer anything for about 80% of the resource needs on a typical SharePoint project. No wonder that the entire industry is complaining about the SharePoint skills shortage!
Specialist training companies like Mindsharp, SharePointHQ, Pilot House Consulting and others have already identified this gap in the market and are busily marketing all kinds of training. If you look at their roster of trainers today versus a year ago, many of them seem to have doubled in size. And Microsoft itself has jumped on this bandwagon somewhat haphazardly: it provides online training (created by the marketing team)… and more online training. Programmatically, there are some people in the SharePoint marketing team (product adoption department) tooling away at solving the skills shortage, but it must feel a little like changing the Titanic’s direction – there are simply so many moving parts to this equation. To get a new Microsoft certification rolled out could take literally years, I think.
In my next post, I’ll take a closer look at the definition of a “SharePoint Business Analyst” or “Power User.” I think it’s possible to develop a bit of a job description/skills definition for this role, and I’m hoping to find ways of laying the groundwork for building this into a curriculum of sorts.
Hi,
Great post and read with interest this and the second in the series.
I have worked on in excess of 130 SharePoint projects and concur with many of your observations and actually despair when I see employment agencies/organisations trying to ‘shoehorn’ in what are clearly separate roles into one person – with the expected results of a poor deployment.
I note however with one exception in that you don’t appear to note the ‘Consultant’ resource or resource whom will implement the changes (ideally via out of the box means) once the initial setup is done?
Granted you have the infrastructure resource to deal with the initial framework setup/back-end build and perhaps initial config, but whom carries on the additional configuration or deployment/QA of any bespoke work done by a developer role once they depart to deploy and manage the environment with new enhancements?
This type of resource is key in the support circle for providing governance to a SharePoint environment.
Best,
Andrew.
Andrew,
I think that you’re calling a “consultant” is more or less the same as my “SharePoint BA,” in a way. I realize that there are gradients between the two, but my core ideas are basically twofold:
1. The SharePoint BA is a BA who can elicit requirements while being aware of the constraints of SharePoint.
2. The SharePoint BA is also a power user of SharePoint who can then implement many of the features he determines, as long as they are out of the box.
My posts don’t mean to downplay the importance of having an infrastructure resource as well as a developer resource on the team. I’m simply saying that having *only* those resources on the team (which is what Microsoft suggests time and again, in the way it’s designed its certifications, or in programs like the SharePoint deployment planning program they offered earlier this year, where customers can use vouchers to pay SIs to build a SharePoint deployment strategy) doesn’t make sense and is in fact counter-productive.
I think the “SharePoint BA” (maybe we need to find a better term for him?) could also do the QA. In fact, since he’s specifying the requirements, he’d be ideal for that. Fewer people on the project = less overhead & less confusion.
Carsten