What should I look for when hiring SharePoint Talent?
What skills should I build to get more involed in SharePoint?
Any of these questions sound familar? I have put together a white paper based on past presentations and discussions regarding the SharePoint community and what type of skill sets fit the bill. Feel free to download the file or just read the below.
Baltimore SharePoint Users Group
President – Co founder
Thursday, May 15, 2008
I have been asked many times by recruiters and aspiring SharePoint people alike, “What are the types of Roles that are needed in a SharePoint deployment, and how do I staff/prepare for them?”
If you have done any investigation into this question you will know that there are a few major points to follow, but a lot of these write-ups don’t answer this basic question effectively. I’d like to give that a shot today. Keep in mind, this is from personal experience. I have been a part of quite a few MOSS deployments and have learned a great deal from each one. However, this is in no way absolute, and is open for interpretation and discussion.
This is a great question because like I say often, the traditional lines have been highly blurred. I will refrain from getting into all the roles of a SharePoint deployment out because some of those questions should be answered in the weeks of planning that SHOULD lead up to a SharePoint project kick off. Some of which include, Business Analysts, Information Architects, Hardware Architects, Designers, Project Managers, Developers, etc.
As I see it, there are three major roles and one optional role for SharePoint not all are needed at the same time on every engagement but for most new projects migrating or standing up a new version of MOSS/WSS you should have all three.
· A SharePoint Administrator
· A SharePoint Developer
· A SharePoint Architect
· The SharePoint Mutt
I’ll go into detail on each one and how I think each one is extremely critical to the success of a SharePoint deployment and a SharePoint team overall. Also, I’ll add that the habitation of the blurred areas in itself is a potential crucial realm.
I have read similar articles and papers suggesting that when recruiters or organizations seeking a SharePoint “person” they should be looking for the “IT STAR”; someone that can do it all, or have their hand in all the pieces of SharePoint. I disagree with this to a point, the reason is because SharePoint as a whole is a LARGE beast, but in a sense it’s modular as well. It has many different components interacting with it to perform the tasks of an organization. To expect an organization to take the financial burden of a person who knows a LOT about SharePoint is unrealistic. Those people are extremely hard to find and if they’re found harder to lure out of their current sweet gig.
I always propose a team effort; however there are some exceptions to the rule in which I’ll highlight below.
The SharePoint administrator has become much more than it was in SP 2001 and 2003. The administrator is now, of sorts, a developer. As the definition of a “developer” has started to shift with more full featured COTS products, the Administrator is becoming the master of his domain.
As products like SharePoint come out with GUI accessible “programming” abilities the world of the Admin continues to grow.
Case in point, SharePoint’s BDC or Form Services. No longer is the admin restricted to creating sites and lists, they are now gaining the responsibility of setting up data sources to external applications, pulling that data in and choosing one of the hundreds of ways to display that content to the user.
To sum up the Admin for SharePoint, he/she is the grunt in the trenches. The person who sets up and manages services running in the SharePoint Enterprise, creating new sites and lists, installing and manipulating web parts, and doing backups. Outside the mold the admin is creating BDC connections, managing shared service providers (SSP’s), creating InfoPath forms and integrating them into SharePoint. They should also be managing governance polices and permission groups.
They should know their way around Central Administration from search settings to creating site collections. He or she should also have a solid understanding of IIS, Active directory and STSadm SharePoint command line parameters.
Most importantly they should have a firm understanding of what SharePoint can do OOTB (out of the box) and what it cannot do without major manipulation. They also need to manage expectations of what their managers have somehow come to believe is possible with little effort in MOSS 07 (probably from a sales call with everyone on it except a SharePoint person).
These are just SOME of the areas an Admin should be familiar with and have working knowledge on. Obviously there are many mediums between for example SSP’s alone command a lot of understanding.
The SP Developer for the most part has remained the most unchanged. The perspective of where they address their profession obviously has changed with the new version of SharePoint. For example files aren’t located in the 60 hive anymore; they’re in the 12 hive. DLL’s change, controls change, ideals change but the main meat of the subject, DEVELOPMENT stays intact. There are however, two roles of the developers.
Really what the roles dictate is the impact on the project itself. The “Lead” role goes to developer that has the most knowledge of the SharePoint API. Someone that can take on the more complex tasks like workflow and others I outlined below. The supporting developer is in no way less valuable, but are more inclined to handle more traditional developer roles such as web parts, event receivers etc. Obviously if in a pinch the lead role would be more desirable if you could only have one or the other.
A “SharePoint Developer” should be well versed on .NET 2/3, windows workflow foundations (WFF aka .Net 3). The Developer should have a solid understanding of C# and or VB.net and a solid understanding of the SharePoint API as a whole. Building workflows from a completely custom Visual studio direction as well as custom coding SQL and SQL server manipulation and maintenance are certainly highly sought after. In addition to these things that are in the developer’s tool box, comes the addition of more XML/XSLT minded development. Being that most things in SharePoint are xml based or can be converted and fed as xml/xsl, these are just another set of skills are another way that the developer can increase their value.
A solid understanding of SharePoint Designer, IIS and editing web config files ALWAYS come in handy. And here is where the lines shift a little for the developer. CSS, Branding implementation, InfoPath forms- these are additions to the developer list. Not to say that CSS wasn’t already on the list, but how it’s used may come as a shock to some developers. SharePoint in its current form is very visual, well that is once you take it out of the box Microsoft has painted it into. A lot can go into the branding and visual aspect of SharePoint. These are things that were never a huge issue back in 2003 when most companies were happy with the features that SharePoint brought to the table. After being stuck with it for a few years, the desire to change the look and feel of the portals got to be overwhelming. So a developer that can take that designers comp and be able to tell the lead or manager what will and will not translate into a literal SharePoint world, then take that design and make it a reality with master pages and site definition page layouts is extremely valuable.
The reason why I think that the developer is the lesser of the three changed is because at the end of the day he/she relies on the same tools to do the job. They can be expected to do the same type or work, custom web parts to workflows and everywhere in between.
I hear the word “Architect” used very loosely in the SP scene. It’s been presented in the context such that it could mean someone who puts all the SharePoint pieces together. They would figure out the information architecture, architect a plan and procedure. This in a sense is correct, there needs to be someone on the project that understands SharePoint as a whole, knows the inter-connecting pieces well and how to orchestrate them in such a way that all comes together in the end when it all needs to. However I believe this job goes to the lead on the project. If the lead is a project manager, he or she better know MOSS inside and out. But this can be anyone on the project that has the knowledge of the product that is conducive for success.
What I believe the SharePoint Architect covers, is the hardware and networking side of the project. The complexity of SharePoint has dramatically grown since SP 2003, that being the case the “Architect” needs to understand a host of technical aspects.
He or she will need to understand the END GOAL of the client. This does not only mean what the project entails while you are on it. You could only be doing a migration of four business units, but if the end goal of the client is to migrate 200 gigs of data and all their team sites, the Architect needs to understand this and propose a enterprise farm that will meet these needs long after that portion of the project is completed.
The Architect also needs to setup the projects environments. In some cases this can be a full blown Development, Staging and Production environment. If that is the case it’s very important to have all the environments match as close as possible if not be exact. The Architect also needs to understand fail over’s, clustering and load balancing, for large farms this is imperative.
A SharePoint Architect also needs a solid understanding of alternate access mapping in MOSS, host headers, DNS entries, Kerberos configuration and multiple forms of authentication (forms auth, ntml etc).
The lines between Admin and Architect I have found overlap the most, especially when the admin is a corporate employee and the architect is the consultant (or vice versa). One owns the network; the other administers the SharePoint sites on the network.
Let’s see, how do I explain the SharePoint Mutt? As I stated before, I don’t think it’s wise for a corporate organization to go after the “IT STAR.” First, if anyone tells you they are an expert in everything SharePoint, they are probably pulling your leg. There is always someone else that knows a different part of MOSS or integrating features better than the last. But the mutt is what I think, as close as you can get to the IT star as it pertains to SharePoint.
The Mutt knows a whole lot of it, but not everything about all of it. He or she gets in the mix with setting up the architecture and the physical environment, administering the services once the farm is up and running and doing development work to some degree or another.
The Mutt is the person that knows those gray areas better than the position that only focuses on let’s say administration. They also have a bigger picture view of the project. The mutt is a designated hitter of sorts; they can get involved in any aspect of the project from web parts to server patches.
In this consultant’s opinion, the mutt is one the most valuable person on the SP team. The Mutt will almost always have a desire to learn more aggressively, have the initiative to be involved and get results from all directions. They should also be humble; there is no shame in saying they don’t know something but as a specialist in the general, they’ll be the first to figure it out.
I hope all of you found this white paper at least a little helpful. If you are a recruiter or an organization looking to fill a SharePoint position, I hope this will help you streamline what you are looking for in your candidate. Remember; look for specialists, not experts.
If you are a SharePoint professional, I hope you have been at least enlightened on what the guy sitting in the next cube over from you is doing.
As I said in my first few paragraphs, there are a lot of different people that make a SharePoint deployment work. There should be a few weeks of intense planning before undertaking any SharePoint venture. Those being the case, a slew of specialist in things outside of SharePoint are very important to have. A project will always pay the price if it is not planned for and managed properly.
In addition, at any given time any of these roles can be reversed. An admin can take on workflow; a developer can manage web applications. The gray areas seem to shift based on the skills of the resources on the project.
Appreciation goes out to some people who added their input and guidance on this white paper. Anthony Wisniewski, Erin Carter, Shadeed Eleazer and Steve Selleny thanks for your help!
|PFE Meet and Greet 2014 and Survival guide
Updated: February 24, 2014
|What is checked out and how big is it?
|Cut the (Cable) Cord
Updated: August 28, 2013
|Nokia Lumia Stuck on Gears
Updated: August 26, 2013
|IE 10 and SharePoint Explorer View
|Using 301 Redirect URL Rewrite module to Redirect SharePoint urls
|Hide Search Box in SharePoint Online
Updated: May 9, 2013
|So you want to brew beer
Updated: April 30, 2013