SharePoint Deployment - Bad Attitude not accepted?

I have been a SharePoint consultant and trainer for nearly 6 years now. In my experience, an often overlooked problem regarding SharePoint deployments, is the bad attitude towards the whole project from key employees or even groups of key employees, this can be really harmfull and it should be adressed.


First there is the IT people. i have experienced IT guys with a really really bad attitude towards the SharePoint deployment. Very often they had very fixed ideas of rights and wrongs within their field of work. They would typically be Mac or Linux evangelists forced into a SharePoint project by decisionmaking above their level. I fully recognize their worries about propriatory software and usability and so on. But having an bad attitude, as i see it, only makes their own everyday worse, and with the decision already taken, It really only makes one difference in a negative, unproductive fashion by 3 factors at least.
They will have an negative impact on their direct IT collegues working miljeu! 
The end users perception and readiness to get involved in the SharePoint implementation!
And  lastly, maybe even their companys overall productivity because moving to another knowledge file and sharing system like SharePoint is a big and important move that requires the whole company to pull towards the end goal, a successfull new intranet solution.
I may be forgiving toward other emplyees having a bad attitude, but with this group i find it very hard. Ofcourse they feel some responsibility for the best selection of software and solutions, but when the decision is made, they have to deliver, because they moved from being nay sayers to bad attitude. The solution............ hmmm

Another common scenario is the lack of dedication from parts of the executives or heads of offices in the company. Typically you could hear from the head of sales, that SharePoint isent of his concern, it is an IT problem, "Fix it!  We got customers to visit and contracts to sign. The affect of this could be a slow migration of the sales departments content into SharePoint as he will not accept time and ressources being allocated for the migration.
This is of obvious reasons not very productive, and it emphasizes the importance of having the CEO's full commitment and acceptance, that willingness to participate is required from ALL head of departments within the company, no exceptions made.
They are somewhat excused, as their primary business goals definately isent that of facilitating a new intranet. In other words, they have to be educated. A little trick here, if you own a Enterprise license, can be a quick and dirty presentation of Business Intelligence with PerformancePoint, Your Sales Executive will go from "Never Ever!" to "Please tomorrow" in 15 minutes. Another good approach could be making a SharePoint Migration group that will travel the departments, helping them with the migration.

Then there usually is a part of the end users who really dont think that "the new system" requires their attention and some may even insist that they will continue to work as usual. That means that they will insist on saving their files to a fileshare or even continue using and older system thet is to be outphased. When i in a training room meet this employee that has to move to a new system for the 6th time in their carreer looking tired, looking for their pension in 5 years, i do feel a bit of symphathy.

Their unwillingness to adopt SharePoint (or any other new system) is to be dealt with by the organization by facilitating services that would make them want to user the new system. That could be a good planning of Content Types and Workflows that will make their everyday easier by delivering Office templates and support for the business processes in their daily work situations. Educating them and having a strategy for education.  Also a clear strategy for getting rid of the old systems is needed. As an example, fileshares. Setup and communicate a date from which content must be migrated into SharePoint, and then make the original fileshare read only.

Lastly, Dont forget the importance of SharePoint evangelism in your company. You can assign someone the role of being an SharePoint evangelist or SharePoint business consultant if you like. Make them produce instructional videos to be published in the intranet, make demonstrations at meetings and so on
They will ofcourse have to be given very important, give them responsibility in the SharePoint project that amkes them feel ownership and commitment. But also dont forget, that the "yes sayer" culture has its limits, it is very often the "no sayers" that points out things that needs to be improved, (I hate the yes sayer paradigm in some companies) You have to facilitate appropiate and constructive channels they can use to express their concerns, wich could be our new infrastructure. and that is to be exactly SharePoint!

Dont fight the Nay Sayers, Fight the Bad Attitude!

Best
Morten Reintoft / Reiners

Site eller en site collection? Thats the question

Jeg kommer i rigtig mange virksomheder hvor jeg ser hele intranettet proppet ned i en site collection. Det er ikke særlig hensigtsmæssigt, denne post forklarer hvorfor.

Det handler om administrative niveauer, altså steder med settings som gør at man kan differentiere funktionalitet og muligheder i SharePoint. En liste over de administrative niveauer vil se ud som følger:

