Recently, Mindsharp conducted a survey about staffing in our customers' deployments. In this extended blog post, I'll outline what we learned and will offer some inductive conclusions on how organizations are staffing their SharePoint deployments. I'll also draw out some other conclusions about the supporting data that is rather interesting. If you want to download a PDF copy of this post, you can do so by registering at the free content site at http://www.mindsharp.com/.

Methodology

The first step in obtaining this data was to send an email to our active customer list. In that email, which came directly from me, each customer was invited to participate in the survey. Those who responded were then sent the link to the survey. I did not send out the survey link to everyone on our list because I wanted to work with those who would take the time and effort to complete the survey. Those who responded, I surmised, would take the time to complete the survey. I was right – over 70% of those who responded to take the survey completed the survey. Given that the survey was about staffing, it was interesting to note some of the comments in interest e-mails I received back indicating pent-up interest in this topic:

• "Although our experience is more like an account of what NOT to do, I think that perspective may be useful too."
• This has been an area of great interest to us, but difficult to estimate. . . . .thanks for coordinating this effort. . . .
• I would like to participate --- and I'm dying to know the results.  I think SharePoint requires more time for support and development than anyone thought it would be and we are understaffed.
• I need to provide some data points to management so this will come in handy.
• Would LOVE to reply as we are a 2 man team supporting EVERYTHING SharePoint, including Site Admin training! 

Basic Statistics

186 individuals completed the survey. There were no duplicate or secondary responses from the same organization, so our research represents responses from 186 different organizations. Not everyone completed the survey and I did include answers to questions from those who did not finish the survey. Hence, as we move through this survey and discuss the results, bear in mind that not all of the responses will equal 186. Some will be less, but none will be more. The first question was as follows:

As you can see, the responses were evenly spread over the various sizes of organizations with the largest percentage coming from the 10,000+ user base.

The second question dealt with the number of desktops in their organization. The reason that I asked this question was because certain verticals, such as retail, can have a high number of employees who do not use computers (Wal-Mart or Target are good examples where there are a number of employees in retail positions that would never use SharePoint), so the more accurate way to assess an organization's potential to utilize SharePoint is to assess the number of desktops they have in their environment.

Again, as you can see, this survey was evenly distributed across small, medium and large environments with the largest percentage having between 1001 – 2500 desktops. 76% of the respondents have at least 500 desktops and 62% have over 1000 desktops.

We also needed to assess the different types of SharePoint implementations that exist in the respondent population. The reasoning behind is that those who purchased more features would naturally use more of those features in their environment (at least that was the hypothesis). I think the data will bear out that this hypothesis was incorrect. At any rate, the implementation numbers are as follows:

As you can see, the vast majority (71%) have SharePoint Server 2007 Enterprise implementations. Surprisingly, very few were Windows SharePoint Services-only implementations. Now, this could be due to several variables that I didn't control for, such as whether or not those who implement Windows SharePoint Services-only farms tend to purchase or not purchase training services. Obviously, our customer list consists of those who purchase training for SharePoint, so organizations that do not make such purchases would not have been included in this survey because they wouldn't appear in our customer list. Moreover, those who utilized Windows SharePoint Services-only implementations may be the type of organizations who would like to purchase training, but lack the resources to do so, leaving them with the necessity of utilizing free educational resources from organizations like Microsoft or Mindsharp. That would tend to correlate with the notion that organizations with low resources would tend to not purchase SharePoint Server 2007 or SharePoint Server 2010 because of the licensing costs. Also, the high number of Enterprise deployments might simply indicate that most of the customers in our database have Enterprise Agreements (EA) that included SharePoint Server 2007 Enterprise, so when they decided to deploy SharePoint Server 2007, they had no compelling reason to not implement the Enterprise version. This would, of course, run against best practices that would advise customers to purchase and deploy only that which is necessary to fulfill the business requirements developed to resolve a business problem. But I would suspect that in most environments, the thinking was "hey, we got it – let's use it. And let's install all of it even though we don't intend to use parts of it".

The thrust of this survey was to find out how organizations are staffing their deployments. But before we can dive into the staffing numbers, we need to better understand our basic numbers. It should also be noted that this survey is focused on SharePoint Server 2007 because SharePoint Server 2010 was not available for production at the time the survey was conducted.

