Building Your SharePoint Team

How do you size your team? How many people does it take to run the SharePoint farm? When I first started it was 1 ops guy managing 17 SharePoint servers, but there was a shared PM resource for deployment, a SM who all it seemed like he did was email, and an Engineer who missed his days of Exchange and had a hard time with the lack of data around SharePoint (no offense Ross). Sizing your team isn't about the # of servers, it's about the service offering demands.

 

The LONE SharePoint Admin

 

I was in Rochester a couple of weeks ago at a SharePoint summit and heard some strange talk about small farms. The speaker was recommending small farms and was comparing the cost of deploying WSS to MOSS to the Internet. I was so flabbergasted by the recommendation of starting with a small farm, and starting with WSS for the Internet I had a hard time sitting still. I was wondering what planet the speaker came from, until I heard more from the audience. In the session of about 35 people 5 people raised their hands to having small farm deployments (were these his customers?). I think that was the first time I'd seen such a thing especially coming from people at a SharePoint conference. Those raising their hands were surely in the camp of I do anything and everything that my SharePoint deployment needs. I was relieved to hear that SQL express wasn't recommended as well as Basic install not being encouraged. (I'm still convinced the basic install was written for the analysts and proof of concepts deployments, and should be called out as such.)

 

This sole admin scenario involves no coding. An occasional off the shelf tool, or solution might be deployed with a support and maintenance agreement. The codeplex solutions should be very carefully scrutinized and really less is best if availability and supportability is of concern. (I could mention the Quest supportability Codeplex plans here, but I know that this is being flushed with by some early feedback. You can be sure I will point to any resources and anything that gets published on this, cause I think it's game changing for those looking to get codeplex tool support.)

 

No matter the fact that you've got one head that may not even be dedicated (especially if you're running Small Business server or a small farm), you need to make sure you have a test environment that can easily be torn down and built up to test nearly anything (Solutions, Hotfixes, Service packs) that is introduced into the farm.

Caution: If you go the one head route...

 

  • Beware the Jack of all trades, the Admin who secretly dabbles in dev and loves to be creative (Dev, Admin, Designer in one) they love to do it all in production and your environment will suffer
  • All your eggs in one basket... what happens when this knowledge goes for a better paying SharePoint job?

 

 

Divide and Conquer= 1 Portal Admin (Site Collection Admin) 1 SharePoint Admin/Server Admin (No developer, No designer)

 

A couple of weeks ago I was at a Seattle SharePoint User Group session where a digital imaging company shared their deployment stories.

 

The speaker explained that they were the portal administrator and they went on to show their environment and every once in a while they would apologize for the ugliness of the pages, but praised the platform on functionality. It was obvious they didn't have a designer, but the pages they showed were very functional and interesting.

 

They said they they would essentially put together everything from top to bottom until it required access to Central Admin or Server Access. They would then ask the Server Admin to make the appropriate changes, as that server admin also managed other web infrastructure, the Exchange environment, and other servers.

 

 

Mid Range+ Deployment= 1 PM(shared), 1 SM(shared), 1 Ops(dedicated), 1 Eng(shared), Dev+(shared) 1 Support lead (dedicated/shared)

 

The PM gathers the business and technical requirements and works with the service manager and stakeholders to put together the governance plan and manages the plans for migrations, business process management plans, and manages resource planning, etc...

 

The Service Manager is the interface for the service definition. They lay out the direction of the service and are the face of the service to the business. They run the communication plans with the project manager.

The ops guy runs the infrastructure and support (If you've got a help desk, they will handle some level of calls and escalate server tickets)

 

The engineer may have 2 hats. They may do any testing, especially performance testing, integration testing, and doing anything complex for the first time. They help make running the trains straight forward and repeatable and scalable for ops. They also work to ensure the SLAs (Service level agreements) aren't being compromised, and ensure that the platform is stable and reliable. Systemic issues from the ops may be escalated to engineering.

 

You can see how each of these roles can evolve into teams which own larger and broader services. People don't need to be dedicated to a few servers. The way to achieve economies of scale in a service oriented deployment is to allow people to specialize and get good at doing what they do. They get better by working with the things that touch the service that brings the broad, and the solutions, integration and scale brings the depth. As the SharePoint platform stretches, so should the SharePoint team. Who is managing file sharing, collaboration, document management systems, web content management systems, portals, intranet infrastructure, BI reporting and analysis infrastructure, business process management, records... You get the idea. This team can expand and will expand as their knowledge and ability to cope expands.

 

 

Big+ Deployment= Dev Team, Ops Team, Engineering Team, Support Desk, Service Owner/Manager, PMO (Project Management) Team & SQL Ops Team, Backup Team, AD Team, Exchange Team, MOM (Ops Manager) Monitoring/Escalation Team, Network Team, etc...

 

Now you can see how an enterprise scales. Where the roles turn into a team based activity. The tasks are shared and the functions are owned. Each service is managed and owned.

 

Shared Support

 

Since cost is so important, it is very common that people will wear multiple hats. If responsibility can be siloed into Dev vs. Ops, and Test vs. Production both change management will be more smooth, but availability will run better. If the server admin owns the SharePoint infrastructure and the exchange infrastructure, but Exchange is Mission critical and SharePoint is business critical you know which one they will spend their time on. You know which one will suffer, be careful about that.

 

Ownership

 

Whether you or small or large the trick is to achieve a balance of satisfaction where people OWN. Ownership is the most important thing when building teams. If anyone or any team doesn't feel ownership, they won't be happy.

 

As a developer you own your solution, and you own your code. You can get very excited about the functionality. You like clear requirements and you want people to be happy with what you build.

As a SharePoint Admin you need to own the servers. If someone else owns them, why will you care if they go up or down? It's not your fault if they are a moving target and things are changing without your approval. There is a direct coorelation between Ownership and availability.

 

The site collection owner, owns the quota and is responsible for keeping the site collection clean and functional. The more this is shared the less clean a site will be. Even if there are a lot added, the idea is one person or a small team is ultimately responsible for the destiny of the portal or site collection.

You get the idea.

 

Jennifer Mason breaks down the SharePoint team like this:

 

•SharePoint Owner

Responsible for the overall SharePoint Implementation. Has ultimate responsibility to direct the implementation of SharePoint in relation to the organizations goals and initiatives.

•SharePoint Infrastructure Administrator

Responsible for the server installation, configuration, operations and maintenance of SharePoint Farm.

•SharePoint Solution Architect

Liaison between the IT Support and the End Users. Responsible for SharePoint Central Admin settings such as: search configuration, top level site creation; SharePoint user security.

•SharePoint Designer

Responsible for SharePoint branding and solution layouts.

•SharePoint Help Desk

Responsible for the support of end users through the function of the Help Desk.

•SharePoint Developer

Responsible for custom SharePoint development using .NET, Java, InfoPath or SharePoint Designer.

•SharePoint Site Owner

Responsible for defining the requirements for SharePoint site, usually within a department or for a specific solution. Gathers and defines requirements for proposed solution. (Usually a Department Manager)

•SharePoint Site Designer

Responsible for the design of the SharePoint site based on the direction from the Site Owner. (Usually Department Power User)

•SharePoint Site Administrator

Responsible for managing SharePoint Sites. Manages user access to the site, uploads content, designs site and manages first level user support.

•SharePoint End User

End user that uses SharePoint in the course of their daily work. They browse / search SharePoint sites to access forms, policies or general information.

About the Author