Farm
Web application
Site Collection
Site / Web

Hvis vi kigger nærmere Site collection og laver en hurtig liste over funktionalitet der styres fra Site Collection settings, så vil den se ud som nedenstående:

• Rettigheder - Rettighedsgrupper oprettes og kan ses per Site Collection, Hvis man kun har 1 Site Collection i virksomheden, så vil man typisk opleve at have alt for mange rettigehedsgrupper og brugerne bliver forvirrede. Man skal huske at hver gang en bruger vælger at et subsite skal have unikke rettigheder, så oprettes der typisk 3 nye rettighedsgrupper. Dvs. at har man 500 subsites med unikke rettigheder, så viser oversigten 1500 grupper at vælge imellem! Helt håbløst for slutbrugeren
• Caching - Hvis man vil styre caching så er det en feature der skal aktiveres per Site Collection (Publishing Infrastructure)
• Content Types - Også Content Types styres per Site Collection. Godt nok kan man publicere dem på tværs af web applications og endda farms med Content Type Hubs gennem Managed Metadata Service Application, men hvis man vil differentiere Content Types gennem sin farm, er man nød til at have mange Site Collections.
• Automatisk sletning - af indhold som ikke bruges længere sker på Site Collection niveau gennem central administration.
• Managed Paths - er meningsløse med kun en Site Collection. managed paths kan give virksomheden en sund og meningsfuld URL struktur. 
• Search - kan konfigureres på Site Collection niveau, man kan bygge og tilbyde unikke scopes, keywords og best bets i Site Collections.
• Recycle Bin - Papirkurven er per Site Collection.
• Workflows - en række af SharePoints indbyggede workflows aktiveres per Site Collection.
• Site Collection Features - er den måde du grundlæggende styrer hvilken funktionalitet dine brugere tilbydes er per Site Collection. For eksempel den helt centrale SharePoint Server Publishing Infrastructure. Men også document sets, documet ID's og hele Business Intelligence (PerformancePoint) delen aktiveres per Site Collection.

Der er flere, det her var bare nogle af dem som kan gøre mest ondt ikke at kunne differentiere gennem sin installation. Hvad værre er, er at SharePoint kan få dårlig Performance af en struktur hvor du kun har en Site Collection.

SharePoint 2010 har en anbefalet max database størrelse på 200GB. Hvis denne overskrides kan man opleve et performancetab. Måden man regulerer database størrelsen på er ved at tilføje nye databaser og så flytte site collections ind i dem. Med en arkitektur hvor du kun har en Site Collection så er det jo af indlysende grunde vanskeligt at flytte "nogle" af dine Site Collections da der kun er 1. Site Collection.

Der er også udfordringer med mange Site collection. Man bliver indtil SharePoint 2010 nød til at finde en løsning på navigationen i virksomheden. For Microsoft har ikke leveret "Cross Site Navigation" med i pakken. Det betyder at man ikke i top navigationen er i stand til at vise andre site collections. Mange virksomheder har løst det med at for kodet en menulinie som altid er synlig i toppen af deres installation. I SharePoint 2013 er problemet løst, da Microsoft har gjort det muligt at anvende Managed Metadata som navigation. Jeg har skrevet et blogindlæg her:

SharePoint 2013 - True Global navigation using Managed Metadata

Du kan også komme ud for at udviklere græder over det er besværligt at installere deres løsninger, hvis det er tilfældet må du fortælle dem at de må lære lidt PowerShelll. Powershell kan løse dette men kan også gøre en masse andre ting for dig hvis du vælger en sund arkitektur med mange Site collections, fordi PowerShell er et Powertool til at lave Bulk operationer i SharePoint.

Afsluttende vil jeg bemærke at en stor del af forvirringen kommer fra to kilder. Den første er at microsoft ikke har orden i nomenklaturen. Når man vil lave et subsite også kaldet et web som så skal man klikke på "NEW SITE" i Site Actions menuen. Site er ellers den normale betegnelse for Site Collection. Hvis du netop åbner PowerShell konsollen, så er PowerShell teamet faktisk de eneste som har været konsistente i anvendelsen af Site = Site Collection og Web = Subsite.

Enjoy
Morten Reintoft
http://reiners.dk