Farm Size, Desktops and Number of Site Collections

From a hypothetical standpoint, it would seem to me that larger organizations would tend to have more servers in their farm and utilize more of the features in SharePoint Server 2007. So, the number of desktops in their environment because an organizing statistic against which much of this data is compared. I then proceeded to do basic comparisons between farm size, number of desktops and number of site collections.

The size of a SharePoint farm in this survey was defined as the number of physical (or virtual) servers in the farm less SQL, because is some environments; the SQL implementation supports a variety of applications in addition to SharePoint Server 2007. For most of the questions in this survey, I focused on their main production farm. The question was phrased as follows: "For your most important production farm, how many SharePoint servers are in the farm, not including SQL server?" Here is what we found.

First, for those organizations that had over 10,000 desktops, the number of servers in their farms was clustered toward what we would normally call the small or small-medium farm size. The horizontal axis denotes the number of servers in the farm. No one reported having 10 servers, so that data point was not reported. The vertical axis denotes the number of organizations that have that number of servers in their farm. For example, there are 14 farms in our survey that have only one server and those 14 farms came from the group that has 50-250 desktops. Moreover, there are 9 farms in the 10,000+ desktop group who have three servers in their main SharePoint farm. Here is the aggregate information.

I was surprised that the kurtosis of the curve was as positively skewed as it is across all sizes of organizations. I would have hypothesized that the skew would have been positive for smaller companies but negative for larger companies and normally shaped for medium-sized companies. For example, I would have expected that those organizations with 50-250 desktops would have installed farms with only one server (which is largely true) and I would have equally expected the 10,000+ crowd to have installed farms with 8 or 10 or more servers (which is not mostly true). But the data didn't bear this out at all. In fact, a surprising number of farms installed in the 50-250 group had three servers which are five more than the 251-500 group. And while some of those larger organizations have installed large farms, the majority (mode) installed three servers in their farm.

Since I didn't control for features or functions utilized in the survey, several plausible explanations for the positive kurtosis include:

• Most farms are installed as a point solution for enumerated purposes
• The SharePoint software is so efficient that farms installed as an enterprise service (as opposed to a point solution) really can run effectively on a small number of servers
• Larger environments can afford higher-end hardware, so they can service more client demand with fewer servers
• Larger organizations have more compliance and testing hurdles, more change management and rigorous processes to undergo in order to install more servers in a farm than medium-sized organizations, so the effort to clear 10+ servers in a SharePoint farm relative to the business requirements for utilizing SharePoint is not equal, leading the IT team to run the solution on fewer servers.
• The larger organizations have not experienced deep penetration of SharePoint into their environment, so the current footprint of their deployment might be less than half of their total number of desktops

Now the opposite of what I've just written could be argued. In larger deployments, one could easily assert that in the larger organizations, management tends to be more risk adverse with higher requirements for fault tolerance, disaster recovery and backup/restore issues. These requirements would lead to additional servers in the farm, leaving us with the following explanations as to why larger environments tend to have smaller farms:

• The individual answering the survey didn't know how many servers are really in the farm – s/he was guessing
• The individual answering the survey under-reported the number of servers due to virtualization – there might be 12 SharePoint virtual machines running on 3 physical machines, so they reported 3 machines instead of 12.
• The individual couldn't assess which production farm was the most prominent or "main" farm, so they reported on their own farm, which might be a smaller implementation in comparison with other production farms in their environment

The results are probably a combination of the bullet points above plus some points that I've not thought of. In any case, it's interesting to note that while Microsoft talks about farm scalability, the market isn't, generally speaking, implementing large-scale farms.

I also asked about the number of farms in their environment. I didn't specify production farms only, because test farms and development farms still need to be staffed – at least that was the assumption. Here is the data correlated for number of farms vs. number of desktops:

