A: Competent SharePoint skills are hard to find. It is not currently taught in universities. If a Business or Computer Science graduate finds his or her way to an entry-level position there is a possibility that the employer has SharePoint and then if the organization has a developed strategy they have the possibility to gain experience. Alternatively if the employees are permitted, they can embark on a self-training regimen but this would be a time consuming effort (given the platform nature of the product) even if they had no other obligations.

Therefore it makes sense to go to the market place for talent. Currently SharePoint skills are at a premium. Many qualified SharePoint professionals are currently engaged and would need to be compensated accordingly to make a move.

Recruiters that do not possess specialization and knowledge of SharePoint often have job requisitions that are either over extending or do not fully describe what is needed. The most popular example of this over extending job title that you will see is a SharePoint Developer. The job description for this role is often borrowed and refreshed with SharePoint skill buzz words from those of .NET developers. The following is an example of a recent job description sent by a recruiter:

A: A common assumption is that SharePoint is as easy as running the install and turning it over to your staff to collaborate and nothing else should be considered besides licensing and staffing. While these two do need to be accounted for, there are other aspects that organizations need to incorporate into their plans, strategy, and budgets.

SharePoint Backup, Content Migration, and Virus Checking can all be considered hidden costs to those not familiar with the platform. As mentioned before in this book there is a healthy ecosystem of third-party products and services available to address these hidden cost areas.

SharePoint is database driven, so backup is as easy as just recovering the database, right? While that is true to a certain extent you will need to look (again) if you have the staff that possesses the high-level of SharePoint knowledge that spans all the little quirks and "gotchas" that this approach entails. Even with this knowledge in place is it worth the time and effort to carry out such a process that may be streamlined by a third-party service or product? That just covers the backup part of the equation; now ask yourself what are the recovery times that are acceptable. Once you have a deployment in place, make sure to take note on how long it took. Are you prepared to reinvest in similar time frames to manually rebuild? After you begin tallying up the potential totals then third-party backup and recovery make perfect sense.

The same scenario applies to migration as well. Moving an entire organization's content from one system to SharePoint is going to take a fair amount of time. Do you have the time to allow the uploading or copying of hundreds of GBs when a product could do it in half to a quarter of the time with metadata in place? Yes, manually moving files would also need to account for adding metadata once files are in SharePoint.

The question in this case is how much content there is to move. If a SharePoint project is meant to be a "line in the sand" where only new content goes in, then this time and cost do not need to be applied. In that case the amount of content does not justify the cost of the additional tool.

As for Virus checking, out of the box protection options are certainly available, but just as in the personal computing space, there are services that go above and beyond. Within SharePoint products and services ecosystem, there are products that have been developed with the advantage of SharePoint knowledge bases that dealt with many of the problems that you may encounter.

While you may have enough space in your content database, other hidden costs may be the additional need for servers and even more licensing. An example that comes to mind are any servers dedicated for Disaster Recovery. These should be put in place to take over in case the production environment fails.

I am sure you are asking yourself "Apart from Disaster Recovery why would you need more servers?" The easiest explanation is that some of the larger applications in SharePoint 2010 begin to take on a life of their own and that need may not be for more size (space) but actual processor strength (performance). Search functionality usually is the first child to leave the house because as content and user population grow it will need more muscle in order to return quicker results. If you are using any Business Intelligence features, you may find that Enterprise SQL licensing needs to be in place in order to handle all the SQL instances that need to be present within your farm as well as speed of data processing.

Another example where performance is a key issue is in regards to physical distance within the organization. If you have users who are spread out nationally or internationally it may make more sense (for performance and compliance) to have say, European-based teams closer to European-based server farms and only use the central farm when accessing central corporate applications and content.

Other hidden SharePoint costs are SharePoint activities working with existing business processes and making these processes more efficient. This activity may not see immediate benefits and in some cases the business value of migrating a process to SharePoint may not be justified. This is why prioritizing initiatives, which was discussed in Chapter 1, Defining a SharePoint IT Strategy, is so important.

A: In the past, IT costs were incurred by a centralized department in an organization and it was seen as petty to charge the marketing department extra because their inboxes were clogged with large PowerPoint attachments. These costs are simply treated as corporate overhead, a straightforward, simple accounting strategy for cost allocation.

Now with the increased adoption of private cloud infrastructures, SaaS, PaaS and SOA, it has become easier to measure usage/consumption and associated allocation costs and a chargeback strategy is now possible for costs incurred. This shift in cost-allocation turns internal IT organization into a service provider and encourages users to treat IT services as they would treat any other utility.

So the answer to this question is that it depends on the specifications of each deployment and the maturity of your SharePoint farm, your IT department, and the organization as a whole. Based upon legal/regulatory requirements and barriers of entry, organizations may fall into one of these two categories:

A chargeback strategy could include any of the following, either alone or as a combination:

A: Making the decision to move from Foundation to Standard and/or Enterprise rides solely on the necessity for feature sets that each has to offer and of course the return on investment that those would bring.

One of the main distinguishing features of 2010 Enterprise Licensing is the inclusion of Business Intelligence (BI). Microsoft's 2010 BI stack (that includes SharePoint and SQL offerings) is highly regarded and is placed in the Gartner's Leader Quadrant for Business Intelligence. BI is the aggregating, analyzing, storing, and reporting on organizational data from different sources in order to make informed business decisions.

SharePoint Enterprise 2010 features offer the capability to create interactive business dashboards that assemble and display business information through built-in web parts, key performance indicators (KPIs), Excel spreadsheets, data-receiving Visio diagrams, PowerPivot, Microsoft SQL Server Reporting Services reports, or various business data connectivity that can assemble information residing in server-side LOB applications.

SharePoint 2010 Enterprise features also include capacity to create and deploy rich client browser-based forms used to gather data when the Microsoft application InfoPath is installed widely in the organization. Users can fill out forms in a Web browser or HTML-enabled mobile device with no download or client components needed.

The advantage is that the end user would not need to have any software to input and submit forms, which were required in previous versions. A similar experience can also be attained using another 2010 Enterprise feature, Access Services capabilities, for the use and distribution of Access databases organization-wide.

2010 Enterprise licensing is also needed in order to use FAST Search in SharePoint. This would be an additional cost and would need to be budgeted. An argument can be made for FAST search if there is a need to have search result returns use contextual sorting based on user profiles, if the overall size of content passes millions of records that need to be searched and returned in seconds, and visual thumbnails are returned that allow you to preview.

Normally the argument here depends largely on the size, amount, and extent of content. The bigger the organization the larger the content and user base will be. Having any filtering advantage in addition will decrease research times.