Bill English

SharePoint Survey: How Organizations are Staffing Their SharePoint Teams

Bill English — Sat, 06 Mar 2010 18:57:00 GMT

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:

1. What is the size of your organization - how many employees?
Under 50	8	4%
50-250	22	12%
251-500	12	6%
500-1000	22	12%
1001-2500	32	17%
2501-5000	26	14%
5001-10,000	24	13%
10,000+	40	22%
Total	186	100%

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.

2. How many desktops are in your organization?
Under 50	7	4%
50-250	23	12%
251-500	15	8%
500-1000	26	14%
1001-2500	33	18%
2501-5000	29	16%
5001-10,000	25	13%
10,000+	28	15%
Total	186	100%

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:

3. What type of implementation do you have?
WSS v2	0	0%
SharePoint Portal Server 2003	4	2%
WSS v3	22	12%
SharePoint Portal Server 2007 Standard	28	15%
SharePoint Portal Server 2007 Enterprise	132	71%
Total	186	100%

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:

6. What role(s) do the SharePoint servers in your main SharePoint farm perform?
WFE	156	84%
Index	156	84%
Query	130	70%
Excel Services	85	46%
Document Conversion	23	12%
WSS Search	119	64%
Central Administration	156	84%
Other, please specify	36	19%

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:

The rules by which everyone will utilize SharePoint
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:

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

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.
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:

Stakeholders
SharePoint Admin
SharePoint Dev
SharePoint Architect
Project Manager
Training
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:

Team Role	Type of Education	Mindsharp Offering
Stakeholders, Project Managers, Help Desk, Business Analysts and Internal Training Staff	End-User + Overview on the connection between the business requirements and SharePoint's functionality	Power End-user Instructor-Led Course UserVersity Customized Solution (Call)
SharePoint Administrators and Developers	Farm Administrator Training Developer Training Web Design Training Search Administrator Training SQL Optimization Training Information Organization Training	5-day SharePoint Administrator Course 5-day SharePoint Developer Course 2-day Seminar on Organizing Information in SharePoint 3-day SQL Optimization Course 5-day Search Administration Course 5-day Web Designer Course
SharePoint Architects	Architect Education	1-day course on Architecting SharePoint for Your Organization (Call) 1-day course on re-architecting a SharePoint Deployment (Call)

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

SharePoint Best Practices Registrations Now Open!

Bill English — Mon, 01 Mar 2010 09:38:00 GMT

Registration now open for the August Best Practices Conference. http://www.bestpracticesconference.com. Early-bird rates through 5-31.

Bill English, MVP

SharePoint Deployment Best Practice Scenario

Bill English — Thu, 25 Feb 2010 07:11:23 GMT

In working with a customer yesterday, I was reminded again that what is a Best Practice in one environment may not be in another. Recall that a Best Practice is an action that aligns with your organization's business & technical requirements, culture, politics and security. It is intellectually simple, although the practical application of the action might be difficult. It aligns with the organization's strategies and represents an intentional action.

My customer has 6000 desktops and is in the F500 list. They are on a sharp growth curve to 15,000 desktops and have offices, literally, all over the world. It has taken this team 2.5 years to gain funding for their SharePoint deployment. Because the advent of SharePoint Server 2010 is just around the corner, we found ourselves in a discussion of whether or not to deploy SharePoint Server 2007 or SharePoint Server 2010.

This company currently has Office 2003 and Windows XP at the desktop. (A different customer I visited with earlier this week had the same scenario – I wonder if this is more common that we might know.) Anyways, we listed out on the white board the reasons for staying with 2007 and for going to 2010. Here was our thinking:

