Last week's post was fairly heavy, (and, due to some editing errors, it ended up being ID 101, but whatever) so I decided I'd do something slightly lighter this week. If you actually managed to read through it all, and you're still with me, you earn a gold star!
Not, I suppose, that this isn't heavy in its own way, but it saves you from my thoughts about the local telco for a little bit.
I was asked recently, partly as a joke, but I took it seriously, how I'd recommend a new technology (in particular, SharePoint) be integrated into any given culture. The question was almost certainly about a particular business environment, but SharePoint is actually a really versatile tool, and there are a few situations where I imagine that it could be deployed and used for various things.
In a business environment, there are two generally accepted ways to deploy and culturally integrate any given product or process. You can have management install it, create policies, and then dictate to employees and managers at lower levels that this is how they'll do things. This can be effective, but it's often said that it is a bad idea because it's poor for morale. Employees more and more (well, always, but they're expressing it more) want to have been consulted and considered when a process or technology comes onboard. Considering and consulting users when a change is made is typically a good morale booster, and even if a particular person's preferred method wasn't taken, they feel better for having been asked.
That brings me to bottom-up deployments, and advocacy. Many management texts suggest that a good way to get something accepted in a corporate or other organizational environment is to just start doing it. The way this ends up happening with technologies is with management buy-in, have the advocacy to start using the product come from people at various levels in the organization at once.
I think that advocacy of SharePoint for almost any kind of legitimate deployment is really important. SharePoint isn't just a thing that you set up and use. It's a platform for collaboration and business processes. It supplements and complements many of the Microsoft Office products, and is the basis for what essentially becomes multi-player versions of those technologies.
So, once an organization picks SharePoint from the veritably huge and competitive playing field of collaborative computing products, how do you integrate it into the culture? The first part is governance and setting up and deploying the product in a way that makes sense for the organization, and the second part is advocacy and making it an important part of the job or daily life of any given person.
SharePoint governance is thought of as being a really complicated task, but it's actually not that wild, and companies or other organizations are probably already doing something similar with whatever technologies they use today. Let's say you have a file server. Do you have an "Accounting" folder on it? Is it set up so that employees of the Accounting department can get to it, but not other employees? If so, you're already practicing governance.
SharePoint governance is slightly more complicated because there are certain resources that you'll want to make available to different cross-sections of a user-base. First, let me just go over some basic SharePoint terminology.
A SharePoint server or server farm is exactly what it says on the tin – this is the actual physical infrastructure of SharePoint. A SharePoint site collection is a top level site on a server or farm. You can have one, or a dozen. Typically, site collections will be tangentially related in some way. These form the basis of governance, quota and disk space management, and configuration. A site is a particular site within a site collection. Each site collection is itself a site, and each site can thusly contain other sites, or individual lists and libraries, or both. (For example, a particular team may have their own site, with sub-sites for particular projects.)
In a company, you might have a site collection for departmental sites, or departmental site collections. This is going to be information that any given department or team will need, but won't' necessarily need to share with other over-arching parts of the organization. For example, an IT department is going to have a help desk team, an ERP team, a networking team, a server team, and a security team. Their site collection might look like this:
In this particular case, the "Knowledge Base" and "Ticketing System" sites are going to be sub-sites for the use of the entire department, and are going to have a single purpose. The items in blue are likely to be particular lists or document libraries for a particular team, although they could be deployed within sub-sites. Each team lead will be the owner on their sub-site.
The other main site collection may be various cross-functional things such as a company-wide announcements site, projects, etc.
In this example, there are going to be company-wide announcements and an events calendar, likely as lists stored within the Company site collection. There'll be a subsite or another site collection for projects, and each project the company has on will be there. Each project manager will be the owner on their project's sub-site, and will add and remove team members from various parts of the company as needed. Each project might, for example, have one or more engineer, designer, and marketing team member involved. Each project is going to need to have lists and libraries such as an announcements or discussion area, documents that are generated while working on the project (like documentation and schematics, possibly even code), as well as a calendar or Project Management module for scheduling and resource allocation.
In SharePoint 2013, a social feed feature was added to SharePoint, so it makes sense to deploy that, and I imagine that the Policies site would have either a single document library with documents contributed by team leads or directors (or another designee) from each department, with categories assigned, or particular document libraries for each department.
Once the structure is set up, the advocacy and integration should be pretty reasonable. Ideally, any document that's being actively worked on and is shared between employees or belongs to a "team" rather than an individual will be on SharePoint somewhere. This allows for versioning, really effective use of Word's mark-up and non-realtime collaborative editing functionality (track changes, for example) and for "multi-player Word" where more than one user can have a Word document open and make changes. (Google is ahead of Microsoft on this front, but Microsoft is quickly catching up.)
Ideally, advocates will be fairly evenly sprinkled around an organization, and will themselves be fairly active users of the system. They'll probably do things like actively post content into SharePoint and re-share links to it, or if somebody asks where a resource has gone, help them find it and show browsing through the corporate structure to find particular types of information.
In terms of what features get deployed, it really depends on how SharePoint is being used. There are a lot of different ways to use it, and different functionality may be deployed at different times. For example, the first goal may be to replace the "file server" with SharePoint for productivity purposes, and at a later date, discussion boards might be added to certain sites, and members of individual teams may be asked to make the SharePoint site for their team or department their browser home page, so they can use lists of links and view announcements and calendars on the site's home page for an at-a-glance view of the most important information when they start or return their workday.
Given that computers are used increasingly in home environments to manage, well, the home, I personally think that there could be a case for including it in a Windows Home or Small Business Essentials server to be used by families, or in other communities. A great example is my previous home, the crazyhouse, where essentially three to five unique factions live in various parts of the home and could have used a way to communicate with one-another and the owners in non-realtime.
My proposed structure for a SharePoint server for such a situation is relatively simple. It would be a single site collection representing everything in the house. At the top level, there's house-ide announcements, an events calendar, a cleaning/maintenance schedule, etc. Almost everything really could be managed by a single site, but I've gone ahead and put in a sub-site called Tenants, and given each Tenant a sub-site therein. (This is going to be the free version of SharePoint, or else I'd say encourage them to use the My Sites functionality that a larger organization would have.)
Of course, the biggest challenge facing this type of deployment (and one of the reasons I don't think SharePoint and similar tools are likely to get used like this) is that it's really hard to tell your roommates or tenants to look at your web site on a regular basis, but you can ask your employees to do so pretty easily, either by telling them that part of their job involves looking at this web site, or using technology (such as group policies on a Windows computer) to set a particular address (or set of addresses) as a home page, and maybe drop shortcuts to the pages or have the browser open automatically.
Of course, in certain situations (such as the SharePoint in a boarding or rental house concept) there are probably better tools available, and the low number of people and physical proximity probably means that there'll be ample opportunity for verbal communication, or something traditional such as a piece of paper on the refrigerator. I like to think that such a system could deployed in even larger multi-tenant environments, such as a dormitory, but I suspect that that's, similarly, a recipe for a disaster.
The other trouble with technologies such as SharePoint is that for personal situations, it's often "yet another account" somebody has to manage, and such a situation is likely to be considered low importance and the account is probably going to get forgotten. I've actually experienced that with some of the sub-sites I host on TECT, such as a site for a local group of friends. None of them specifically cares about TECT, so their accounts on the system are a lot more likely to go unused than people who have accounts specifically because of their interest in TECT. (And, there are a few.) This would probably be alleviated in situations where account creation and maintenance was more self-service, such as with a forum or MediaWiki installation. On the other hand, those systems have an implied use case that really does involve public web sites.
My personal SharePoint server is also used as my public web site, but it does have a somewhat similar structure, where there's a main page, this blog is on a sub-site, I have some sub-sites for communities I host on the machine (including my guild and some other things) and a private site I use instead of the My Site functionality.
Ultimately, SharePoint is actually not very different from some of the other neater web applications out there. Because Microsoft has to commit to a level of functionality and compatibility, it's nowhere near as neat as Google Applications, from a technical perspective (and from the perspective of just how well Google's Multi-Player Word Processor works) but it's essentially the only option if you want that type of functionality hosted on your own servers, especially if you wanted to integrate it with a single-sign-on system and you only wanted to maintain a single application and web server environment.
I actually suspect SharePoint is likely to catch on when members of an organization find out how low-effort it is to request and bring up their own sites, and add components such as a blog, a group calendar, document work spaces, and so on. With a properly deployed SharePoint environment, there's relatively little reason to keep using traditional file servers for collaboration on Office documents, but the biggest problem (and I suspect a big part of why SharePoint Online exists and is available to Office365 subscribers) is definitely improperly deployed servers. Because SharePoint is truly a more complicated way to store and use files, setting up an environment that's appropriate to the scale and getting good backups going can be a big challenge.
I have long thought that centralization, having a server, and even specifically software like SharePoint can be beneficial to organizations of any size. The biggest problems with the smallest organizations (and organizations that aren't necessarily profit-making corporations) is that SharePoint requires fairly hefty hardware to run, and while the basic level of SharePoint is free, Windows Server is mandatory, and is far from free. (Very old versions of SharePoint actually ran on client versions of Windows, but those days are over. SharePoint now also recommends 16-24 gigabytes of memory for a single server configuration.)
Microsoft is using Office 365 and SharePoint Online to try to counter-act these issues. By providing access to SharePoint or OneDrive for a few dollars per user per month or year, Microsoft is really building the case for centralized storage of files. I have mourned the loss of the classic Windows Small Business Server Standard product for a while now. Although it would be expensive, I would be in support of Microsoft's using Hyper-V to offer a physical appliance that has the same functionality as an SBS 2011 Standard box. Such a system would need to be as simple as plugging in your Internet line on one end and your LAN on the other, and have Exchange and SharePoint, but that entire setup is another topic, especially given how much the box would end up costing, with the firepower it would need to run three to six Windows instances plus Exchange and SharePoint.
For larger, existing deployments, it really is a matter of making sure the SharePoint technology works properly and is deployed well, and then advocating it within the organization. It's at least as much a training and culture issuer as it is a technical one, and I'm pleased to have had the opportunity to write about it from that perspective. SharePoint can do a lot, and in an ideal world, it might even get used as a front end or content rollup area for things like a human capital management system (like PeopleSoft or SAP), and I of course believe that with some thought, SharePoint can be used as a course management system. SharePoint can of course be customized by a developer, but there's also an awful lot it can do on its own.
This article is about the culture and I've touched on that, I wanted to emphasize again just how important both aspects are to a successful integration of SharePoint. If you do an Internet search for SharePoint problems, you'll find pages upon pages of results from people whose SharePoint administrators did something weird, and stuff that should work in a particular way now requires insane work-arounds.
Most people can't separate the concept of a product (especially infrastructure or applications like SharePoint, Exchange, SAP, or the BIND DNS server) with a particular work environment where it was used. As a result of this, most people believe SharePoint itself is a bad technology or a bad idea, without necessarily understanding that (just like how Windows 7 can be good or bad, depending on whether or not the machine is a $200 terrible-puter and is loaded with viruses and malware, or if it's a nice machine with good components that has a clean installation of Windows 7) SharePoint has different operating and performance properties that depend heavily on the administrator, hardware, and other factors. To make it more complicated, an individual desktop or the Active Directory and general system configuration practices in an organization can also affect how users experience SharePoint, and most of its features work best if you're (surprise) also using a Microsoft Exchange server, if you have Lync deployed (SharePoint 2010 and 2013 display a user's presence information, for example) and if your desktops are on the domain, and you're using Internet Explorer to access the services. (Also, if you have the matching-or-better version of Office.)
In that way, it may actually be the smallest organizations, looking at Office365 and using Small Business Server 2011 Standard (or earlier versions) that have the best experience with SharePoint. In particular, Small Business Server Standard comes with SharePoint set up in a reasonable manner out of the box. For a self-deployed system, when you throw enough server firepower at a single server setup of SharePoint, it is will perform well enough for some number of users. Of course, the eternal problem is that you need a lot of firepower to run SharePoint well.
In some environments, if you build it they will come, but in some other environments, users already using a solution (such as a plain file server) will need some evangelism and help. Culture is a very important part of any technology deployment, and some groups have a culture where they'll start using any new technology immediately. Other groups have a culture where they'll wait until after the last possible moment to start using a new thing. Encouragement can help, but like Windows XP, I suspect that there are going to be some people who will never give up their old unmanaged file servers.