I think it's safe to say that the one response with 300 farms is a hosting provider or else they have an incredible amount of collaboration going on. Again, across the board, regardless of the number of desktops, the vast majority of implementations consisted of three or less farms. Clearly many are not even installing two farms, which means that they have a production farm but do not have a testing farm in which to conduct quality assurance routines on home-grown code. While the smaller environments have one farm – as I would have hypothesized – it is surprising that the three largest environments are not skewed in the direction of multiple production farms. Combining these two charts, one can see how most environments are standing up one or two farms with (generally speaking) three or less servers.

The reason for the few number of farms, I suspect, has as much to do with licensing costs as with anything else. I would suspect that by and large, organizations who have installed all of their EA SharePoint licenses have decided to "make due" with what they have and not go outside their EA to purchase additional licenses for other farms.

Now, I hypothesized that one strong indicator of robust collaboration is a high number of site collections in the farm. One would think that if there is persistent, pervasive collaboration in an organization, that the number of site collections will be high. Of course, this betrays my basic belief that an organization's collaboration should not be conducted in one or two site collections. Instead, I firmly hold to the position that the more collaboration an organization takes on in SharePoint, the higher the number of site collections there will be, due to any number of factors that are outside the scope of this post. The question that was asked was this: "How many site collections exist in your main SharePoint farm?" Here are the results:

The way to read this chart is to see the number of reported site collection on the horizontal axis and the number of organizations reported that number of site collections on the vertical axis for a given desktop range (yes, the number of desktops was a core element that I pivoted on several times). For example, there were two farms from the 10K+ desktop range that had over 10,000 site collections. On the other end, there were seven farms that had three or less site collections. You can see that some farms from the 10K desktop range had a relatively small number of sites collections (two were under 20) and yet there were two farms coming from the 5001-10,000 desktop range that had well over 5000 site collections in them.

I would make the assumption that those farms with a few number of site collections (under 50, to be arbitrary), have deployed SharePoint Server 2007 more often as a point solution and less often as an Enterprise service application. Conversely, those with a large number of site collections have done so, at a minimum, for its' collaboration features. Now, it is possible to install SharePoint Server 2007 Enterprise as a point solution for collaboration features, but I would suspect that in most of those installations where there is robust collaboration, they are also utilizing other SharePoint Server 2007 features. Once could also surmise from this data that a number of implementations lack pervasive adoption this data doesn't tell us if these farms are experiencing poor penetration into the enterprise or if SharePoint Server 2007 was purchased for a limited functionality – perhaps one that doesn't involve the creation of a high number of site collections.