Reasons to Deploy 2007	Reasons to Deploy 2010
SharePoint Server 2007 is fully qualified and has passed all of the QA tests, SharePoint Server 2010 does not have a standard matrix yet for testing after the initial install	The metadata services and collaborative taxonomy are highly needed and desired in this environment. SharePoint Server 2007 doesn't provide this OOB
SharePoint eco-system is mature and needed third-party applications are available and supported	Eliminate an entire upgrade project from 2007 to 2010 by starting with 2007.
In-house IT administrators and developers are well versed in SharePoint Server 2007. Training would be needed to get them up-to-speed on SharePoint Server 2010.	Eliminate an entire learning curve for their user base by not having them learn 2007
They can get SharePoint Server 2007 installed and going in production in the next 2-3 months. SharePoint Server 2010, realistically, wouldn't happen until the 4^th quarter of 2010, at the earliest. Demand is high to get SharePoint NOW.	Several VP's are asking for 2010 and don't understand why SharePoint Server 2010 isn't being installed, especially since it has some of the key functionality that this organization needs.
Better learning curve to move to 2010 at the desktop from 2003, then introduce SharePoint Server 2010 at the server end.	Better learning curve to move to SharePoint Server 2010 and then move from 2003 at the desktop to 2010, skipping 2007.
Can customize 40-50 apps for SharePoint Server 2007. Many are already running on a test farm.	Can skip and entire customization upgrade effort by going to SharePoint Server 2010 now.
"We are not an organization that installs pre-SP1 software from Microsoft".

