SharePoint Turf Wars

SharePoint Turf Wars - Part 1

By Russ Edelmann posted 02-17-2011 11:05

Recommend

Regardless of whether you are fan or foe, SharePoint has firmly planted a stake in the ground and has become part of the IT fabric in most organizations. The purpose of this blog is not to extol the wonderful features and functions of SharePoint, nor is it intended to give you pointers or warning signs on some of SharePoint’s gotchas. Instead, my intent with this post is to dig into an interesting trend I have observed over the past year regarding the management of SharePoint environments. That trend is all about the bloodthirsty quest (ok blood thirst is only there for dramatics but highlights the point) of many people to own the keys to the SharePoint kingdom.

Is this a view of SharePoint Governance through a different prism? Yes. However, it is an area worth exploring as companies and individuals are betting big on SharePoint. To address this, there is a need to be more thoughtful and proactive about the distribution of responsibilities for managing, administering, contributing and viewing all things SharePoint. This distribution is becoming increasingly important as it has become clear that successfully deploying SharePoint requires an amalgam of skills; which extend well beyond those of the technologists. I emphasis successful as too many SharePoint implementations are “technically successful” but prove to be a “business failure”.

As a result, it is important to recognize the diverse and distributed set of skills needed to do it the right way. Requisite expertise includes technology prowess (of course), but that can be segmented into three distinct areas; architecture, infrastructure, administration, development and help desk/troubleshooting. Other skills include strong organizational skills (information architecture), communications skills, project management skills, business analysis skills. When blended and proportioned properly, this combination of skills can be very potent.

So, in an effort to make sense of a potentially contentious environment, I would like to offer up a few recommendations, starting with the easiest and advancing to the more complex. As a guy who loves tables, I give you the “SharePoint Turf Table”. Can a graphic designer please step up and render this on a map! I’ve broken this post into two pieces with the first being “solid” turf and the second being “slippery” turf. Next week, I’ll give you my take on the latter.

Apologies for bad formatting...It looked better in Word! All feedback welcome!

The “Solid” Turf…	Ideal Candidate Profiles
Architecture Touching and tickling almost all dimensions on the technical front and often supporting business functions or people delivering those services.	Lives/breaths/eats SharePoint internally and plays an active role in tracking what others are doing – should have risen through the ranks and have a lot of scar tissue.
Infrastructure Configuration of servers (physical and virtual), farm configuration (WFE, database servers, app servers), redundancy, disaster recovery, network performance.	People passionate about the physical side of the house. Typical upbringing consists of deep expertise with server builds, Operating Systems, Databases (but not necessarily DBAs) and networking.
Site Collection & Site Provisioning Central Administration and above which includes all of the administrative controls and throttling linked to Site Collections, Site administration, the provisioning of sites, lists, users, integration with Active Directory or other authentication providers (especially in cahoots with infrastructure on this one).	Somewhere in between the developer and the infrastructure person, lays the person who will own the important keys to this part of the kingdom. This guy/girl should be highly organized with a great appreciation for structure and process. They need to enjoy living in this world and serving as a key intermediary between many different roles.
Development and Deployment SharePoint has unquestionably become a major development platform. Development with SharePoint typically includes the creation, maintenance and troubleshooting of Service Applications, Timer Jobs, Application Pages, WebParts, Custom Actions/Conditions, CAML experience, Event Receivers, Feature Receivers, Provisioning Handlers, Custom Workflows and the ability to integrate with other products.	SharePoint developers (as compared to .NET developers), should have intimate knowledge of the SharePoint object model, APIs, Web Services and packaging of solutions. If they don’t have these skills, do not fear, just invest properly and set expectations accordingly regarding ramp-up. It takes a while.
Training and Help Desk Many organizations look at SharePoint as a tool that requires little or no training. For basic functionality, this is typically true. However, having a training and help desk program to support more advanced capabilities and business specific logic does become very important. This also becomes rather political as communications and messaging play a pretty key role in this area.	Trainers should be those who are thoroughly familiar with the targeted area of SharePoint (they don’t have to know everything about SharePoint). They should also be very familiar with the configuration and the business process to provide the necessary value. Hands-on experience also makes a big difference. From a help desk perspective, multiple levels of expertise makes a big difference and I typically recommend some type of rotation and on-going educational/ramp effort while providing support makes the person much more rounded.
Corporate User Experience (UX) Standards The SharePoint user experience demands a multitude of experiences to get it down correctly. In its simple form, its basic content population, image placement, theme selection and basic font manipulation. Going deeper into graphic design and layout, one must be familiar with master page configurations, page layouts, graphic design, CSS and XSLT. There is also a dimension of JavaScript and potential coding expertise that may be necessary.	To satisfy the UX demands for SharePoint, I would recommend three different hats be formally recognized. There is the classic graphic designer (imagery, layout, flash, color design, etc.). There is then the “graphic programmer”; the person who takes all of the graphic work and incorporates into the SharePoint constructs (master pages, page layouts, themes, etc.). The third hat is the person who associates the graphic programming work with sites, pages and other components within SharePoint.

#governance #responsibilities #Roles #Management #sharepoint #SharePoint

0 comments

80 views

Blogs