The data here was interesting. For example, the 10,000+ desktop range, there were two farms that had only one site collection (I'm assuming that those who responded know what a "site collection" is and that they are reporting accurately). Notice that in this desktop range, the kurtosis is not just platykurtic, it's really rectangular. This means that across the spectrum, there is no statistically significant variation or grouping in the number of site collections for those environments who have over 10,000 desktops.

Those who had less than 250 desktops had 500 site collections as the highest number reported for that group. Those who were in the 500 – 1000 desktop range reported the highest number of site collection as being 828. In the 2501-5000 desktop range, the highest number of site collections in a single farm was reported to be 5595. Generally speaking, as the number of desktops increased, so did the highest number of site collections in a single farm. But this may not be the most useful of data, since even the largest of environments scaled down to the smallest of the number of reported site collections.

What can be concluded from this is that there is no consistent pattern across the size of the farm relative to the number of site collections. However, as the number of site collections increased in a farm, so did the number of servers.

We also wanted to see if there was any correlation between the products in production and the number of site collections. This data is presented here:

The only real surprise to me is the number of SharePoint Server 2007 Enterprise farms hosting less than 10 site collections. I was also surprised to see Windows SharePoint Services-only farms hosting site collections in the thousands. What both of these numbers tell me is that SharePoint Server 2007 and Windows SharePoint Services are being implemented for specific reasons and that in some of these implementations, verbose, pervasive collaborations is not part of their design.

Now, what server roles are being utililized in these farms? Here is the data:

For other, here were the responses:

• DocAve (2)
• InfoPath Form Services (4)
• AvePoint
• Search Server Express
• Project Server 2007 (4)
• Anti-virus
• Axceler (2)
• Separate, dedicated SSP Server
• WCM
• SharePoint Server 2007 Search (2)
• K2 BlackPoint (2)
• OpenText CLM Services for SharePoint
• Tsunami
• Nintex Workflow

To have 186 respondents report that only 154 farms have Web Front End (WFE) servers is perplexing, to say the least. Perhaps those who filled in the survey didn't know what a "WFE" is – the acronym wasn't spelled out on the survey. Moreover, it is possible that 31 people simply chose not to fill in this question. But whatever the reason, the same 154 who have WFE servers also have index servers. The next most popular server role was the Query role. Happily, all of the farms that had WFE servers also had Central Administration running! In all honesty, I'm not convinced that this question was asked in the right way, so I view the data from this question with some suspicion.

Staffing for SharePoint Farms

Now that we have discussed the basic numbers, we can turn our attention to staffing. The first question I asked was this: "What is the FTE (full-time equivalency) of SharePoint farm administrators? (1.0 equals one full-time individual)". Please bear in mind that all of the staffing questions were focused on the respondent's main farm and were not supposed to cover staffing for "farms in the wild" or for multiple farm deployments. The reason for this was due to the complexity of putting together a survey that would elicit data with true positives to the exclusion of false positives or false negatives. Being this was my first survey of this kind, I tried to keep it simple.

Frankly, if you have multiple production farms, my first inclination would be to multiply these numbers here by the number of farms you have to arrive at an approximate number of FTE's needed for your deployment. This would, at least, give you an educated guess.

The responses are as follows:

As you can see, across all of the farm sizes and number of desktops, the majority of farms deployed had two or less full-time SharePoint administrators. Surprisingly, one farm in the 50-250 desktop range has three full-time administrators. But when you look at the raw count of those who have 2 or less FTE administrators, the number is 158 out of 186 respondents, or 85%. Notice also that the farms with the highest number of SharePoint administrators (4.5 – 5.0) came from the medium sized companies, indicating that the level of administration these farms need is more directly related to activity in the farm than the size of their deployment. Again, I would have assumed that the largest deployments with the largest number of desktops would have resulted in higher SharePoint administration staffs. But the data doesn't bear out this hypothesis.

A similar question to ask is this: As the number of servers increases in a farm, does the number of SharePoint administrators increase? The data comparison between the number of servers and the number of administrators is here:

The way to read this chart is to see the FTE equivalency of SharePoint Administrators across the bottom with the number of servers represented in the color bars. So, the highest bar on the chart would indicate that there were 11 farms that had 3 servers in them that had one full-time administrator. The last bar on the right would indicate that there is one farm with five administrators who have only 3 servers. Again, this data seems to indicate to me that the staffing for a SharePoint farm, from an IT Pro perspective, it more related to the functions of the deployment rather than the number of servers or the size of the deployment. From a higher perspective, I would postulate that those farms deployed as an Enterprise service will require more care and feeding (and thus more man-power) than those farms which are deployed as a single or multi-point solution. In essence, staffing becomes tied to business requirements (like everything else).

Other than the Farm Administrator, there is no other role more central to a SharePoint deployment than that of the developer. I did ask about the developer role and here is the data:

There appears to be a number of farms that have no on-staff developers at all. Since I didn't control for outsourcing of development activity, all I can report on is the number of FTE developers on staff. So those who reported having no developers on staff may be either confining their deployment functionality to that which comes out of the box or they are outsourcing their entire development effort. But again, the vast majority of farms deployed have two or less FTE developers. Out of 186 respondents, 149 (80%) have two or less full-time developers on staff for SharePoint. Moreover, just because an organization has someone devoted to SharePoint development doesn't mean that they are not also outsourcing some of their development work. Unlike administrators, who rarely outsource the administrator of their farms, development can be more readily and easily outsourced, so there is a variable here that might skew the reality of just how much development is going on in our SharePoint industry.

This survey also asked about other SharePoint roles on the overall SharePoint team. I was surprised by how many of the farms claimed to have SharePoint architects and how many large deployments didn't have architects:

In this survey, there were 28 farms that had over 10,000 desktops and 25 of those environments reported a SharePoint Architect. But of those who have on-staff architects, how many of them actually were full-time vs. part-time (and presumably splitting their time between SharePoint and other applications)? Nearly all of the architects were below 50% time on SharePoint with many being pegged in the .25 to .20 time range. This tells me the in-house architects are splitting their time and attention between SharePoint and other applications.

What does it take to be a good SharePoint architect? Well, what you want is someone is both technical and business oriented. Someone who understands business processes and has experience managing a team, a P&L and working with customers, partners and vendors. At the same time, this individual needs to understand the technology that s/he is architecting at a granular-enough level to be able to connect the business requirements to the features of the technology inside a scope of rules that is developed via collaboration between the stakeholders and the technology team.

Interestingly enough, those organizations with 10,000+ desktops report having only 6 Taxonomists (librarians). This means that only 27% have someone on staff who can help them grow and manage the putability, findability and organization of their information. In the 2501 – 5000 desktop range, there were 6 organizations who reported having a taxonomist, which means that 21% of those organizations are supported for taxonomy services. As our industry moves into the SharePoint 2010 era, with its' Metadata Services and improved organization features, these companies will come up against the very real problem of having to figure out how to organize their information with SharePoint in mind. The opportunities for training and consulting companies will be significant.

You've probably noticed that we had an "other" category. What other roles did people report on their SharePoint teams? Here is this data:

• Third Tier Support
• Records Manager
• Common Solutions Manager
• Search Administrator (2)
• Project Server Developer
• SharePoint Sherriff

I like the SharePoint Sherriff role. J Perhaps Mindsharp should start a certification for that role! But seriously, each of these roles was mentioned only once, except for the Search Administrator, which was mentioned twice.

When it comes to the search technologies, I've been persistently surprised at how little organizations utilize the full range of the search and indexing technologies. Especially when they have it "all" installed via the Enterprise version. With the advent of FAST and the improved search capabilities, coupled with the taxonomy services in 2010, it just seems to me that this is another area where our customer base will need to vastly improve both its server-side skill set as well as improving the end-user's ability to execute quality queries that will limit the number of false positives in their result sets. At this stage of the product's maturity cycle, to have only 2 search administrators out of 186 farms is surprising to me. It does demonstrate that SharePoint Server 2007 is not being deployed often for robust search and indexing deployments. Perhaps other products, like Autonomy or Google are still well entrenched and the sunk costs are a barrier of entry for SharePoint search. I don't know. But to be fair to the search technologies, I am assuming that a robust search and indexing deployment will require significant resources to support, most of which are FTE people who can troubleshoot crawl and result set issues.

I also wondered if any relationship exists between the number of servers deployed and the roles performed on the SharePoint team. Summary data is below. This data would be consistent with the data above: Since most farms have three or less servers in them (at least in the main production farm), then it would stand to reason that the vast majority of roles on the SharePoint team would be associated with those farms that have less number of servers.

However, this question asked about all of the SharePoint servers in their environment, not just their main production farm, so we find that the distribution of roles is relatively consistent across the farms, regardless of the number of servers.    

Governance

I also asked a direct question about whether or not the respondents liked their current Governance plan. The question I asked was this: "Are you happy with your Governance of your SharePoint deployment? Why or why not?" Here is the summation of their responses:

Not Happy – 74 (40%)

Mixed - 54 (29%)

Happy – 58 (31%)

Surprisingly, less than 1/3 of the respondents are "happy" with their Governance plan and its' effect in their implementation. A full 40% stated that they are not happy with their Governance plan. In spite of all the articles, presentations, blogs, materials, advice, assistance or other messages about Governance since it became a hot topic in early 2007, the majority of the SharePoint customer community continues to work under a dissatisfactory Governance model. Why is this? The data didn't indicate any single reason or cluster of reasons for why they dislike their governance models.

However, I suspect (and this really is speculation on my part) the problem lies in the type of Governance advice and planning that is being given. Most of what I've seen starts with the SharePoint technology rather than starting with the business requirements of the deployment. There are really several layers to a strong Governance plan: the business layer, the technology layer and the enforcement layer. Governance isn't about the proper use of SharePoint unless you can tie those directives to business requirements. Governance isn't about technology only. Governance is about people and processes. Governance can't be (mostly, anyways) enforced via technology. Governance is best enforced via people – managers managing people. Managers doing spot checks in the technology to ensure that people are utilizing SharePoint according to the Governance rules is how most Governance needs to be enforced. People manage people, not technology. People enforce Governance rules, not technology.

From another perspective, Governance has two parts:

1. The rules by which everyone will utilize SharePoint
2. The designation of who will make and enforce the rules

Governance Matrix

	Business Layer	Technology Layer	Enforcement Layer
Rules for Use of SharePoint	Based on business requirements, defines what the technology should do.	Derive from this what SharePoint should and should not do.	List out the method of enforcement. If the rule cannot be enforced, then it should not appear in the Governance Document
Designation of Responsible Part for Creation and Enforcement of Rules	<enter position title here>	<enter position title here>	<enter position title here>

Now, a few other items to keep in mind:

1. (Yes, I'm repeated myself here) If the rule cannot be enforced, then it should not appear in the Governance Document

1. The entire Governance document should be 10 pages or less. I've seen several 50-100 page Governance documents that have been developed and submitted as the standard to which people need to pay attention. In nearly all of these scenarios, the documents are ignored because they take too long to read and there are too many rules to remember. If necessary, keep your mammoth Governance document to help you feel better, but then write a short, concise version for your users to refer to. Short, simple, clear, and easy-to-read. That's part of the ticket to doing this correctly.
2. Train your users on the Governance, not just the technology. Third-party training companies like Mindsharp can only go so far in writing SharePoint materials for your users. There is a point at which you'll need to append those materials with your own materials. I advise that end-user education start with the Governance rules and the Business Requirements that led to the adoption of SharePoint Server 2007. Distilling the requirements and how those requirements solve certain business problems for your organization are a key way to gain buy-in from your user base as well as help them connect their use of SharePoint to the company's strategic goals.

So, I'll submit to the community for their collective consideration that most Governance is not working because it is not grounded in the business and technical requirements and most of the rules are not enforceable. Perhaps, at some point, I should publish a sample set of Requirement, Governance and Training documents for companies to consume. It would be a lot of work. Uffdah!

One other explanation might be that the Governance implemented has been excessive and without enforcement, leading users to ignore important directives. This is another way of saying they have a 100+ page Governance document that isn't read and is mostly not enforceable.

How to build a SharePoint Team

Lastly, I'd like to suggest some methods of building your SharePoint team. When implementing or growing your SharePoint deployment, it is best if you can start with the core support functions that are absolutely necessary and then build out your team from there. But follow the Best Practice of building out a team that can support a deployment based on business and technical requirements first. So, start with a SharePoint Governance Team:

1. Stakeholders
2. SharePoint Admin
3. SharePoint Dev
4. SharePoint Architect
5. Project Manager
6. Training
7. Business Analysts

Then, this team (in theory) can build out the Governance document. More likely, a subset of this team will actually do the writing with the full team discussing and giving approval/direction.

While the Governance is being written for your deployment, this team will also need education on SharePoint because they will not be as well versed in SharePoint as a Governance team needs to be. Their training should be as follows:

After you have built and trained your SharePoint Governance team, you'll find that this same team, with minor modifications, can also be your ongoing SharePoint Implementation Team (SPIT) or your SharePoint Deployment Team (SDT). Things that your ongoing SDT will need to advise and make decisions on include taxonomy development, end-user education for new employees, changing business and technical requirements or establishing secure extranet policies.

This team is an ongoing effort that will exist in perpetuity. That is the best way to ensure your SharePoint deployment has the proper care and feeding support from everyone impacted by this technology.

Summary

I trust this post has been helpful to the community. I want to thank Mark Ferraz at SolutionsMark, Peter Serzo from Microsoft, and Joel Oleson. Any and all mistakes in this post are mine, not theirs, but I do want to thank them for reading through this post and offering suggestions on how to improve it. I suspect that there is much that I'm missing here, so please respond with questions and I'll see if I can give solid answers out of the raw information that hasn't been presented here. In addition, I anticipate that based on the feedback, I'll be doing a second round of surveys to further flesh out this information. Any advice or ideas would be greatly appreciated and can be posted here as a response to this blog or emailed to me at bill@mindsharp.com.

Bill English
Mindsharp