There were some other discussion points, but these represent the main points that we discussed. The last two points were something that could go either way, IMHO. Timing was a big issue – to wait until November/December of this year would be construed as a "miss" by many in this organization and was not acceptable. While the reasons to move to SharePoint Server 2010 were compelling, the decision continued to be to install SharePoint Server 2007 and then do an upgrade project to SharePoint Server 2010 in roughly 18-24 months. Their distrust in pre-SP1 software from Microsoft to be reliable and stable was apparent. (They are not alone in this perception. Many customers I've worked with are post-SP1 customers).

In this organization, the requirement that installed software on servers be run through a detailed quality assurance and set of custom qualifications was iron-clad. Their change management processes simply won't allow them to install product-level software without undergoing this internal compliance step. This decision represented a Best Practice for them because 2007 aligned with their immediate business requirements, technical requirements for product-level software, culture, security and politics. The fact that some VP's were asking about 2010 didn't rise to a level of a requirement and thus, for this decision, could be managed in a different way. Also, the taxonomy services in SharePoint Server 2010 while highly desired, were not a business requirement for the first phase of their SharePoint Server 2007 deployment.

This group was one of the most aligned, in-synch teams I've ever worked with. Usually, there are some tensions and politics within the SharePoint deployment team. This was not the case with this team. I'm looking forward to working with them as they move forward. I think this team will be highly successful and their deployment will be well accepted by their user base.

Bill English, MVP
Mindsharp

Mindsharp FaceBook Page

Bill English — Tue, 09 Feb 2010 22:09:00 GMT

Just a reminder that you can become a fan of Mindsharp's FaceBook page.

http://www.facebook.com/pages/Mindsharp-Education/71973741690

Thanks!

Bill English, MVP

SharePoint Best Practices Conference 2010

Bill English — Mon, 25 Jan 2010 14:29:31 GMT

Registrations for the SharePoint Best Practices Conference will open on March 1 at www.sharepointbestpractices.com. This event will be help August 24-26 with a post conference on Friday, the 27^th. We'll be updating the web site and getting going on lining up speakers and topics for this conference. Be sure to include the SharePoint Best Practices conference in your line up of educational events this year. It will be held at the Reston Hyatt, outside of Washington, DC.

More details will follow as they become available.

Bill English, MVP

SharePoint Server 2010's ECM: Why Businesses Will Take 2010 Seriously

Bill English — Sat, 23 Jan 2010 13:42:00 GMT

When you stop to think about it, what is needed in order to have a robust Enterprise Content Management System? Would we not need the following, at a minimum?

Ability for users to create and manage content areas
Ability to upload information into the system with a low transaction cost
Ability to directly manage that information
Ability to find information in the system with a low transaction cost

In other words, how information goes into the system (Putability) will directly impact how the information comes out of the system (Findability). A good Findability architecture is built on a good Putability architecture, just like a good restore system is built on a good backup system.

In SharePoint Server 2010, there are three main part of the Putability architecture:

Managed Metadata Service
Content Organizer Feature
Default Metadata Values

When these three features (small "f") are utilized together, they for a coherent way to describe and place information in such a manner that it can be found easily. We find information mainly through search and navigation tools, though other tools like RSS, links, shortcuts and the like can be useful in finding information. But until SharePoint Server 2010, we've not had the tools embedded within the product itself to implement a robust Putability architecture.

Now that SharePoint Server 2010 has both robust Putability and Findability tools, I believe the market will begin to take seriously SharePoint Server 2010's ECM features. But make no mistake, a great deployment on paper coupled with sincere intentions on the part of those who are doing the implementation won't be enough to achieve success. Instead, they will need to manage (overcome?) the following ECM busters:

Lack of Governance (and its' enforcement) on how information will go into SharePoint
Lack of funding for a project that is hard to quantify the savings in real dollars
Lack of ongoing care and feeding of the SharePoint Server 2010 information management system
Resistance at the desktop to take the time to apply metadata to information
Lack of an overall Glossary on what the metadata column titles and value choices mean across the enterprise
No agreement between the stakeholders on what their overall end-result is supposed to be
No agreement between the stakeholders on the business requirements for improving the information management system

SharePoint Server 2010 provides solid reasons to choose it for an ECM system. I look forward to working with the community and our customers to ensure they implement ECM correctly, the first time, saving them serious dollars.

Bill English
MVP

The Basics on Content Type Syndication in SharePoint 2010

Bill English — Sat, 23 Jan 2010 12:59:00 GMT

What follows in this post is a brief sample of the type of courseware that Combined Knowledge and Mindsharp are writing for SharePoint 2010 as part of our participation in the World Education Alliance. If you're looking for SharePoint 2010 Training, we would invite you to join one of our Mindsharp or Combined Knowledge classes. Enjoy!

Why Publish Content Types?

There are four main reasons to publish content types. They are:

Consistency
Identity
Location
Lifecycle Management

Consistency

The first scenario is about consistency: Is it (the content type) the same across the enterprise? When one stops to think about it, content types and metadata are really about consistent governance and management and standardization of information in the enterprise. In other words, if I build out content type "A" in Site Collection 1, is it the same construct as when it is used in site collection 2? The MMS will answer this question in the affirmative and yet provide localized extensibility for greater usability of the content type in specific scenarios.

Identity

The second scenario is about identity: What is in the content type? When it comes to the enterprise, is this content type about the same topic with the same metadata? What metadata is in the content type? Understanding the construction of the content type helps us understand it's focus, purpose and meaning.

Location

The third scenario is about location: Where is this content type and how can I use it? The MMS will allow you to search for the content type, navigate to it, aggregate data with it and find data using it.

Lifecycle Management

The fourth and last scenario is about lifecycle: This scenario encompasses the creation, consumption and disposition of the content type in the enterprise. More specifically, the content type can be mapped to a document's lifecycle and then utilized across the enterprise in distinct ways. We'll use workflows to move the document from one lifecycle stage to the next, ensuring that compliance is enforced, tracked and audited.

Understanding Terms

The MMS has some terms that we'll use, so here are some terms and definitions:

Hub - A site collection designated as a "source" from
which we share content types throughout the enterprise
Content Type Syndication - Publishing, sharing, pushing
one or more content types across site collection, Web App.,
and farm boundaries

Note that a taxonomy is not the same thing as an ontology. And ontology is the philosophical study of the nature of being, existence or reality in general, as well as of the basic categories of being and their relations. By contrast, when we refer to a taxonomy, what we're referring to is a hierarchy of objects that will likely include synonyms, equivalencies, parent/child relationships and metadata. In contrast, a folksonomy can be thought of as "free-form" without a hierarchy of terms from which to draw metadata values.

Content Type Publication

The core value of Content Type Publication is the ability to create a data element that has metadata, workflows and policies attached to that data element, and then publish it to the hub and from there, syndicate it to all web applications, site collections and sites in your farm and in child farms. For example, let's suppose your organization develops a policy that says all blog posts are to be expunged 12 months from the last date of modification. Well, you can develop a content type that includes that policy that will kick off a workflow to delete the blog post after 12 months. You'll then publish this content type to a hub and from there, syndicate it across your farm.

Publishing Content Types

Content Types are created within a normal content type gallery and then are "published" from a "normal" Site Content Type Gallery to a hub within the MMS. Each MMS gets one hub for CTS. If you need more than one hub in your farm, you'll need another MMS. It is not a requirement that an MMS syndicate content types nor is it a requirement that a service connection to an MMS consume content types from that service. Setting a site collection to be the hub enables necessary components on the hub for it to operate properly.

The elements that get published include the following:

Content Type with all the corresponding columns
Document Set Content Type
Policies
And workflow associations, but not the workflows themselves

You'll need to ensure the workflows are available downstream where the content types are going to be syndicated. Once those content types land in the destination gallery, they will be re-associated with the workflow(s). If the workflow doesn't exist in the destination site, then no assignment is made and the content type will function to the extent it can without the workflow.

For the content types that are on the hub site collection, you can perform the following actions:

Publish: this means that the content type is being syndicated for the first time
Unpublish: this means that the content type should no longer be in syndication. The effect of an unpublish action is that the content type is made read/write at the local level and is still available for use at the local level, but it's no longer available in a read-only version from the hub.
Republish: this action is used when changes to the content type have been made and you want to push those changes out to the consuming audience
Roll-up errors from consuming site collections: it is possible, in a scenario where there are thousands of content types being published from a single hub, that some content types will contain errors. In those instances, all of the consuming sites will report their errors back to the hub so that the content types can be fixed and republished.

From the consuming side of the syndication, you can:

Extend a published content type: consuming sites can add more columns to the content type in order to give that content type more specificity in the local environment
Derive from a published content type: this means that we can use that published content type as a place from which to inherit to create new, local content types
View import errors: this will allow the consuming site to view the errors that it is reporting back to the hub
Refresh all content types consumed from the Hub: this action allows the consuming site to erase all of the syndicated content types and perform a new, full download of the existing published content types from the hub. This can be especially helpful when the hub has been down or the consuming site has been down or connectivity has been lost and there is a need to capture all of the new, updated changes from the hub.

Setting up Content Type Publishing

There are several steps to setting up the MMS for content type syndication in your farm. First, you'll start at the site collection layer by associating the site collection with the MMS. The MMS is turned on from within Central Administration and the service-to-web application association is also executed within Central Administration. The site collection can be associated at the time the application service is created, as illustrated here, where we're creating a new human resource metadata hub at a new site collection called hrhub.

The MMS can use any site collection as its' hub for content type syndication as long as the owner of the MMS service has permissions to that site collection. The site collection hosting the hub does not need to reside in the local web application with which the MMS is associated. Once the hub is selected from within the MMS, the syndication service can be shared and all of the other consuming sites will need to consume from the shared services' hub. Technically speaking, the syndication is not a push technology, it is a pull technology. So the consuming sites pull the content types from the hub in a pre-configured frequency. That's why, in some ways, it's better to talk about the content types being published as opposed to be syndicated. However, be aware that the literature and informal blog posts will use both terms. In both cases, they are describing a publishing/pull architecture.

Note that the content types themselves haven't changed from SharePoint Server 2007 to SharePoint Server 2010. They are still data elements coupled with metadata, policies and workflows. The content type galleries, aside from some UI changes, also look to be pretty similar.

So, in our example in this module, we're going to create a new content type named "Candidate Evaluation Form" (not illustrated) and then publish it to other content type galleries where it can be consumed and the metadata can be extended. Since the publishing is at the content type layer (not the gallery layer), we decide to put all published content types in the hub in their content type group.

We derived the Candidate Evaluation Form from the Document content type to create a new content type. The Candidate Evaluation Form contains these unique metadata elements (not illustrated):

Job Number
Department Number
Hiring Contact

Once the service application is started, you'll find the publishing action in the properties of the content type itself, "Manage Publishing for The Content Type". If this link doesn't appear, then that means that the service is not started or this site content type gallery does not reside within a publishing hub. Recall that each Managed Metadata Service can have only one hub and that content type publishing is not a requirement in order for the hub to be installed and to operate.

When you click on the "Manage Publishing for this Content Type" link, you're taken to the managectpublishing.aspx. page. On this page, you're able to perform the following actions:

Publish
Unpublish
Republish

Because this is the first time this content type is being published, only the Publish action is available. Until the content type has been published, it cannot be unpublished or republished.

The most common scenario for using the unpublish/republish actions is when you want to update the content type by either adding metadata to the content type or deprecating metadata from it. You can also modify other properties of the content type, but those scenarios will be less common. So let's assume that you want to update a published content type with new metadata while retaining the current metadata on the content type. Here are the steps you'd take to ensure the new metadata is published:

Unpublish the content type. This action will remove the content type from being pulled by consuming sites. Note that this action does not affect content types in consuming sites - their content types will continue to work as needed and as expected.
Modify the content type as needed.
Republish the content type: This action will put the updated content type back into the published role and the consuming sites will be able to pull the updates to the content type to their location and begin using the additional metadata

Consuming a Published Content Type

The first configuration element for the consuming site is to ensure the site is associated with the same application service. This is accomplished in Central Administration. Highlight the web application you wish to associate with the Managed Metadata Service application, then select Service Applications from the ribbon.

By default, all of the service applications appear in the Default group. But you can group the applications into different groups or you can select "Custom" and select your own mix of service applications to associate with the web application. In our illustration, we chose Custom and associated the HR metadata service and the user profile service with the Portal web application.

The act of consuming a content type that is published is a Site Collection Administrator act - in other words, you must have site collection admin privileges to set this up. The link you'll want to select under Site Settings is Content Type Publishing Hub. Note that in Beta2, these links in the site collection admin area are not in alphabetical order, so you'll have to hunt to find it.

That link will take you to the contenttypessyndicationhubs.aspx page. On this page, you will see the hub with which your site is associated. You can check the Republish all content types on next update check box if you wish or leave it blank. Leaving it unchecked will mean that you will not receive updates via the Republish action at the hub. Selecting the checkbox means that you'll re-copy all of the content types at the next update interval.

The update interval is run by the Content Type Subscriber timer service (one for each consuming site collection), which, by default, it set to run every hour at a randomized time between 0 and 59 minutes after the hour starts. You can customize the frequency of how often this timer service runs and, if needed, click the Run Now button (not illustrated) to force the consuming site collection to come to the hub and copy down the content types to their galleries.

Once copied down, the content type will appear under a pre-configured group called Published Content Types.

Once the content type is copied down to the consuming site, it can be extended with additional metadata and other, new content types can be derived from it. Moreover, only the Advanced properties are available on the published content type, with all of the other properties being set and controlled by the administrators managing the source content types at the hub. This means, for example, that you can't associate a different workflow with the content type than has been associated at the hub.

Notice also, that the interface will show the source of the content type to be the consuming site collection. This is because the pull action is a copy action, not just a set of pointers that point back to the source content type source. So the content type is copied and a new content type is created in the consuming site collection.

Bill English, MVP

E-Discovery and SharePoint

Bill English — Mon, 18 Jan 2010 19:51:00 GMT

Oce' has an interesting white paper on e-discovery and what I term litigation readiness. You can download the paper here (but you must register, something I don't mind doing). Key findings of the paper include the following:

Attorneys agree that e-discovery preparedness is one of the most important functions of a corporate legal department (77%)
Yet less than 50% have implemented any type of e-discovery preparedness via internal processes or technologies. Reasons for this varied, but the most prominent was that it took the lawyers away from case-related activities
Law firms are developing e-discovery personnel to help their clients with litigation readiness
Most in-house firms are nervous about working with their IT staff to help with mitigation of e-discovery risks
60% of organizations, according to their in-house counsel, lack a fully implemented records management program
35% plan to implement a records management program in the next 12 months

Many will be choosing SharePoint as their Records Management system. Many will people who understand the triangle of services: technology, information architecture and business processes. Firms that can deliver these three skill sets will be in high demand.

Small and large organizations alike are in the bull's-eye when it comes to e-discovery. The fact that one in five corporations will be sued this year is no laughing matter. Forget that most of the lawsuits are frivolous. Responding to them still costs time, money, energy and employee attention. The opportunity costs can be significant. Organizing information with a view to mitigating exposure to liability for e-discovery will become a sunk cost that can't be recovered. Yet, if you're one of the 20% who will be sued this year, you'll be glad you undertook such a project.

You can learn more about e-discovery and how to organize information in SharePoint by attending my upcoming seminar on February 15 & 16. If you'd like, you can email me offline (bill@mindsharp.com) to ask questions about this seminar.

Bill English
Mindsharp

SharePoint Staffing

Bill English — Mon, 18 Jan 2010 15:13:00 GMT

When I go out and do design and architecture engagements with our customers, I'm routinely asked about staffing levels for their deployment. Often, I'm asked about what other companies and organizations are doing to staff their SharePoint deployment and support needs. So, after asking several customers if they would be interested in participating in a staffing survey and getting their consent, I thought I would post this and ask if others would be willing to participate in the same survey.

The survey will focus on your current SharePoint staff relative to the size and type of your deployment. In many organizations, SharePoint is "part-timed" within the same staff of those who support other applications. In some, it is full-timed. All you'll be asked to do is to estimate the FTE (Full-time equivalency) of the various SharePoint roles, then report on the number of SharePoint servers, number of site collections and size of content databases as well as if you have MOSS or a WSS-only implementation. We'll also ask about the number of SharePoint users in your environment and the number of overall desktops too. That will help all of us understand SharePoint penetration in most organizations. We will not ask about salary information.

The survey won't take long if you have the information needed for the survey. We'll releases the results back to those who complete the survey, but that means they will need to identify themselves in the survey to ensure that they have completed it. If you want to participate, please respond indicating as much to me (bill@mindsharp.com) and we'll send you the link to take the survey. If you are on our mailing list, an email went out today about this. If you've not received the email, please check your Junk Mail folder and ensure that email from Mindsharp is white listed on your email server.

I trust you've had a great holiday season and that you're on a good track for 2010. While it has been a difficult time for many businesses, it's also a great time to be thankful for what we have and to work harder to create a better future. Take care and I hope to hear from you soon. Please let me know if you have any questions.

Bill English
Mindsharp

Signs of an Unhealthy Site Collection

Bill English — Sun, 17 Jan 2010 18:11:00 GMT

I was working with the crew at DePaul University this past week and we talked for a while about the danger signs that would indicate the unhealthy use of a site collection. So I thought I'd share some of our conversation with you all. Many thanks to the talented team at DePaul University for their input in thinking through this with me.

Constant Need to Move Information Out of the Site Collection to Keep it Within Prescribed Database Ranges

This is actually a constant battle for several of our clients who must keep information for X number of years, but still need to have that information available for collaboration within the site collection. Recommendation: programmatically move the oldest information to a file server or other location so that the newest information can be developed and utilized within the site collection. Use Scopes in search to group the two locations together for fast retrieval of information.

URLs longer than 256 characters

We've know about this for some time, but it seems to me that URLs that are longer than 256 characters represent either a lack of good user education or an information structure that is too deep (or both). Wide, but more shallow site collections will help prevent this problem.

Lack of good end-user education

Despite what you might have heard, SharePoint is not entirely intuitive. Users need education, not only on how to use it, but also on how to use it within your environment (think Governance training here).

Installation of untested home-grown code

Note that I'm not against home-grown code being installed and utilized in your farm. What I'm against is untested code. Site collections with untested code = high potential for disaster. This was brought home (not by DePaul), but by our theoretical (and tangential) discussion of how much code should be tested in a lab before being deployed in production.

Wrongly Secured Information

I suspect that most people don't stop to think about the site collection owners having access to every document and list item within the site collection. If information is placed in a site collection to which the site collection owners should not have access, then you have wrongly secured that information. It should be moved to a site collection whose SC owners can and should be able to see the information.

There were more items we came up with, but this is all I can remember. Perhaps I'll get the rest of the list and post it here at some point. Thanks.

Bill English
MVP, Mindsharp

	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>